Hi there, On Mon, 2011-09-05 at 11:36 +0100, Caolán McNamara wrote:
On Fri, 2011-09-02 at 21:22 +0100, Michael Meeks wrote:Or are they there in fact there for some good purpose that I just failed to spot ? :-)Yes, I added all these deliberately. See http://www.makelinux.net/make3/make3-CHP-8-SECT-3 for the rationale.
Ah indeed :-)
The outcome is that on incremental builds when someone removes a header and nothing includes it anymore, the build doesn't break with some bizarro error but "does the right thing". For me the build-time difference is negligible but I guess its significant for others.
So that is great. Of course the build-time difference is indeed
negligable, but the incremental build time impact is quite real.
So - we need these rules in place; with a small tweak to my script to
print the dummy rules we'd be throwing away, I notice that we have (eg.)
483 /data/opt/libreoffice/core/sc/inc/rangelst.hxx:
634 /data/opt/libreoffice/core/sc/inc/address.hxx:
719 /data/opt/libreoffice/core/sc/inc/global.hxx:
797 /data/opt/libreoffice/core/sc/inc/scdllapi.h:
several hundred duplicate dummy rules for many headers - still
consuming big chunks of the aggregated library dependency files. That
yields 441k redundant lines instead of 445k - but I think that's most of
the win ;-)
I attach an updated cleanup.pl - that leaves the dummy rules, but
removes duplicates in them; it takes a second or two to run itself ;-)
[ we could write it in C no doubt to accelerate it if that is an issue
]. Which gmake rule builds the aggregated library dependency file that
could have this wedged into it ?
Thoughts ?
ATB,
Michael.
--
michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot
Attachment:
cleanup.pl
Description: Perl program