Next: Functions, Previous: Components, Up: The Object model of ASDF [Contents][Index]
To be successfully build-able, this graph of actions must be acyclic.
If, as a user, extender or implementer of ASDF, you introduce
a cycle into the dependency graph,
ASDF will fail loudly.
To clearly distinguish the direction of dependencies,
ASDF 3 uses the words requiring and required
as applied to an action depending on the other:
the requiring action depends-on the completion of all required actions
before it may itself be performed.
Using the defsystem syntax, users may easily express
direct dependencies along the graph of the object hierarchy:
between a component and its parent, its children, and its siblings.
By defining custom CLOS methods, you can express more elaborate dependencies as you wish.
Most common operations, such as load-op, compile-op or load-source-op
are automatically propagate “downward” the component hierarchy and are “covariant” with it:
to act the operation on the parent module, you must first act it on all the children components,
with the action on the parent being parent of the action on each child.
Other operations, such as prepare-op and prepare-source-op
(introduced in ASDF 3) are automatically propagated “upward” the component hierarchy
and are “contravariant” with it:
to perform the operation of preparing for compilation of a child component,
you must perform the operation of preparing for compilation of its parent component, and so on,
ensuring that all the parent’s dependencies are (compiled and) loaded
before the child component may be compiled and loaded.
Yet other operations, such as test-op or load-bundle-op
remain at the system level, and are not propagated along the hierarchy,
but instead do something global on the system.
Next: Functions, Previous: Components, Up: The Object model of ASDF [Contents][Index]