Re: [Libreoffice] a faster gnumake ? ...

> 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