[asdf-devel] ASDF improvements from ECL

[Faré]

2009/11/10 Robert Goldman <rpgoldman at sift.info>:
> 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....
>
Here's the way out I use with XCVB, that depends on a quite recent copy ASDF:
1- include your own copy of ASDF in your source distribution.
2- first, obliterate the previous ASDF with /xcvb/no-asdf.

In case you can't do that (e.g. cl-launch doesn't support this
overriding of ASDF), make sure your basic functionality works with a
legacy ASDF and extensions are #+'ed away.

> Worse than that, Classic ASDF\tm doesn't seem to have provided any
> versioning information for us to use in conditional compilation.
My way out is to handle that in your larger build system. ASDF needs
to be setup somehow, so you need scripts that DTRT wrt loading ASDF
itself and setting the central-registry. That build system can push
the *features* that distinguish a good ASDF from a bad one.

Or you could start helping me develop XCVB. It is getting quite usable
these days.

> 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.
>
Committee, schmommittee. If you want for a document to be born ten
years from now that will standardize this ten year old technology, a
committee is what you need.

If what you want is a better build system, get hacking -- and may I
suggest that you hack on current technology like XCVB instead of
trying to extend an evolutionary dead-end?

I think what ASDF itself needs is some minor work of
1- cleaning up, unifying and stabilizing the various versions that are
available for the several implementations
2- maybe a few essential hooks for extensions (such as a flag "list as
dependency of LOAD-OP'ing the parent", vs "present as dependency of
other things").
3- continuing support for legacy code, including existing ASDF plugins.

I don't think it's a good idea to try invest in making big changes or
innovations on top of ths code base. I recommend you give a try to
XCVB and extending it -- or not even extending it: you can already
have a build /foo and another build /foo/test that depends on foo --
or better, whose individual files each depend on relevant parts of
foo, which allows for incremental testing.

> 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.
>
It's a two-way street. If we can't accommodate the legitimate needs of
implementers such as those of ECL, why would they bother trying to
accommodate us?

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
If money is your hope for independence you will never have it. The only real
security that a man will have in this world is a reserve of knowledge,
experience, and ability. -- Henry Ford