%% Noel Yap <[EMAIL PROTECTED]> writes:
ny> Yeah, I think we're saying the same thing but with different POV's.
ny> From my POV, GNU make now has two ways to specify the conditions ny> in which something is built due to one of its dependencies:
ny> 1. Normal dependencies: the LHS is built if the RHS's timestamp changes ny> 2. Order dependencies: the LHS is built if the RHS didn't exist
I still have to disagree with #2, although again it might be a wording thing (but words are important!)
In order dependencies, the LHS (target) is built IF AND ONLY IF the target is out of date as determined by any NON-order-specific prerequisites.
Whether or not the LHS is built is completely independent of any order dependency. In fact, the decision to build the LHS would be identical if the order-only dependency was not there at all.
You're absolutely right; my wording was completely off.
In the end, though, the OP should be able to do what he wanted (assuming IIUC) -- the .exp, .so, and executable are rebuilt only when necessary.
The neat thing with order rules that allows this is that the DAG for the RHS is attached appropriately to the main DAG, but the RHS's timestamp doesn't affect the LHS's rebuild.
The ONLY thing that an order-only dependency changes is the order in which targets are built. It never, ever changes _whether or not_ targets will be built.
This is true for the LHS, but not completely true for the RHS. It allows checking to see if the RHS needs to be rebuilt.
Without the order rule, the DAG wouldn't include the RHS at all.
ny> IMHO, it'd be great (although I wouldn't know what type of syntax ny> one could use) if one could define customized conditions (eg MD5 ny> hash changes, version changes, ...).
There is an order of magnitude difference between the suggestions you give here and what make currently does, and that is that all the ideas you give here require state to be stored. Make is currently stateless: it has no knowledge of when (or even if) it was ever run before and if it was, what happened then.
I didn't mean to imply that make proper would be doing the work of generating and checking the hash, version, etc. Rather, the developer who created the code for the condition would be responsible for coding it in such a way that it's able to retrieve and store this info somewhere.
In order to implement _ANY_ more advanced out-of-dateness condition than what we have now, make would first have to be enhanced to be stateful. Once that's done (assuming it was done in an extensible manner) you could conceivably have various types of state that would be checked. I would assume that MD5 hash would obviate any other type of change, since even if a version changes as long as the contents of the file haven't changed, why rebuild it?
However MD5 hashes are expensive (comparatively) to compute, so it might be more efficient to do something like store the TLM, and then do an equality comparison instead of a greater-than comparison... that way _ANY_ change to the TLM, including a move forward which still didn't make it newer than the target, or even a backwards change, would trigger a rebuild. This, for example, should be good enough for tools like ClearCase, for all practical purposes.
Yeah, MD5 is probably not a good choice for this. A cheaper-to-compute hash is more appropriate.
Do you think adding GUILE to make and allowing a hook to redefine the update condition would allow such extensibility? Anyway, just blue sky dreaming; the situations in which such a feature to be useful are extremely rare IME. YMMV, of course.
Thanks, Noel
_______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
