Next: Concept Index, Previous: missing bits in implementation, Up: Top
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)
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://world.std.com/~pitman/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 ]