Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


On 31/01/13 14:33, Lubos Lunak wrote:
On Thursday 31 of January 2013, Michael Stahl wrote:
On 31/01/13 08:01, Michael Meeks wrote:
Hi guys,

    I was digging for the latest information on the size cost of our
dependencies, and was interested to see things like:

    workdir/unxlngi6.pro/Dep/LinkTarget/Library/libfwklo.so.d

    contain only lots of:

/data/opt/libreoffice/master/workdir/unxlngi6.pro/CxxObject/framework/sou
rce/accelerators/globalacceleratorconfiguration.o :$(gb_Helper_PHONY)
/data/opt/libreoffice/master/workdir/unxlngi6.pro/CxxObject/framework/sou
rce/accelerators/keymapping.o :$(gb_Helper_PHONY)
....
    It seems some clever person deferred the dependency generation until an
incremental build is done (?) :-) I assume that accelerates the
straight-through build too (?).

actually it makes a full build from scratch slower, expecially on
Windows writing thousands of .d files takes several minutes.

 It's not as bad when using the patched make (and it's slow because of process 
forking, making concat-deps a make builtin would presumably make that as fast 
as on Linux).

i haven't measured it but i guess the majority of the problem is first
writing the Object .d files, of which there are a lot more than
LinkTarget .d files.  which should make it easier because iirc object .d
files are just "echo foo: .PHONY > foo.d" while concat-deps has a bit of
LO-specific logic (rewriting external headers to .done files, which is
necessary for correctness of incremental builds) that doesn't make sense
as a make builtin.

the advantage is that you can do a partial build; with the old way of
doing things every object file in every module was built to include the
.d file even when you only want something like "make comphelper.all".

 Are you sure about this? From what I remember when doing the builtins for 
make, all .d files are first created with dummy content, so having or not 
having the LinkTarget .d files doesn't change anything there.

there were always LinkTarget .d files; the "old" way (since CWS
gnumake4) was to have the object .d files depend on the object files,
which causes make to compile everything because the first thing make
does is ensure included files are up-to-date.

this was reverted in commit 8b5a984d45005d3df1c89eae897d6e04612625d8
(plus numerous follow-ups to actually get it to work)

 As far as I understand it, the purpose of LinkTarget .d files is reading less 
files - gbuild includes only LinkTarget .d, not object .d files . And 
LinkTarget .d files are dummies (just like object .d files) during the first 
build, during that build object .d files are updated while building the 
targets, and before second build LinkTarget .d files are created from 
object .d using concat-deps.

yes.  not only reading less files, but also the content is de-duplicated
a bit nowadays.

the LinkTarget .d files are always created via concat-deps from Object
.d files, which leads to the result you describe.



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.