[Top][All Lists]

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

Re: non-recursive build question

From: Sandy Currier
Subject: Re: non-recursive build question
Date: Thu, 29 Apr 2004 16:54:36 -0400

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

reply via email to

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