[Libreoffice] a faster gnumake ? ...

[Tor Lillqvist]

> 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