We aim to solve basically the same problems as
However, our architecture for extensibility
better exploits CL language features (and is documented),
and we intend to be portable rather than just widely-ported.
No slight on the
mk-defsystem authors and maintainers is intended here;
that implementation has the unenviable task
of supporting pre-ANSI implementations, which is no longer necessary.
The surface defsystem syntax of asdf is more-or-less compatible with
mk-defsystem, except that we do not support
for separating source and binary files, and
we advise the removal of all options to specify pathnames.
mk-defsystem code for topologically sorting
a module’s dependency list was very useful.
Marco and Peter’s proposal for defsystem 4 served as the driver for many of the features in here. Notable differences are:
If you want to find out what files an operation would create, ask the operation.
If you want to compile in a particular package, use an
in that file (ilisp / SLIME will like you more if you do this anyway)
defsystemdoes version control.
A system has a given version which can be used to check dependencies, but that’s all.
The defsystem 4 proposal tends to look more at the external features, whereas this one centres on a protocol for system introspection.
Available in updated-for-CL form on the web at http://nhplace.com/kent/Papers/Large-Systems.html
In our implementation we borrow kmp’s overall
and concept to deal with creating component trees
defsystem surface syntax.
[ this is not true right now, though it used to be and
probably will be again soon ]