ASDF is designed in an object-oriented way from the ground up.
Both a system’s structure and the operations that can be performed on systems
follow a extensible protocol, allowing programmers to add new behaviours to ASDF.
cffi adds support for special FFI description files
that interface with C libraries and for wrapper files that embed C code in Lisp.
abcl-jar supports creating Java JAR archives in ABCL.
poiu supports compiling code in parallel using background processes.
The key classes in ASDF are
component represents an individual source file or a group of source files,
and the products (e.g., fasl files) produced from it.
operation represents a transformation that can be performed on a component,
turning them from source files to intermediate results to final outputs.
Components are related by dependencies, specified in system
When ordered to
operate with some operation on a component (usually a system),
ASDF will first compute a plan
by traversing the dependency graph using function
The resulting plan object contains an ordered list of actions.
An action is a pair of an
operation and a
representing a particular build step to be
The ordering of the plan ensures that no action is performed before
all its dependencies have been fulfilled.11
In this chapter, we describe ASDF’s object-oriented protocol, the classes that make it up, and the generic functions on those classes. These generic functions often take both an operation and a component as arguments: much of the power and configurability of ASDF is provided by this use of CLOS’s multiple dispatch. We will describe the built-in component and operation classes, and explain how to extend the ASDF protocol by defining new classes and methods for ASDF’s generic functions. We will also describe the many hooks that can be configured to customize the behaviour of existing functions.
Historically, the function that built a plan was
traverse, and returned a list of actions;
it was deprecated in favor of
make-plan (that returns a plan object)
plan objects were introduced with ASDF 3;
the old function is kept for backward compatibility and debugging purposes only,
and may be removed in the near future.
The term action
was used by Kent Pitman in his article, “The Description of Large Systems,”
and we suspect might be traced to
Although the term was only used by ASDF hackers starting with ASDF 2,
the concept was there since the very beginning of ASDF 1,
just not clearly articulated.