Juan Jose Garcia-Ripoll <juanjose.garciarip...@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-Integration.html#Groveller-ASDF-Integration _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel