From: Scott L. Burson on
Ever since I started using ASDF I have been mildly bugged by redundant
recompilations: recompilations of fasls that are already up to date.
This problem doesn't seem to have gone away: I was just trying the new
ABCL (with ASDF 1.719) to see if it could run FSet, and every time I
restart ABCL and load FSet, ASDF recompiles several files, despite the
sources not having changed.

I'll put together a proper bug report for the maintainers, but first
I'm curious, because I haven't heard anyone else complain about this:
does anyone else see this behavior?

-- Scott
From: D Herring on
On 06/02/2010 08:25 PM, Scott L. Burson wrote:
> Ever since I started using ASDF I have been mildly bugged by redundant
> recompilations: recompilations of fasls that are already up to date.
> This problem doesn't seem to have gone away: I was just trying the new
> ABCL (with ASDF 1.719) to see if it could run FSet, and every time I
> restart ABCL and load FSet, ASDF recompiles several files, despite the
> sources not having changed.
>
> I'll put together a proper bug report for the maintainers, but first
> I'm curious, because I haven't heard anyone else complain about this:
> does anyone else see this behavior?

Not nearly as bad as you describe; but yes, I have seen what appear to
be spurious recompilations. I have seen some files which always
seemed to recompile. Never tracked down the details. Suspected the
fasl wasn't being written properly due to a spurious warning or the like.

Regardless, I have a fundamental issue with merging the functionality
of "make" with "load and execute". It is nice that they can be
coordinated, but wrong to think tight coupling should be the default.

- Daniel
From: Scott L. Burson on
On Jun 2, 6:34 pm, D Herring <dherr...(a)at.tentpost.dot.com> wrote:
>
> Regardless, I have a fundamental issue with merging the functionality
> of "make" with "load and execute".  It is nice that they can be
> coordinated, but wrong to think tight coupling should be the default.

I'm not sure I follow. Are you suggesting that ASDF, when asked to
load a system, should refuse to do so if it has not already been
compiled?

-- Scott
From: D Herring on
On 06/02/2010 09:42 PM, Scott L. Burson wrote:
> On Jun 2, 6:34 pm, D Herring<dherr...(a)at.tentpost.dot.com> wrote:
>>
>> Regardless, I have a fundamental issue with merging the functionality
>> of "make" with "load and execute". It is nice that they can be
>> coordinated, but wrong to think tight coupling should be the default.
>
> I'm not sure I follow. Are you suggesting that ASDF, when asked to
> load a system, should refuse to do so if it has not already been
> compiled?

That is one implication of my statement. While there are many things
to mock in the land of C, a "dumb" workflow can have advantages.

In particular, the classic "configure && make && make install"
sequence provides several useful hooks for the end-user to check that
things are working properly. Did configure find the right stuff? Did
make succeed? Am I ready to install to the default places used by
other programs? ...

Defsystems like ASDF seem to discourage anything but a single-hacker,
single-project mentality. In my experience, the C model allows
finer-grain mixing of libraries since I don't have to worry about
things changing underneath me. Its dumbness approaches the smart
immutability preached by Clojure.

That said, I see no need to perpetuate the GNU toolchain of autoconf,
automake, shell, make, cpp, cc, linker, loader, ... We can do
everything in one monolithic lisp; we just need to make the pieces
accessible individually as needed.

Later,
Daniel

P.S. Hope I'm not incoherent. Its very late now...
From: Captain Obvious on
DH> Regardless, I have a fundamental issue with merging the functionality
DH> of "make" with "load and execute". It is nice that they can be
DH> coordinated, but wrong to think tight coupling should be the default.

Isn't that a fundamental issue of Common Lisp?