[asdf-devel] Trying again

Faré fahree at gmail.com
Fri Feb 12 05:11:05 UTC 2010


> 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?

> 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.

> The advantage of my currently-committed patch is that, I believe, it
> confines itself to a single case where The Right Thing is not debatable
> --- I don't think *anyone* could make a case for the current ASDF
> behavior, nor against the behavior that I've added.
>
I admit I haven't looked at it yet.

> I don't think James's arguments mitigate against pushing my modification
> onto the trunk, either.  Again, the argument is that the current changes
> are not sufficient, not that they are wrong.
>
Indeed.

> Unless I hear a serious argument against doing this by the end of the
> day tomorrow, I will push the fix for INTRA-system module dependencies
> into the trunk and kill the module-depends branch.
>
Thanks!

> THEN we can go ahead and figure out how to fix INTER-system dependencies.
>
I say fix it just the same.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
Nostalgia isn’t what it used to be.




More information about the asdf-devel mailing list