[Libreoffice] make dev-install hangs

[Bjoern Michaelsen]

On Wed, Dec 21, 2011 at 07:29:06PM +0100, Jan Holesovsky wrote:
> I see the same hang as Miklos; huge ram here too.  I'm using stock make
> 3.82 - can we disable this additional toplevel gbuild, as you say that
> it ends up doing nothing anyway?

Well, it _should_ do nothing. But for example on Ubuntu Precise (with gcc
4:4.6.2-2ubuntu1) it does something: it fails, while I have not observed it to
do so on Ubuntu Oneiric (with gcc 4.6.1-9ubuntu3). This ssems to be because the
new gcc version automagically makes relative paths out of the deps which is a
Bad Thing(tm) as building from a module and building from toplevel are suddenly
incompatible. As in the end we want to build from gbuild toplevel anyway (when
buildpl is dead), it is good not to let that scenario bit rot. There were some
more breakages, which already sneaked in, but I already fixed most of them in
that week before branchoff. This should be fixed on master now because as I
told Norbert about it and he took care of it in his concat-deps.pl replacement,
but it currently still hits me on -3-5.

Quick workaround: Add the affected target (dev-install) to
post_SpeedupTargets.mk. Those dont do anything in the gbuild phase then. You
can do that for "dev-install" (as it is not a target used in modules), but not
for things like "build" -- otherwise they will not do nothing when building the
module too, which would break you build (as build.pl still wanders through all
modules).

But this isnt the whole story: Once others will also that gcc version, they
will hit this bug too and there are real-world scenarios were this hurts: Doing
a full build (which builds all tail_build modules from one dir) and then doing
a build in one module of tail_build only will still be broken on -3-5 with that
gcc version and other people might start using that on the release branch too
soon. So: 

 What do we do about the -3-5 branch? Backport Norberts concat-deps.c?

For my release build, I ignore deps for now as they are only interesting for
rebuilds. But thats just a packagers hack, not something for upstream IMHO.

> I'm afraid it won't help with the
> broken deps, because as long as it builds, nobody will notice something
> is wrong ;-)

Well, with gcc 4.6.2 it breaks here now (on -3-5). While I am unhappy about
that, I am happy that it is detected -- I dont want to have to fix lots and
lots of accumulated bit rot bugs once we switch fully to gbuild. Esp. those
hard to hunt down cases like "dependencies look slightly different from top an
module build". That btw was the motivation behind all those messy build system
changes.

Best,

Bjoern