> Thats too close to be a accidental. It seems like GNU make restats
> every target everytime it gets named as a dependency without any
> caching (or expecting the OS to do the caching).
And why wouldn't it? Make can not know that some files are typically static and
not modified by commands being run.
Consider the following Makefile (sorry this is a Windows-specific case, but the
first one I could think of). The top targets are a DLL and its import library.
These two targets are produced by the same command, the one that links the DLL.
ALL: foo.dll libfoo.dll.a
foo.dll libfoo.dll.a: foo.o
gcc -shared -o foo.dll foo.o -Wl,-out-implib,libfoo.dll.a
foo.o: foo.c
gcc -c foo.c
clean:
rm foo.dll libfoo.dll.a foo.o
Now, assume thre are old foo.dll and libfoo.dll.a files around, but foo.c has
been edited. If Make would cache stat calls, it would not have any reason to
believe that libfoo.dll.a indeed got updated, too, when foo.dll was produced by
its recipe, would it? So it would run the recipe once more.
Well, yeah, Make could reasonably assume that the command does indeed update
both foo.dll and libfoo.dll.a as both are targets of the command and the recipe
didn't contain $@. Or something like that. One probably can easily come up with
more heuristics that could be added to (GNU) Make and make it better in our
case. But if we start using a modified Make, we are back where we started, with
our own Make.
OTOH, http://savannah.gnu.org/bugs/?443 says "GNU make does have a directory
cache which is used for a significant performance advantage; much of the time
make spends is for doing stat(2) system calls" , hmm. Need to get the Make
sources and investigate.
--tml
_______________________________________________
LibreOffice mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/libreoffice
