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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
