On 3/29/10 Mar 29 -9:49 AM, Juan Jose Garcia-Ripoll wrote: > On Mon, Mar 29, 2010 at 4:43 PM, Tobias C. Rittweiler <t...@freebits.de > <mailto:t...@freebits.de>> wrote: > > Juan Jose Garcia-Ripoll > <juanjose.garciarip...@googlemail.com > <mailto:juanjose.garciarip...@googlemail.com>> writes: > > What is needed for any kind of standalone system building that > relies on > > ASDF system definitions and is capable of incorporating all > dependencies? > > > > - A way to gather the list of files that form part of that system > > (gather-components in asdf-ext.lisp) > > - A way to compile the components (provided by asdf.lisp and > extended by > > asdf-{ecl,sbcl,...}.lisp if needed) > > - A way to pack all the compiled files into a single output file > > (implementation-dependent and thus in asdf-{ecl,sbcl...}). > > > > The first part is very critical and it needs the expertise of ALL > of ASDF > > maintainers to get it right. As a bonus the result will be > applicable to ALL > > functions that kind of grovel through ASDF system definitions. > > Another real life usage case: Slime's asdf contrib does that, too, to > provide functionality such as running the Emacs command rgrep, or > query-replace over all files defined in a system. > > > This is why I insist so often that the ASDF grovelling facility has to > be part of the core. Right now ECL and the extensions above use a nasty > trick: TRAVERSE is invoked using an operation COMPILE-OP and we wrap > around LOAD-OP to inform ASDF that the operation was not done before. > What this does is create a list of operations that ASDF would do > assuming that absolutely no system was loaded. This has the advantage > that one does not have to code special cases or traverse the tree > manually looking for implicit or explicit dependencies, but I am afraid > it is just as fragile.
I think that this is a laudable objective, but I'm inclined to suggest that it be pushed past ASDF 2 because it's a significant widening of the API with hard-to-predict effects on backward compatibility. Aside from fixing the obvious bug in intra-system dependencies, we have been very delicate about rooting around inside TRAVERSE and, as you know, even my very delicate modifications caused significant pain. My vote would be to make gathering components wait past ASDF 2. That would allow us to ship pretty close to what we have now (I am painfully conscious that a number of the bottlenecks are down to me), and would also permit a changing of the guard in ASDF maintainership. Faré has expressed an interest in focusing his "fix the world" energy on an ASDF successor, instead of continuing to try to wrestle with the ASDF code base. Similarly, I'd like to get ASDF tolerably documented and be able to free up time for some other open source projects. Would it be possible to take a straw poll about how to assign the gather-components protocol to a milestone? Best, r _______________________________________________ asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
