good morning;
what is a 'dependency'? the word makes my head spin. in a build system, three things contribute to the completion state of any given node with respect to a given operation.[1] [nb. i refrain here from using the term 'depends on'.] - any intrinsic performance. eg, for a system, the up-to-date instantiation of the system definition or for a source file, that it compiled. - the performance with respect to internal constituents. eg, for a group (that is, a system or a module), the 'components'. - the external requirements. eg, as expressed in .asd as :depends-on or :weakly-depends-on
the determination for a given node depends on the intrinsic evaluation and on evaluations delegated to constituents and requirements. the internal determination is customarily, effectively atomic. the others are unclear. in particular, whether and in which manner the completion state of external requirements is transitive is a 'completely open question'. the answer, below, reads as if the state propagates from external requirements in some selective, but unspecified, manner. otherwise changes to foo-implementation would indicate the foo-interface had changed, which would be seen by foo- user as an indication that it itself was not complete.
this needs to be made explicit. the present definitions express only the user-to-requirement propagation rules. this problem demonstrates that one must also be able to describe the inverse propagation rules. in that the description of a system must include the rules for completion state propagation for respective operations. maybe that applies to modules as well? maybe that applies even to the level of components? eg for a source file changes to function, macro, ... definitions.
--- [1]: http://github.com/lisp/de.setf.asdf.x/blob/ 285a38e4ee18e10b5ce887d8ab2dd5e2d352aa0a/asdf-x.lisp#L2152 On 2010-02-11, at 05:38 , 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).
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.
[Fare: is your XCVB going to handle the kinds of inter-system issues I raised in my earlier email?]
XCVB does the Right Thing of correctly invalidating any object any dependencies of which has changed. On top of that, you can do whatever you want.
Feeling like Richard III, I can only say "A spec! A spec! My kingdom for a spec!"
I think ASDF should, like XCVB, do the Right Thing, which is obvious: a dependency is a dependency. Just like any build system on earth does. Just because legacy ASDF is broken doesn't mean it should remain so. Incremental builds are broken with ASDF, and that's a shame.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http:// fare.tunes.org ] There is no excuse for a programming language without clean formal semantics. For even if your language is not designed for formal reasoning by computers, there will still be humans who'll have to reason about programs.
asdf-devel mailing list asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel