Hi Michael,
On Mon, 05 Sep 2011 12:38:56 +0100
Michael Meeks <michael.meeks@novell.com>
wrote:
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.) [...]
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 ;-)
Yes, that is most likely because we generate the deps for each object,
but cat them together for each linktarget to reduce file-io later.
Instead of cat'ing the objects we could indeed pipe them trough some
cleanup script.
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 ?
Looking good from this perlhaters point of view. I would have written
it in awk for performance and lean-dependency reasons, but I am not
too zealous about that. To inject it to the build system, add it in
around here:
http://opengrok.libreoffice.org/xref/core/solenv/gbuild/LinkTarget.mk#401
Best,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.