All the operations described in this section are in the asdf
package.
They are invoked via the operate
generic function.
(asdf:operate 'asdf:operation-name :system-name {operation-options ...})
compile-op
&key proclamations
This operation compiles the specified component. If proclamations are supplied, they will be proclaimed. This is a good place to specify optimization settings.
When creating a new component type, you should provide methods for
compile-op
.When
compile-op
is invoked, component dependencies often cause some parts of the system to be loaded as well as compiled. Invokingcompile-op
does not necessarily load all the parts of the system, though; useload-op
to load a system.
load-op
&key proclamations
This operation loads a system.
The default methods for
load-op
compile files before loading them. For parity, your own methods on new component types should probably do so too.
parent-load-op
&key proclamations
This operation ensures that the dependencies of a module, and its parent, and so on, are loaded (as per
load-op
) before the components within that module may be operated upon.By default, all operations depend on this
parent-operation
for actions on components to depend on this “parent operation” being acted on the parent.The default methods for
load-op
compile files before loading them. For parity, your own methods on new component types should probably do so too.
load-source-op
This operation will load the source for the files in a module even if the source files have been compiled. Systems sometimes have knotty dependencies which require that sources are loaded before they can be compiled. This is how you do that.
If you are creating a component type, you need to implement this operation — at least, where meaningful.
test-op
This operation will perform some tests on the module. The default method will do nothing. The default dependency is to require
load-op
to be performed on the module first. The defaultoperation-done-p
is that the operation is never done — we assume that if you invoke thetest-op
, you want to test the system, even if you have already done so.The results of this operation are not defined by ASDF. It has proven difficult to define how the test operation should signal its results to the user in a way that is compatible with all of the various test libraries and test techniques in use in the community.
People typically define
test-op
methods like thus:(defmethod perform ((o asdf:test-op) (s (eql (asdf:find-system :mysystem)))) (asdf:load-system :mysystem) (eval (read-from-string "(some expression that runs the tests)")) t)
load-fasl-op
This operation will load and create if need be a single fasl file for all the files in each loaded system. (Its compilation-only equivalent is
asdf::fasl-op
.)Once you have created such a fasl, you can use
precompiled-system
to deliver it in a way that is compatible with clients having asdf dependencies on your system whether it is distributed as source of as a single binary.On your build platform, you run something like that:
(asdf:operate 'load-fasl-op
:mysystem)
And on your delivery platform, a form like this is evaluated in a prologue or at some point before you save your image:
(defsystem :mysystem :class :precompiled-system :fasl (some expression that will evaluate to a pathname))Of course, before you define such systems, you should not forget to
(asdf:clear-configuration)
.
load-fasl-op
is available on all actively supported Lisp implementations, and on those implementations only, and only since ASDF 3. This functionality was previously available for select implementations, as part of a separate systemasdf-bundle
, itself descended fromasdf-ecl
.