Re: non-recursive build question

[Paul D. Smith]

%% Noel Yap <address@hidden> 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.

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.

  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.

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.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist