Next: Pre-defined subclasses of component, Previous: Components, Up: Components [Contents][Index]
All components, regardless of type, have the following attributes.
All attributes except name
are optional.
A component name is a string or a symbol. If a symbol, its name is taken and lowercased.
Unless overridden by a :pathname
attribute,
the name will be interpreted as a pathname specifier according
to a Unix-style syntax.
See Pathname specifiers.
This optional attribute is used by the test-system-version
operation.
See Predefined operations of ASDF.
For the default method of test-system-version
,
the version should be a string of integers separated by dots,
for example ‘1.0.11’.
Nota Bene: This operation, planned for ASDF 1, is still not implement yet as of ASDF 2. Don’t hold your breath.
FIXME: This subsection seems to contradict the
defsystem
grammar subsection,
which doesn’t provide any obvious way to specify required features.
Furthermore, in 2009, discussions on the
asdf-devel mailing list
suggested that the specification of required features may be broken,
and that no one may have been using them for a while.
Please contact the
asdf-devel mailing list
if you are interested in getting this features feature fixed.
Traditionally defsystem users have used reader conditionals to include or exclude specific per-implementation files. This means that any single implementation cannot read the entire system, which becomes a problem if it doesn’t wish to compile it, but instead for example to create an archive file containing all the sources, as it will omit to process the system-dependent sources for other systems.
Each component in an asdf system may therefore specify features using
the same syntax as #+
does, and it will (somehow) be ignored for
certain operations unless the feature conditional is a member of
*features*
.
This attribute specifies dependencies of the component on its siblings. It is optional but often necessary.
There is an excitingly complicated relationship between the initarg and the method that you use to ask about dependencies
Dependencies are between (operation component) pairs. In your initargs for the component, you can say
:in-order-to ((compile-op (load-op "a" "b") (compile-op "c")) (load-op (load-op "foo")))
This means the following things:
load-op
, we have to load foo
The syntax is approximately
(this-op {(other-op required-components)}+) required-components := component-name | (required-components required-components) component-name := string | (:version string minimum-version-object)
Side note:
This is on a par with what ACL defsystem does. mk-defsystem is less general: it has an implied dependency
for all x, (load x) depends on (compile x)
and using a :depends-on
argument to say that b depends on
a actually means that
(compile b) depends on (load a)
This is insufficient for e.g. the McCLIM system, which requires that all the files are loaded before any of them can be compiled ]
End side note
In ASDF, the dependency information for a given component and operation
can be queried using (component-depends-on operation component)
,
which returns a list
((load-op "a") (load-op "b") (compile-op "c") ...)
component-depends-on
can be subclassed for more specific
component/operation types: these need to (call-next-method)
and append the answer to their dependency, unless
they have a good reason for completely overriding the default dependencies.
If it weren’t for CLISP, we’d be using LIST
method
combination to do this transparently.
But, we need to support CLISP.
If you have the time for some CLISP hacking,
I’m sure they’d welcome your fixes.
This attribute is optional and if absent (which is the usual case), the component name will be used.
See Pathname specifiers, for an explanation of how this attribute is interpreted.
Note that the defsystem
macro (used to create a “top-level” system)
does additional processing to set the filesystem location of
the top component in that system.
This is detailed elsewhere. See Defining systems with defsystem.
This attribute is optional.
Packaging systems often require information about files or systems in addition to that specified by ASDF’s pre-defined component attributes. Programs that create vendor packages out of ASDF systems therefore have to create “placeholder” information to satisfy these systems. Sometimes the creator of an ASDF system may know the additional information and wish to provide it directly.
(component-property component property-name)
and
associated setf
method will allow
the programmatic update of this information.
Property names are compared as if by EQL
,
so use symbols or keywords or something.
• Pre-defined subclasses of component: | ||
• Creating new component types: |
Next: Pre-defined subclasses of component, Previous: Components, Up: Components [Contents][Index]