[asdf-devel] asdf and quicklisp
Faré
fahree at gmail.com
Fri Oct 12 15:05:54 UTC 2012
On Fri, Oct 12, 2012 at 10:31 AM, Zach Beane <xach at xach.com> wrote:
> I stopped updating ASDF versions when it seemed to require asdf-ecl.lisp
> to work on ECL. Is the case? Can ECL get by with asdf.lisp alone?
>
Wait: inasmuch as ECL likes to have asdf-ecl.lisp loaded,
this has *ALWAYS* been the case, since back in the days of ASDF 1.
The difference is that at the time, everyone was forced to use
whichever version of ASDF was bundled with their implementation,
which in the case of ECL would include asdf-ecl, even though
asdf-ecl wasn't included in the upstream version of ASDF.
If anything, ASDF 2 has made things BETTER for those who load asdf
without loading asdf-ecl: I've moved into asdf.lisp
all the essential bits that were previously in asdf-ecl.lisp
(if only for the sake of asdf self-upgrade).
Also, if you fail to load asdf-ecl, you may now find that
the same functionality is now available as part of asdf-bundle
(though it's largely untested by lack of test cases;
I suppose I could modify cl-launch to test some of it).
Note that if you're concerned about ECL,
ECL support was notably improved since the version
of ASDF you picked (2.014.6).
The latest significant change for ECL support is in 2.23.1
(merging in various enhancements made in the ECL source tree),
with various subsequent cleanups before 2.24, as I added MKCL support
and refactored ECL and MKCL support together.
But for the sake of running on ECL without asdf-ecl,
you really want at least 2.21
(though 2.018 or 2.019 might do; I would have to re-test;
2.20 had a bug with ECL).
> Quicklisp is geared towards providing libraries ("systems"), and I see
> ASDF is an application for loading systems, not a library.
>
Yes, but some libraries require recent versions of ASDF
to use recent features (:defsystem-depends-on, :encoding,
:around-compile, :compile-check) or bug fixes
(nikodemus I'm sure would be delighted to be able to rely
on a fixed default-component-class; also fixed was weakly-depends-on).
Many implementations also require a recent ASDF:
lispworks-personal-edition has been broken for a while
before stassats noticed (since it has no command-line,
it's not part of my automated tests);
XCL, MKCL were added;
abcl, allegro, ccl, clisp, lispworks have had notable fixes,
as well as cormanlisp, GCL, Genera, RMCL (if anyone still uses them).
Windows search paths have been fixed
(also something I don't test automatically).
Logical-pathnames were fixed (again).
Self-upgrading has been made more robust on all platforms.
Various instabilities you yourself reported when using quicklisp were fixed.
Many other bugfixes, tweaks, usability improvements were made.
> It has a
> parallel and separate system for updates in Quicklisp. I have put time
> and effort into making it possible to "downgrade" library sets with
> Quicklisp, providing an escape hatch for harmful changes to libraries,
> there is no easy mechanism for ASDF. (There's also no easy mechanism for
> Quicklisp itself, but I am not too troubled by that since I can make
> quick updates to Quicklisp directly if needed.)
>
The "self-upgrade" of ASDF can also be used for self-downgrade,
although there were bugs and limitations that have been lifted with 2.015
(i.e. if the *initial* ASDF is earlier than 2.015, you must load
the new ASDF alone *before* you load any other system; if you load a system
that depends on ASDF, the upgrade won't go smoothly).
> I'm up for upgrading the provided version to a more recent ASDF if it is
> still a single file on all implementations and if it doesn't cause any
> major compatibility problems. Of course, those always seem to crop up
> after things have been pushed into wide use, not during testing.
>
Yes. I always think to myself "this is the LAST asdf release",
and right after I release it, someone tells me about a bug.
Happily, the bugs seem to get smaller after each release, these days.
> Jumping on a frequent upgrade cycle for ASDF does not excite me,
> though.
>
I'm not asking for a *frequent* upgrade.
But considering how much ASDF has evolved recently, I think it reasonable
to request that you should upgrade at least once a year.
2.014.6 is from April 2011, which is well past its due date.
PS: Attila Lendvai pushed a fix to hu.dwim.asdf so you should be all set there.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The rule is perfect: in all matters of opinion our adversaries are insane.
— Mark Twain
More information about the asdf-devel
mailing list