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