Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com writes:
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.
I suggest that the Manual contains a few notes on Style, perhaps as an FAQ. The notes should also explain why pureness in .asd is worthwhile. I'll submit a bug entry for this.
Also FAQ 12.5.1 "How can I cater for unit-testing in my system?", does not actually fully show how to add unit-testing in pure style; it shows the IN-ORDER for the FOO system, but does not show how to actually invoke the RUN-TESTS (or whatever) in the FOO-TEST system. I'll submit a bug entry for this, too.
There, however, seems to be an inherent dependency-vs-pureness problem with user extensions as illustrated by cffi-grovel; from [1]:
;;; CFFI-Grovel is needed for processing grovel-file components (cl:eval-when (:load-toplevel :execute) (asdf:operate 'asdf:load-op 'cffi-grovel))
(asdf:defsystem example-software :depends-on (cffi) :serial t :components ((:file "package") (cffi-grovel:grovel-file "example-grovelling") (:file "example")))
I know Stelian cursed about this in-persona, wishing for a reader which has a notion of unresolved-symbols.
-T.
[1] http://common-lisp.net/project/cffi/manual/html_node/Groveller-ASDF-Integrat...