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 <r...@novell.com> Novell, Inc. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
