Hi there,
Being generally irritated by the apparent hang when running make (I
know, I know it is all faster in real terms than it used to be ;-) I was
poking at the dependency files in:
core/workdir/unxlngi6.pro/Dep/LinkTarget/Library
And - being of an ignorant nature, I was amazed to see them packed
half-full of a great mass of dummy / empty dependency rules like these:
/data/opt/libreoffice/core/solver/unxlngi6.pro/inc/tools/string.hxx:
/data/opt/libreoffice/core/solver/unxlngi6.pro/inc/osl/thread.h:
..
Using the attached perl script to remove these [ and I assume they are
truly redundant ;-] we get some quite interesting shrinkage (gnumake
profiles show most of its time parsing and hashing strings
interestingly):
core/workdir/unxlngi6.pro/Dep/LinkTarget/Library> du -k -c *.d.orig |
tail
12748 vbaobj.uno.so.d.orig
9720 vbaswobj.uno.so.d.orig
2096 vclcanvas.uno.so.d.orig
372 writerfilter_uno.uno.so.d.orig
603924 total
core/workdir/unxlngi6.pro/Dep/LinkTarget/Library> du -k -c *.d | tail
6424 vbaobj.uno.so.d
4904 vbaswobj.uno.so.d
1060 vclcanvas.uno.so.d
192 writerfilter_uno.uno.so.d
324084 total
ie. around 50% of the byte size is gone. That translates into:
* tail_build (clean make -sr / secs)
+ before: 33.964 33.842 34.902
+ after: 21.858 21.202 21.090
* sc (clean make -sr / secs)
+ before: 5.238 5.729 5.802
+ after: 4.195 4.184 4.195
Of course when using cvs gnumake (which has the other globbing win in
it - without which everything is far slower).
So - my question is: how are those library .d files created /
concatenated - and is there some existing script we could piggy-back on
to get rid of these.
Or are they there in fact there for some good purpose that I just
failed to spot ? :-)
Thanks,
Michael.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
Attachment:
cleanup.pl
Description: Perl program