Dear SBCL hackers,
after Attila's bug report from his new SBCL-provided ASDF, I released
2.105 == 2.003, a new version of ASDF that fixes that embarrassing bug
in a new feature I advertised, i.e. the ability to always update to
the newest available configured ASDF with (require :asdf)
(asdf:load-system :asdf). It also fixes a few other minor things, and
brings to 2.0 the COMPILE-FILE* facility that never leaves the output
FASL in a broken state.
Please update ASDF in SBCL to 2.003 (rather than 2.105) using the
--branch release flag in the Makefile script.
Also note that it is now incorrect to have SBCL_HOME be a relative
path, and that run-sbcl should be changed (either relying on readlink
-f or spawning an initial sbcl for the sake of calling truename) to
make its $BASE an absolute namestring.
slyrus, can you do it all?
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Anarchism is founded on the observation that since few men are wise enough
to rule themselves, even fewer are wise enough to rule others. — Edward Abbey
From: Attila Lendvai <attila.lendvai@gm...> - 2010-06-25 06:32:50
> Also note that it is now incorrect to have SBCL_HOME be a relative
> path, and that run-sbcl should be changed (either relying on readlink
> -f or spawning an initial sbcl for the sake of calling truename) to
> make its $BASE an absolute namestring.
if someone is touching run-sbcl.sh, then please get rid of the --help
stuff in it.
we've got a command line tool (a build program) that can be run from
an executable core and through a shell script.
its --help doesn't work when invoked through a shell script.
for convenience, i've attached a run-sbcl.sh with both of the above
ps: although i still think that a hard coded default
relative-to-the-executable path for the core file, and a sane
placement of the resulting executable of the build, would be a much
better answer to the problem than the current sh wrapper...