[Libreoffice] oox/source/drawingml/customshapepresets.cxx is just (Offensive Word Found In Message) too much for gcc

Radek Doulík rodo at novell.com
Thu Oct 6 01:56:00 PDT 2011


I would also vote for not reverting stuff (at least not before we try
fix it first), when only some of the tinderboxes fail due low system

I will try to split the offending source file to few smaller files,
similar to what we do for some non-generated CXX sources, and push

One thing I noticed. It might be useful to run tinderboxes without gcc
optimization (ie. with -O0). It makes huge difference in compile time -
more than 10 times faster on my system and could make the tinderbox
turnaround much faster.

customshapepreset.cxx compiled with -O2
real	4m22.910s
user	4m13.794s
sys	0m9.996s

customshapepreset.cxx compiled with -O0
real	0m25.427s
user	0m25.242s
sys	0m1.035s


On Thu, 2011-10-06 at 11:18 +0300, Tor Lillqvist wrote:
> The only solutions I see are:
> 1) Either we should get some really really bad-ass Windows tinderbox,
> *and* make it use ccache (i.e. investigate whether kendy's port of an
> old ccache version really works correctly, or re-port a current ccache
> to support MSVC).
> 2) Or, we should have our developers mainly work on the "difficult"
> platforms, i.e. Windows, and to some extent MacOSX, so that they
> notice themselves when code they are writing will cause problems on
> these platforms. Only people mainly doing distro packaging would
> continue to work on Linux. Obviously "we" (for some value of "us")
> can't enforce that on volunteers, only bosses can on their paid
> developers ;)
> 3) Or, we should jump to 4.0 directly, and support only
> cross-compilation to Windows. (Yes, that means a lot of work needs to
> be done to avoid too many regressions in the form of missing
> features.)
> Obviously I am not really expecting you to take alternative 2 seriously.
> --tml

Radek Doulík <rodo at novell.com>
Novell, Inc.

More information about the LibreOffice mailing list