[asdf-devel] SBCL port of ECL's extensions

Robert Goldman rpgoldman at sift.info
Mon Mar 29 15:53:42 UTC 2010


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 <tcr at freebits.de
> <mailto:tcr at freebits.de>> wrote:
> 
>     Juan Jose Garcia-Ripoll
>     <juanjose.garciaripoll at googlemail.com
>     <mailto:juanjose.garciaripoll at 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




More information about the asdf-devel mailing list