[Ecls-list] ASDF revolt

[james anderson]

good morning;

On 2010-03-31, at 05:31 , Daniel Herring wrote:

> 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.

because it is there.

>
> 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.

perhaps, if there were something which did an adequate job with just  
compilation and offered an adequate interface to the inference  
machinery, one could do with it also all the other things one might  
think up. as you note below, it would be very helpful to have a  
coherent model for versions, as well as one for runtime variations.

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

if that reference was intended to bolster skepticism about logical  
pathnames, it was not a good one.
somehow some people see enough utility, that a substitute was defined  
as an asdf extension.

>
>
> 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.

what happened to support for versions?

>
>
> 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.

the last thing i would ever want to wish on a user of my code is to  
have to decipher a procedural description for the program's  
constituent sources, configuration, dependencies, and construction.
i have yet to see a configure file which even remotely implied that a  
coherent description of any of these aspects was at issue.
please, no.

>
> Contrast that with ASDF.
> - Nontrivial bootstrap; CL impls are encouraged to ship with it.

i recall that some of them even ship in a form which allows one to  
require it.

> - ASDF is always used to load the library/application.

pick an interface. any interface. it's lisp.

> - All libraries must use the same version of ASDF.

that problem is orthogonal to asdf per se.

> - 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.

if the dominant goal is to simplify, it is demonstrated, that there  
is sufficient information in package declarations to build lisp  
programs. asdf manifests an additional goal: that system definitions  
are first-class and independent of the implementation. this is  
valuable. when you propose an alternative, please include it.

>
> The final result of a "make" would be a single file, source or  
> fasl, that
> pulls in everything when loaded.

what happened to versions? post-facto.

>   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].

if you have a reference to a proposal, that would help. google yields  
lots of ancillaries for him, but no substance.