Next: Controlling where ASDF searches for systems, Previous: Defining systems with defsystem, Up: ASDF: Another System Definition Facility [Contents][Index]
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 an extensible protocol, allowing programmers to add new behaviours to ASDF.
For example, cffi adds support for special FFI description files
that interface with C libraries and for wrapper files that embed C code in Lisp.
asdf-jar supports creating Java JAR archives in ABCL.
poiu supports compiling code in parallel using background processes.
The key classes in ASDF are component and operation.
A component represents an individual source file or a group of source files,
and the products (e.g., fasl files) produced from it.
An 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
definitions.
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 make-plan.10
The resulting plan object contains an ordered list of actions.
An action is a pair of an operation and a component,
representing a particular build step to be performed.
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
called traverse, and returned a list of actions;
it was deprecated in favor of make-plan (that returns a plan object)
when the 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,”
(see Bibliography),
and we suspect might be traced to make.
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.