[Libreoffice] Windows (MSVC) incremental build is broken.

Jan Holesovsky kendy at suse.cz
Sun Dec 4 17:28:37 PST 2011


Hi Bjoern,

Bjoern Michaelsen píše v Čt 01. 12. 2011 v 09:21 +0100:

> > And reverting
> > http://cgit.freedesktop.org/libreoffice/core/commit/?id=28275d470f3a062cfa27d72bbf89328af1e83c68
> > fixes it.  I haven't pushed the revert yet since I don't know the
> > intent of this commit.
> 
> Please push, the commit was the result of a misunderstanding between kendy and me.

Well - the misunderstanding was only part of that.  I did that because
the build was broken ;-) - and my commit fixed the clean builds.
Unfortunately, it OTOH broke the incremental build of the gbuild-based
modules, sorry for that.

Either way, fixed now (see the other mail).  For those who are
interested in the gory details:

>From the last Monday, every module (even the build.pl-based ones) is
routed through gbuild when you do 'make' in toplevel.  Unfortunately,
gbuild has a sideeffect - it rewrites the OUTDIR set in Env.Host.sh from
the Windows path to Unx path (C: -> /cygdrive/c), and does that so that
such a setting is then used in the subsequent build.pl call.  Most of
the build.pl-based modules survived that just fine (or broke so that it
did not affect the build.pl exit value), only glib stopped with an
error.  So I removed the gbuild's sideeffect, which fixed the clean
build; unfortunately that broke the incremental build.  I thought the
dependency generation was the problem, but it is deeper - already the
path rewriting mechanism of gbuild (the R=XY ; S=$R/AB etc.) relies on
several assumptions that are fulfilled only with the Unx paths.  Would
be good to unwind that; or at least be aware of that when the
setsoenv.in is killed.  My preference would be to set the OUTDIR etc. to
the 'right value' from the very beginning, whatever the 'right value'
stands for :-)

Regards,
Kendy



More information about the LibreOffice mailing list