Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


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.



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.