rebuilt 1 .cxx, linked 184 libraries

[Terrence Enger]

On Thu, 2013-04-04 at 20:47 +0200, Bjoern Michaelsen wrote:
> 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

I had imagined that library a would be rebuilt because some object in a
got rebuilt because it depended on a changed header in b.  Ah well, it
just goes to show that there is a lot that I do not know.

Actually, it is a tribute to the project and to the build system in
particular that I am able to hack around with so little knowledge.

> 
> 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

Thank you, Bjoern, for the excellent explanation.

Terry.