Make ordering (Re: namespace / typing thrash ...)
l.lunak at suse.cz
Tue Apr 17 06:05:26 PDT 2012
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
> 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.
l.lunak at suse.cz
More information about the LibreOffice