Next: Concept Index, Previous: TODO list, Up: Top [Contents][Index]
We aim to solve basically the same problems as mk-defsystem
does.
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
the source-foo
and binary-foo
prefixes
for separating source and binary files, and
we advise the removal of all options to specify pathnames.
The 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-package
form
in that file (ilisp / SLIME will like you more if you do this anyway)
defsystem
does 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 PROCESS-OPTIONS
and concept to deal with creating component trees
from defsystem
surface syntax.
[ this is not true right now, though it used to be and
probably will be again soon ]
Next: Concept Index, Previous: TODO list, Up: Top [Contents][Index]