[asdf-devel] ASDF improvements from ECL

Robert Goldman rpgoldman at sift.info
Tue Nov 10 22:20:06 UTC 2009

Faré wrote:
> (Moving the discussion from the ecl list to the asdf list,
> originally Re: ECL support for cl-launch and xcvb)
> 2009/11/9 Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com>:
>> This is another thing I have been asking help from the ASDF
>> maintainers. We cannot push our extensions upstream until they have
>> been agreed upon, I mean we need a blessing for what we are doing with
>> TRAVERSE and the like, and the assurance that the enging below is not
>> going to arbitrary change breaking the operations we have. Again, I
>> have written like five emails to the list without any answer. It is
>> discouraging.
> The problem is that you'll find no one to bless your changes, as ASDF
> does not have a clearly defined dictator, the original author having left,
> our main maintainer not having the resources to become one, and a vast
> undefined community of users not being able to provide a clear permission
> wrt making incompatible changes since it's not clear what in the
> implementation or its documentation is binding for the future and what isn't.

An additional problem is that there is no clear relationship between the
ASDF project and the versions of ASDF shipped with implementations.

I find that this is a strong disincentive for me to work on even
backwards-compatible extensions to ASDF (asdf extensions providing new
functionality, but not breaking any old functionality).

The lisp code I work on is shared across a number of organizations and I
don't have a good way of getting people at all these organizations to
adopt a patched ASDF.  That means that I have to both provide a system
that employs the new functionality /and/ a version of the system
(presumably using conditional reading) that will replicate the
functionality that I have pushed into ASDF....

Worse than that, Classic ASDF\tm doesn't seem to have provided any
versioning information for us to use in conditional compilation.

I'm inclined to think that the ASDF-using community needs to somehow
evolve a committee --- ideally with representatives from the SBCL
developers, CCL developers, Franz, and LispWorks --- that will help vet
ASDF and deal with release processes.

This would meet the implementors need for some idea about when would be
a good time to pull an ASDF revision into their CL, and would give ASDF
programmers some sense that their efforts are unwasted.


More information about the asdf-devel mailing list