On 18/02/2020 13:17, Luboš Luňák wrote:
On Tuesday 18 of February 2020, Stephan Bergmann wrote:
You left it somewhat unclear what the target audiences for your various
performance improvement proposals are (local builds, Gerrit Jenkins
builds, other tinderbox builds, "official" TDF release builds, ...).
I assumed it was implied where it mattered. Using --enable-debug/dbgutil is
for developer builds, isn't it?
...but then you mentioned "Windows Jenkins builds" with regard to
--enable-python=system in your previous response. Probably better to
spell things out explicitly.
Using --enable-python=system for Gerrit Jenkins builds would trade
significance of those builds ("will a release build with this change be
good?") for build performance.
Strictly speaking, no Jenkins build does that except for the Linux GCC
release one, as all the others build with --enable-dbgutil, so I find this
argument weak. In practice it seems it's the tinderboxes that check this (if
at all).
Still, I would prefer it if we keep the differences between Gerrit
Jenkins and "official" TDF builds as meaningfully small as possible.
The motivation for --enable-dbgutil deviation is certainly different
from the motivation for --enable-python=system deviation. Deviation
motivated by build performance should IMO only be a last resort.
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.