[asdf-devel] Trying again

[Robert Goldman]

On 2/11/10 Feb 11 -11:11 PM, Faré wrote:
>> I think to be fair to James he's not saying that ASDF should DWIM, he
>> was asking for a minimum perturbation fix.
>>
> No, he's rejecting an actual fix to actually broken behaviour,
> in favor of something that's not specified and not specifiable,
> whereas anything meaningful and specifiable he could want can
> actually be achieved, better, in a well-specified ASDF,
> and cannot be achieved in any way whatsoever in a broken ASDF.
> 
> The ASDF specification language can already express dependencies
> and non-dependencies (just you define several systems, one
> for interfaces and one of implementations, or whatever).
> 
> e.g. in foo.asd:
> (defsystem foo :depends-on (bar foo-interface foo-implementation) ...)
> (defsystem foo-interface :depends-on (bar-interface) ...)
> (defsystem foo-implementation :depends-on (foo-interface) ...)
> 
>> What I took from this was that a minimum perturbation fix is to make
>> ASDF handle the easy case (INTRA-system module dependencies), test and
>> incorporate that fix and move on to a better fix later.
>>
> Isn't it actually simpler to fix everything once and for all?

I don't believe so, because I think there are some subtleties, and I'd
rather get this obviously busted behavior fixed right now.  Also, pace
the git-lovers, I don't like having a long-lived branch on the central
repository, because the updates aren't clean.
> 
>> The problem with doing the INTER-system dependencies is that I don't
>> believe that ASDF currently has the infrastructure to do The Right
>> Thing.  In order to do the right thing, each system would have to store
>> with itself information about the state of the dependencies when it was
>> built.
>>
> A timestamp is all you should be needing. What else do you need, really?

I need to think about this a little bit more.  In particular, I can
think of some issues that we should push our heads through:

1.  We need to understand clearly the two notions of correctness in
build --- correctness within a single lisp session and correctness
across lisp sessions.

2.  What do we do about a general solution?  I.e., how do we handle the
fact that the set of operations and components is extensible?  My bet is
that we should systematize what it means for an operation to be done,
rather than have operation-done-p just be arbitrary lisp code.  I mean
we should support standard definitions of operation-done-p: e.g., all
input files are newer than all output files, never (as for test-op),
etc.  Users would be free to fall back to arbitrary

3.  Currently there's a hard distinction between operation-done-p, which
only works on "internal" considerations and dependency management, which
is done by TRAVERSE.  I don't think this distinction is particularly
helpful.  At any rate it is nowhere clearly specified.

I'd like to see a quasi-formal spec roughed out before we move beyond
fixing the obvious bugs, and I don't have the time to do that right now
(or even to review such a spec), so I'd like to get the immediate
irritant --- the intra-system dependency bug --- removed now.

Cheers,
r