On 09/02/2022 08:03, Stephan Bergmann wrote:
On 04/11/2020 16:31, Stephan Bergmann wrote:
Since
<https://git.libreoffice.org/core/+/f23aa1a51cb1beea4ebe3a61ba0c9b3abd844fd9%5E!/>
"Bump compiler plugins Clang baseline to 5.0.2" from about two years
ago, the baseline for (Linux) --enable-compiler-plugins builds is
Clang 5.0.2.
Wasting time yesterday with
<https://gerrit.libreoffice.org/c/core/+/105234/1..4>, tracking down
why a loplugin:toolslong false positive started to appear with old
Clang, I wondered whether we could bump once again. The benefit would
be getting rid of various #if CLANG_VERSION cruft across
compilerplugins/clang/, and potentially avoiding wasting time on
similar issues in the future. (Plus, we could revisit
<https://lists.freedesktop.org/archives/libreoffice/2019-November/083780.html>
"On using C++17 for compilerplugins (not possible for now)".)
The question is what the maximum Clang version would be that we could
bump to as a baseline for (Linux) --enable-compiler-plugins builds.
(For (implicit) --disable-compiler-plugins builds, baselines can stay
as they are for now. And on macOS and Windows, I think I am the only
one using --enable-compiler-plugins, and I'm using Clang trunk there
anyway.)
So, what is the maximum Clang version that people would be comfortable
with here?
lode already happens to provide a recipe to install Clang 9.0.1 on
Linux. so my suggestion---absent other constraints---would be to at
least bump to Clang 9, somewhat randomly.
as discussed on #libreoffice-dev yesterday:
Feb 08 09:45:59 <sberg> vmiklos, last time I brought up "Bump
--enable-compiler-plugins Clang baseline?" back in 2020, you asked for
Clang 7 for openSUSE; is that still what you'd ask for as a baseline?
(maybe I'll finally find time to actually bump anything there...)
Feb 08 09:50:03 <vmiklos> sberg: today openSUSE has clang 12 (vs
only 7 in the past)
Feb 08 09:51:18 <sberg> noelgrandin, ^ and you asked for Clang 10
for Ubuntu, what's your ask now?
Feb 08 09:51:51 <noelgrandin> sberg, I run clang trunk, that I
compile myself
Feb 08 09:52:06 <noelgrandin> but kendy I think uses clang from
Ubuntu or some such
Feb 08 09:52:24 <noelgrandin> current Ubuntu has clang 13
Feb 08 09:52:50 <sberg> ok, then lets settle on 12 for now, lets
see if I get that working on the jenkins machine
An implementation is now available at
<https://gerrit.libreoffice.org/c/lode/+/129705> "Bump
linux_clang_dbgutil_64 to Clang 12.0.1". I'll bring this proposed
baseline bump up in the next ESC meeting.
But rolling this out on Jenkins has some preconditions (see that Gerrit
change's commit message): "For this to work, the
<https://ci.libreoffice.org/label/linux_clang_dbgutil_64/> machines must
have
<https://git.libreoffice.org/lode/+/b898c10233300052925cad8e4c78f07425f3fb08%5E!/>
"Move setting COMPILER_PLUGINS_CXX from core to lode" (resp. its fixup
<https://git.libreoffice.org/lode/+/da00185f0111e1f52c0f9a894bca4bc8695cbdb5%5E!/>
"Fix quoting in previous commit") installed, and Gerrit changes built
with that configuration must have
<https://git.libreoffice.org/core/+/a45f057d9d2bcd28e6b4342bbdf45fec38a43ac1%5E%21>
'Remove COMPILER_PLUGINS_CXX from
distro-configs/Jenkins/linux_clang_dbgutil_64'."
I have already updated the lode repo on all the relevant Jenkins
machines (except for the offline hc-1). But what is needed is to make
sure that all the Gerrit changes include that core commit, on all the
branches that are built with that Jenkins configuration (Cloph, is that
libreoffice-7-2, libreoffice-7-3, and master?). My suggestion would be
to backport that core commit to all the relevant branches, wait for say
a week (to increase chances that Gerrit changes will contain that
commit), and then to submit
<https://gerrit.libreoffice.org/c/lode/+/129705> "Bump
linux_clang_dbgutil_64 to Clang 12.0.1" to lode and update the setup of
the relevant Jenkins machines accordingly. (If a Gerrit change still
doesn't include the relevant core commit then, it will fail the Jenkins
gerrit_linux_clang_dbgutil build step quickly, and will need to be rebased.)
