On 2/12/10 Feb 12 -4:48 AM, james anderson wrote:
good morning;
On 2010-02-12, at 06:11 , Faré wrote:
[...]
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?
Pace Daniel H, I don't believe that timestamps on files is sufficient to do this. We have developed an API based on operation-done-p, and I don't believe that operation-done-p is sufficient for this. Timestamps on files is sufficient for make, but I'm not confident it's sufficient for ASDF. At any rate, I believe that we need to go through a process of making proposals about a protocol that will do the right thing, and then move on.
Maybe the current timestamps in ASDF are somewhat lacking, but that doesn't mean timestamps can't solve the issue. I think that one timestamp per pair (op component) should do the trick, stored as an alist (op timestamp) in a slot of the component.
is that not what the `operation-time` cache[1] is already there to do? (traverse x operation-done-p) reads as if module-level "done-p" is hard-coded[2] with logic, which is different than that for components in general, and which does not act on this cache. perhaps some protocol additions would work here.
One problem is that this cache does not survive across lisp sessions, so we can't appeal to it to establish correctness when our lisp first starts up (unless we add code to populate the cache with inferred compilation times).
A second problem is that there are two meanings to performing an operation on a system, and these two meanings need to be teased apart. (I don't believe this distinction is helpful.)
One meaning is the intuitive one: to operate on a module is to operate on all of its components. The second is the less intuitive tree walking one: there is a tree node that corresponds to operating on the module proper, and we do the operation by calling PERFORM on the operation and module objects.
With respect to your point about module level done-p being hard-coded, I agree --- I discussed this in terms of the distinction between operation-done-p and traverse, in my earlier response to Faré. Note that the unhelpful dual definition of performing an operation on a module almost forces this distinction.