On 2/10/10 Feb 10 -10:38 PM, Faré wrote:
On 10 February 2010 18:27, Robert Goldman rpgoldman@sift.info wrote:
OK, I have just pushed an alternative solution to the module dependency bug, this one (I believe) only triggered by INTRA-system dependencies. This one is also on the module-depends branch.
A test! This requires a test case in the test suite (and not a suit in the suitcase).
Correct. We need a test where there's an inter-system dependency, we modify an upstream system and we check to see what is done.
This was achieved, as I said, at the cost of some hair, but I believe it does the right thing to the extent that I understand the right thing, and thinking about James's email convinced me that I /don't/ understand what is the right thing with respect to inter-system dependencies.
I think you do understand the right thing, and that James is wrong to want ASDF to somehow DWIM. If you want to distinguish in code into parts that are depended on and parts that are not, then split your code into two systems. System foo-interface provides the interface, with packages, macros, specials, types, classes, gfs, and anything that matters at compile-time. System foo-implementation provides the implementation, with everything else. Clients depend on foo-interface and get recompiled if the interface changes. The overall system depends on interface AND implementation.
In other words, on top of a system that does the Right Thing(tm), i.e. invalidate dependencies recursively, you can do whatever you want, though it may take some effort. On top of a broken system, you always and forever have something broken.
Somewhat disappointingly, this commit agrees with the last one on the tests, which indicates that the tests need to be augmented...
Additional reviews very welcome as are test results!
No time for that right now. Hopefully tomorrow.
I think to be fair to James he's not saying that ASDF should DWIM, he was asking for a minimum perturbation fix.
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.
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.
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.
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.
You and I are in agreement that the behavior I've added is necessary but not sufficient. I don't think the fact that the current fix fails to handle INTER-system dependencies should be allowed to keep us from fixing INTRA-system dependencies.
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.
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.
THEN we can go ahead and figure out how to fix INTER-system dependencies.
Best, r