On Saturday 18 of May 2019, Luboš Luňák wrote:
On Friday 17 of May 2019, Thorsten Behrens wrote:
Yeah, same anecdotal evidence here. Is the assumption we don't need
more Mac build power based on hard data?
IIRC one Mac bot had some problems a couple of days back, so maybe the
increased Mac load was just caused by catching up there (I certainly
remember waiting for those to finally pass). If I right now look at gerrit
master builds in progress, none of them is currently waiting exclusively
for Mac, but some of them are for Windows.
BTW, I've noticed that all setups except for gcc use --enable-dbgutil, which
in turn by default does --disable-optimized. Given that Jenkins builds also
run all checks and that takes time that cannot be avoided/cached in any way,
wouldn't it be in total faster to go with --enable-optimized? I'm not sure
how that'd turn out with the Windows build, but at least the ccache-enabled
ones could easily gain on that. I know unittests also try to print out a
backtrace if they crash, but do we need that for Jenkins builds? Quite
possibly adding --enable-optimized --disable-symbols could save quite some
build power.
Also, every build has to build all the stuff in external/, over and over
again. That shouldn't matter much with ccache, but presumably the Windows
build spends quite some time there. We could try some silly^H^Hinteresting
improvements there, such as adding PCHs even for those.
--
Luboš Luňák
l.lunak@collabora.com
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.