[Ecls-list] ASDF revolt

[Daniel Herring]

Hi Juanjo,

I largely agree with your thoughts on ASDF, with one glaring exception: 
ASDF should be replaced, the sooner the better.  The architecture has 
fundamental flaws.  Frankly, I was shocked with how much development it 
has received this year; even Fare has said he would rather work on XCVB.

I think XCVB has some good improvements over ASDF; but last I checked, it 
still felt wrong.  It solves some important build consistency issues, but 
doesn't tackle much other than compilation.

As an aside, I'm not sold on the value of logical pathnames[1].


Rich Kreuter gave an interesting talk at the Boston Lisp meeting several 
months ago.  In it, he argued that REQUIRE had almost the right semantics 
and that defsystems like ASDF were the wrong thing.

One of his basic points was that people who use a library want a simple 
way to load it.  They don't care what build framework it uses, and they 
definitely shouldn't be forced to use the same build framework.


This resonated with me and my experience in the C/C++/unix world.  The GNU 
autotools are dominant not because they are easy to start with; they took 
over because they do the right thing.  Configure is a self-contained shell 
script; the packager needs autoconf installed, but the user doesn't. 
Only a decent shell, compiler, and make are presumed to be on the user's 
system.  Configure detects the actual system behavior; it doesn't require 
the end user to tell it everything, it doesn't rely on preconfigured 
tables, it fails with logs about what went wrong, and it outputs 
"config.h".  Once "configure; make; make install" are finished, the user 
never needs to touch anything from the build framework.

Contrast that with ASDF.
- Nontrivial bootstrap; CL impls are encouraged to ship with it.
- ASDF is always used to load the library/application.
- All libraries must use the same version of ASDF.
- No interaction with non-asdf systems.
...


Considering "autotools for CL", the autotools (and even make) simply are 
not suitable for CL.  Furthermore, a great source of their pain comes from 
the reliance on "portable" shell scripting and make.  A CL build tool that 
followed their basic pattern should be much easier to develop in portable 
CL...

My current idea is to write two packages for each library: 
configure-(library)-(version) with nickname "configure" and 
make-(library)-(version) with nickname "make".  Each would be in a single 
source file, the result of a "macroexpansion" performed by the packager, 
so the end user doesn't need any build tools installed.  If configure 
detected a local build tool, that could be exploited instead of the 
standard make script.

The final result of a "make" would be a single file, source or fasl, that 
pulls in everything when loaded.  No build framework required.  All CL 
implementations have support for hooking such a file into REQUIRE (ASDF 
requires a more sophisticated hook).  I outlined a couple other details on 
the ASDF list[2].


Last point for tonight.  Somebody needs to figure out a way to handle 
library versioning.  Preferably in a way that allows multiple versions to 
peacefully coexist.  Again, Kreuter claims to have made a system that 
almost did the right thing.  I have also daydreamed on the topic[3].

Later,
Daniel

P.S. Work and home have had me completely swamped this year; but I keep 
hoping that time will lighten up.

[1] Zach's Journal - Logical pathnames survey
http://xach.livejournal.com/242280.html

[2] Subject: A dream for ASDF2
http://thread.gmane.org/gmane.lisp.asdf.devel/825

[3] Subject: Thoughts on library versioning
http://thread.gmane.org/gmane.lisp.libcl.devel/110