RE: prerequisite staleness criteria

[Lawrence, Lynne]

 Thanks to both you and Mr. Patton for your responses.

>-----Original Message-----
>From: Paul Smith [mailto:address@hidden On Behalf Of Paul D. Smith
>Sent: Monday, April 17, 2006 3:01 PM
>To: Lawrence, Lynne
>Cc: address@hidden
>Subject: Re: prerequisite staleness criteria
>
>%% "Lawrence, Lynne" <address@hidden> writes:
>
>  ll> Is there a way, with GNU make, to alter the criteria it uses to
>  ll> test whether a prerequisite is stale?
>
>No.  This is something that is often requested, but is still 
>on the TODO
>list.
>
>  ll> For instance, when determining whether to copy a file 
>from a build
>  ll> directory to an install directory it would be convenient to copy
>  ll> only if the file checksums differ, regardless of whether the file
>  ll> in the build directory is newer.
>
>Although on the surface it might seem like it's simple to 
>implement this
>just by replacing the current stat() of the file with 
>something else, if
>you think carefully you'll see that this is actually a major change.
>
>Currently we compare the timestamp of the target with the timestamp of
>the prerequisite.  The key thing to understand about this is that these
>timestamps are stored by the filesystem, and we're comparing different
>files to each other so they all exist at the same time: make just asks
>the filesystem for them every time it is invoked.
>
>
>If you wanted to switch to another method, say comparing checksums, now
>you're comparing the current state of a given file with its PREVIOUS
>STATE... so now that previous state has to be stored somewhere!
>
>I call this "stateful make"; it really doesn't matter what the contents
>of the "state" is: now you have to have make creating and maintaining
>some kind of database every time it is invoked so that the next time
>it's invoked it can see what's changed.  Obviously this "database" can
>be very simple; any implementation capable of a standard key/value
>lookup is acceptable (even something like one state file or symlink per
>target).
>
>Nevertheless, there's a lot of additional complexity here.  What if the
>DB is non-existent or corrupted?  What do we do about multiple 
>instances
>of make running in the same directory and updating files there--even in
>parallel if you use -j (concurrency/locking/etc.)
>
>
>Still, this would be a great feature.  Someone will certainly implement
>it, someday ... :-/ :-).
>
>-- 
>---------------------------------------------------------------
>----------------
> Paul D. Smith <address@hidden>          Find some GNU make tips at:
> http://www.gnu.org                      http://make.paulandlesley.org
> "Please remain calm...I may be mad, but I am a professional." 
>--Mad Scientist
>