A couple of points I noticed while doing my backport to info:
1. We start by saying "you can just use require," but then we say "you only need to load asdf.lisp." I think it would be better to say "if this require trick works, you can skip over the section about loading asdf."
2. We might want to say "you might want to install ASDF yourself if you want to get a particular version of ASDF."
HtH, r
2009/10/5 Robert Goldman rpgoldman@sift.info:
- We might want to say "you might want to install ASDF yourself if you
want to get a particular version of ASDF."
Please don't say this, unless you also provide instructions that allow people installing their own ASDF's not break things like SBCL contrib modules.
"Why is SB-FOO broken?" is pretty frustrating when it turns out that they broke their own environment my installing another copy ASDF that messes with SBCL's assumptions about loading contrib modules.
Cheers,
-- Nikodemus
Nikodemus Siivola wrote:
2009/10/5 Robert Goldman rpgoldman@sift.info:
- We might want to say "you might want to install ASDF yourself if you
want to get a particular version of ASDF."
Please don't say this, unless you also provide instructions that allow people installing their own ASDF's not break things like SBCL contrib modules.
"Why is SB-FOO broken?" is pretty frustrating when it turns out that they broke their own environment my installing another copy ASDF that messes with SBCL's assumptions about loading contrib modules.
Well, here's an example of why people might want to be loading their own:
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'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.
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?
Best, r
2009/10/5 Robert Goldman rpgoldman@sift.info:
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?
I did my best in /xcvb/no-asdf to allow the uninstallation of a previous ASDF such that the new installation will not break contrib modules. I needed it so as to use the latest ASDF whereas Debian has an ancient one, and SBCL is not always cutting-edge enough for me.
It looks like it's working to me. If there are issues that can be fixed, I'll welcome bug reports and patches.
http://common-lisp.net/gitweb?p=projects/xcvb/xcvb.git;a=blob;f=no-asdf.lisp
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] People are not born rich and become poor because of some dreadful phenomenon. They are born deprived of anything and become rich when they do but by the accumulated fruits of their own and their ancestors' labor: their capital.
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
-
Faré -
Nikodemus Siivola -
Robert Goldman