rebuilt 1 .cxx, linked 184 libraries
Bjoern Michaelsen
bjoern.michaelsen at canonical.com
Thu Apr 4 11:47:53 PDT 2013
Hi,
On Thu, Apr 04, 2013 at 02:11:35PM -0400, Terrence Enger wrote:
> I just changed vcl/source/window/builder.cxx and did top-level make.
> The make had 184 [build LNK] steps. Is this to be expected?
Yes, that is currently expected.
The chromium build system evades that, see "ld trick" in this post:
https://plus.google.com/101038813433650812235/posts/NAjqBW9rtSe
Now that we have everything in gbuild, we should be able to evade that too
rather trivially. Consider we have a two library a and b with a linking against
b. With a : b meaning a depending on b the dep graph looks like this (simplified):
$(call gb_Library_get_target,a) : $(call gb_Library_get_target,b) : some object from lib b : some cxx from lib b
thus recompiling a object always relinks the library (which makes sense), which
then causes all libs linking against it to be recompiled.
We could evade that with build order only deps (signified :|, see
http://www.gnu.org/software/make/manual/html_node/Prerequisite-Types.html ) and
with (simplified):
$(call gb_Library_get_target,a) :| $(call gb_Library_get_target,b)
$(call gb_Library_get_target,a) : $(call gb_Library_get_headers_target,b)
$(call gb_Library_get_target,b) : some object from lib b : some cxx from lib b
This would make library a being rebuild only if one of the 'public', delivered
headers of library b changed but not otherwise. And it would make sure, that if
both library a and b need to be rebuild, a will always be rebuild after b.
Ironically, that would require to explicitly track all the 'public' headers of
a library in gbuild -- which we do that right now as we need to copy them to
solver/ anyway, but we hoped to get rid of that with the big header move (see:
http://nabble.documentfoundation.org/moving-global-headers-into-one-top-level-location-td4047903.html).
So _if_ we go to get more intelligent on when to relink a lib, we would need to
keep the explicit 'external header' bookkeeping somehow.
Best,
Bjoern
More information about the LibreOffice
mailing list