Re: rebuilt 1 .cxx, linked 184 libraries

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