> 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 _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
