Re: Make ordering (Re: namespace / typing thrash ...)

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.lunak@suse.cz