[asdf-devel] fare-utils build failure

[Faré]

Cc'ng asdf-devel.

On Wed, Jan 16, 2013 at 9:30 AM, Zach Beane <xach at xach.com> wrote:
> Faré <fahree at gmail.com> writes:
>
>>> How do I get asdf-driver?
>>>
>> It's currently part of the asdf git tree. Should I make it separate?
>> I think you can already include asdf-driver.asd without including asdf.
>
> What is the relationship between asdf-driver and asdf? What is a driver?
>
asdf uses asdf-driver.
asdf-driver is currently distributed as part of the asdf source tree,
but if that is an issue, there is no barrier to splitting it apart.

For bootstrap purposes, the source code of asdf-driver is transcluded
into asdf.lisp as a prelude to asdf, so asdf can rely on it.

asdf-driver is a general purpose portability and runtime management library.
It provides various abstraction layers for packages,
pathnames, command-line arguments, compilation, condition-muffling,
run-program, image dump and restore with hooks, basic I/O, etc.

Basically, it's all the portability work I did over the last few years
as part of asdf and xcvb, so as to be able to run user code unchanged
(above the abstraction layer) on all supported lisp implementations.

When rpgoldman convinced me that a portable, usable run-program
should be part of asdf, whereas the legacy run-shell-command
is an unusable unmaintainable unfixable crock,
I decided to pull in the implementation from xcvb-driver.
At the same time, drewc convinced me that having plenty of smaller files,
with one package per file, was a good idea.
I have been haunted for a few years for having failed janderson
when he proposed to split asdf in parts; yet
now asdf.lisp is much bigger than it was then,
and at the same, having integrated bundle operations
and figured out the dependency mess means it's easier and safer
to write a general purpose source-concatenation operation.
Finally you (Xach) convinced me that ASDF itself should not
be a utility library, but only a build system;
at the same time I really need the portability library,
for XCVB as well as for ASDF and for any portable CL code I write.
To top it all, after having completely reimplemented ASDF several times,
I have started feeling much more comfortable with
taking it apart and reassembling it in better ways.

So there. I split ASDF in parts, and the part that's not specific
to the system definition facility has been separated into asdf-driver.

On most implementations, you can upgrade asdf-driver on top of an old ASDF
-- though I admit I haven't yet added this situation
to my automated testing regime.

(The outlier as usual is CLISP, which is very funky to upgrade,
and I don't know how to do things short
of deleting the ASDF package when there's an incompatibility,
which isn't conducive to upgrading ASDF-DRIVER far beyond ASDF;
but I have ideas on how to make things a little bit more usable.)

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If I go through life free and rich, I shall not cry because my neighbour,
equally free, is richer. Liberty will ultimately make all men rich; it will
not make all men equally rich. Authority may (and may not) make all men
equally rich in purse; it certainly will make them equally poor in all that
makes life best worth living.  — Benjamin Tucker