[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-recursive build question

From: Noel Yap
Subject: Re: non-recursive build question
Date: Thu, 29 Apr 2004 10:07:15 -0400
User-agent: Mozilla Thunderbird 0.5 (Windows/20040212)

Paul D. Smith wrote:

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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]