Re: prerequisite staleness criteria

[David Boyce]

At 05:12 PM 4/17/2006, Dave Hylands wrote:
> It's quite useful to use this technique for any generated source files.

I just saw on another list where someone uses this technique to avoid 
relinking against DLLs on Windows. He does the 
save/compare/unlink-or-replace thing with the .lib file generated 
when building a DLL. I'm no Windows guru but as I understand it, this 
file contains the list of exported symbols. If the export list is 
unchanged, the original is put back in place so its date stamp is 
unchanged and make sees no need to relink all the executables against 
it even though the DLL itself will have changed.

Back on the original question, I toyed with delving into this a 
couple of years ago but then got too busy. My take is that though 
Paul is right of course about the complexities of persistence, GNU 
make should deal with it by refusing to deal with it. It seems to me 
that from make's point of view the task is simply to refactor the 
code such that all "staleness" determinations are made by a single 
discriminator function rather than a bunch of stat() calls scattered 
about as now. Then at startup make could do a quick check to see if 
an override discriminator is defined (this could be done with 
dlopen/dlsym on Unix and LoadLibrary et al on Windows, or just 
compiled in via a configure option). If an override is defined, the 
discriminator function pointer is set to that; otherwise it defaults 
to the traditional timestamp function. The override function is 
responsible for its notion of persistence, fallbacks, etc. This way 
people could cook up and propagate their own methods, ranging from 
something as simple as dropping little foo.md5 files for every foo to 
communicating with a central database.

David Boyce