2009/11/10 Robert Goldman rpgoldman@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