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
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
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
(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
remain at the system level, and are not propagated along the hierarchy,
but instead do something global on the system.