This is an idea that has been long floating in the back of my mind, and was brought back to life by these comments http://groups.google.com/group/comp.lang.lisp/msg/f99a69797eda1caf
The problem is that many people use *.asd files to do things like building up packages, creating operations, defining methods, etc. That makes it impossible to ship those libraries because the side effects are not recorded in the system itself. So if ECL traverses the system to build a standalone program it will know which sources are required, but those sources may for instance rely on a package that was created in the *.asd definition.
My suggestion is a gradual move towards enforcing that *.asd files become mere descriptions of the system and that side effects needed for building and loading are listed in the system itself.
- System definitions should be read and recorded by ASDF in pure form, that is as S expressions, with a hash that maps system names to s-expressions. - Instead of using LOAD we use a LOOP and READ. If a form which is not a DEFSYSTEM is found, we have two options: if we enforce strict mode, an error is signaled, otherwise the form is evaluated after emitting a warning. - Warnings could also be emitted when a DEFSYSTEM clause does not match the name of the file, or when more than one such clauses is found. - The system definition should be scanned for a class name and for a keyword option, :asdf-support If the :asdf-support option is found, it should name a file with side effects that are needed for the ASDF definition to be used. The file should be loaded using LOAD. - The original S expression is now parsed and the system definition is created.
The warning could be really self-explanatory, stating the following: - Dependencies that are needed for processing the system definition must be listed in :asdf-support - Dependencies that are needed for load/compile-op should be listed in :depends-on
I can think on even more elegant ways to do this. For instance having proxy classes, such as proxy-system and proxy-component which are used to store the S-expression for the system and using change-class on these objects to transform them into valid systems and components on demand, that is only when the systems are needed.
It should also be possible to write an utility that grovels existing ASDF systems looking for potential problems and suggesting changes.
What the solution above does not address is the following sentence from Daniel's comment:
As to the "no". Simply doing asdf:find-component may result in side effects, both in the package of interest and in random other packages before it. These side effects include dumping fasls. There are several asd files that force things to load early in order to extend ASDF by defining custom classes."
In other words, the side effects in :asdf-support can be really harmful, or costly. However this proposal could help us identify what libraries do have side effects and also help enforce further restrictions in the side effects they may have.
I mean, there are many many other ways to do this, but I think you get the idea.
Juanjo