[asdf-devel] Note on ASDF getting started guide...

[Nikodemus Siivola]

2009/10/5 Robert Goldman <rpgoldman at 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