2009/10/5 Robert Goldman rpgoldman@sift.info:
Recently, we modified the default dependencies of the test-op, entirely reasonably, so that by default you need to do a load-op on a system before doing the test-op. Unfortunately, this means that system definitions written for new ASDF will not test-op properly on earlier versions of ASDF. [Worse, I don't believe we can even test asdf versions properly --- seems like earlier versions don't have the asdf:*asdf-version* variable defined.]
I'm not sure I actually buy this. :) If you had been using SBCL, you would have made the change in the SBCL's copy of ASDF, rebuilt SBCL, distributed it internally, and everything would have been fine...
But yes, I agree there are cases where you might want to update, particularly if you have an ancient SBCL that you cannot for some reason recompile and install. (?)
I'd be happy to update the manual to include instructions for people installing git or downloaded versions of ASDF onto SBCL. However, SBCL is not my primary CL implementation, and I am not competent on my own to do more than say "this might break contrib modules on SBCL." Would it be possible for someone (you?) to provide suitable instructions? If you do this, I will undertake to do the grunt work of getting those instructions into the ASDF manual.
There is one real issue, and one potential issue:
SBCL installs asdf.fasl, which hooks into REQUIRE, and provides the system-definition-search-function that know where the contrib modules are. This is the real issue. The easies way to override the default ASDF would probably be to first require the SBCL-provided one, and the load the new one. I *think* that should work. The other option is to make sure the new one hooks into require and tells ASDF where to find the contrib modules. It's not brain surgery, but people who don't feel comfortable with this should not update the SBCL provided ASDF.
The second issue is that there could be (maybe there is already, I'm not sure offhand) ASDF dependent stuff in the already-compiled-and-installed contrib modules -- if the new ASDF is not compatible with these (eg. function signatures, etc), things will break. Users updating ASDF need to be aware of this as well.
Alternatively, is it possible to modify the portable ASDF distro so that out of the box it would be capable of not breaking contrib modules?
This is probably the best solution -- but I probably won't have the spare cycles to think about it this week.
Cheers,
-- Nikodemus