[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
Hi,
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
resources.
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
again.
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
Cheers
Radek
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