Thanks to both you and Mr. Patton for your responses. >-----Original Message----- >From: Paul Smith [mailto:[EMAIL PROTECTED] On Behalf Of Paul D. Smith >Sent: Monday, April 17, 2006 3:01 PM >To: Lawrence, Lynne >Cc: [email protected] >Subject: Re: prerequisite staleness criteria > >%% "Lawrence, Lynne" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >
_______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
