[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
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
- re: non-recursive build question, sandy currier, 2004/04/27
- re: non-recursive build question, Paul D. Smith, 2004/04/27
- Re: non-recursive build question, Sandy Currier, 2004/04/27
- Re: non-recursive build question, Paul D. Smith, 2004/04/28
- Re: non-recursive build question, Noel Yap, 2004/04/28
- Re: non-recursive build question, Paul D. Smith, 2004/04/29
- Re: non-recursive build question, Noel Yap, 2004/04/29
- Re: non-recursive build question, Paul D. Smith, 2004/04/29
- Re: non-recursive build question, Noel Yap, 2004/04/29
- Re: non-recursive build question, Paul D. Smith, 2004/04/29
- Re: non-recursive build question,
Sandy Currier <=
- Re: non-recursive build question, Noel Yap, 2004/04/29
- Re: non-recursive build question, David Boyce, 2004/04/30
- Re: pluggable out-of-date (Was: non-recursive build question), Noel Yap, 2004/04/30
- Message not available
- Re: pluggable out-of-date (Was: non-recursive build question), Noel Yap, 2004/04/30
- Re: non-recursive build question, Boris Kolpackov, 2004/04/29
- Re: non-recursive build question, Paul D. Smith, 2004/04/29
- Re: non-recursive build question, Boris Kolpackov, 2004/04/29
- Re: non-recursive build question, sandy currier, 2004/04/28
- Re: non-recursive build question, Noel Yap, 2004/04/28
- Re: non-recursive build question, Paul D. Smith, 2004/04/29