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