Re: deps etc.

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.