On Tuesday 17 of April 2012, Bjoern Michaelsen wrote: > On Tue, Apr 17, 2012 at 02:19:59PM +0200, Lubos Lunak wrote: > > I don't think it would hurt parallelism much, because the linking of svx > > needs to be done somewhen, and make should have enough of other stuff to > > do. On the other hand, I doubt such one change would change much. Could > > gbuild be changed so that each library target depends on its dependent > > libraries not only for linking, but also for compiling its sources? > > Yes, it could, but that would be throwing the baby out with the bath tub.
What baby? Is the library dependency tree in LO so narrow that the build would be repeatedly stuck waiting for just one library to be linked? > After all, all we want is _some_ linking to be done earlier. It is not some linking, it is all linking. The build will be the fastest if for each library the compiling and linking is done as close as possible. Recursive make, in fact, except that there should not be the problem of being unable to build unrelated targets in parallel. > Creating a > file DoNotLinkAllInTheEndHack.mk containing just a few "artificial" Deps > and include that would be enough: > $(call gb_Library_get_header_target,sw) \ > $(call gb_Library_get_header_target,swui) \ > $(call gb_Library_get_header_target,sc) \ > $(call gb_Library_get_header_target,sd) :| $(call > gb_Library_get_target,svx) > > without creating too much artificial dependencies. There's probably not going to be too much benefit either, if it's just few dependencies. Unless there is some ordering for sc/sd/sw, they will be all compiled and linked intermingled. Which means that using only inter-library dependencies is not enough. That also means that simple make patching probably won't do, and it'd need to be changed to prefer depth-first search for targets to build next. -- Lubos Lunak l.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice