Re: non-recursive build question

[Sandy Currier]

> That I don't know about; you could well be correct--I hope Sandy will
> provide a list of explicit requirements that we can use to determine
> that because I, at least, don't have any good feeling for exactly what
> they are.

Ok, I will try to do this real soon, but for some strange reason I _really_
wanted to add my $0.02 to this sub-thread now.  (I had sent email to somewhere
for this gmake feature about 4 years ago...)

>   ny> I didn't mean to imply that make proper would be doing the work of
>   ny> generating and checking the hash, version, etc.  Rather, the
>   ny> developer who created the code for the condition would be
>   ny> responsible for coding it in such a way that it's able to retrieve
>   ny> and store this info somewhere.
>
> That's an idea.  I was kind of thinking that make would offer to save a
> token in its own directory structure representing the "state" of the
> target.  This token would be generic; maybe a union of a void* and a
> long unsigned or something.  That way make could avoid keeping duplicate
> structures representing files.

As per my old email, I was thinking of a .<target>.sig file or some such.
Whenever a target's rules are run _and_ the target is created/exists, make
would update the .<target>.sig file with some user defined signature, 
out-of-the-box either MD5, TLM, or whatever.  Then under user control
(yet another option), when make did the update check, it would use the
.<target>.sig file instead of a stat.  If the .sig file did not exist, it would 
be
nice to default to the stat.

One thing that would be really cool is if a hash is also taken of the entire,
expanded target rules and included that in the .<target>.sig file as well.  This
way, if say a macro was changed that is referenced in the target rules,
say changing CFLAGS from "-O2" to "-O3", then make could
determine that the target rules have changed and rebuild the target.

!

With these two enhancements, make would handle some of clearmake's
functionality.  And it would be soooo cool.

I would imagine that the user could define either an external function or
use either the internal mtime or MD5(?) function.  The hash of the target
rules themselves could just be a MD5 - it may not be that time expensive
for such a small piece of data.

>   ny> Anyway, just blue sky dreaming; the situations in which such a
>   ny> feature to be useful are extremely rare IME.  YMMV, of course.
>
> Actually in my "real life" job I'd love to have this capability--I think
> it could be (part of) a very, very significant savings in developer
> productivity.  Maybe someday I'll convince my managers in that life to
> let me work on it :).

I would love it too.  This way, when the SCM system sync's a workspace
back in time, things would rebuild.  And in particular, as with the reason
that started this thread in the first place, by using a MD5, if the contents
of the file did not change, even if the mtime did, then downstream
dependencies do not get rebuilt.  Oh, it would be so cool.

just my $0.02
-sandy