Re: non-recursive build question

[Noel Yap]

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