On 15/02/2022 11:00, Stephan Bergmann wrote:
On 11/02/2022 15:37, Stephan Bergmann wrote:
For another, as discussed in yesterday's ESC meeting,
+ Any objections to make that also the general Linux Clang
baseline?
+ no objections (all)
we'll also bump the Linux Clang-w/o-loplugin baseline to 12.0.1 at
that point. (Otherwise, we would no longer have a Gerrit Jenkins
builder that builds against that baseline, potentially silently
breaking master for people who still use that baseline. That way, we
will potentially silently break libreoffice-7-2 and libreoffice-7-3
for people who still use those branches' baselines, though; but
chances of actual breakage should be relatively low.)
Ach, and then there's Android, which I keep forgetting about.
All our Gerrit Jenkins Android builds (aarch64, arm, x86, x86_64) appear
to be done with Clang 8.0.7 (e.g.,
<https://ci.libreoffice.org/job/gerrit_android_aarch64/14741/> "checking
whether Clang is new enough... yes (8.0.7)"). Cloph, is that correct?
So what we could do is bump the Linux (incl. Android) w/o-loplugin
baseline from 5.0.2 to 8.0.7 (and only bump the with-loplugin baseline
to 12.0.1). That way, we would still have Gerrit Jenkins builds that
build against the baseline (even though only on Android), to catch
problems with Gerrit changes that would no longer build against the
baseline.
For that, we would presumably need to bump master README.md
* Android:
* Build: NDK r19c and SDK 22.6.2
to whatever NDK and SDK combination would provide at least Clang 8.0.7.
Would anybody see any problems with such an Android baseline bump? And
could anybody (Cloph?) please provide the details what the new baseline
versions in README.md should be (maybe the versions that are actually
used on the Jenkins machines)?
Though, taking another look at this, LLVM never released a "Clang
8.0.7", so it's a bit unclear to me what that would be exactly. There
only ever was LLVM/Clang 8.0.1, according to <https://releases.llvm.org/>.
If I download
<https://dl.google.com/android/repository/android-ndk-r19c-linux-x86_64.zip>
(the version referenced in our README.md),
$ android-ndk-r19c/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --version
Android (5058415 based on r339409) clang version 8.0.2 (https://android.googlesource.com/toolchain/clang 40173bab62ec746213857d083c0e8b0abb568790) (https://android.googlesource.com/toolchain/llvm 7a6618d69e7e8111e1d49dc9e7813767c5ca756a) (based on LLVM 8.0.2svn)
[...]
and if I download
<https://dl.google.com/android/repository/android-ndk-r20b-linux-x86_64.zip>,
$ android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang --version
Android (5220042 based on r346389c) clang version 8.0.7 (https://android.googlesource.com/toolchain/clang b55f2d4ebfd35bf643d27dbca1bb228957008617) (https://android.googlesource.com/toolchain/llvm 3c393fe7a7e13b0fba4ac75a01aa683d7a5b11cd) (based on LLVM 8.0.7svn)
[...]
so:
* It looks like those Android Clang builds have their own versioning
scheme different from the upstream LLVM/Clang scheme.
* Our current Android baseline Clang (from NDK r19c, reporting "clang
version 8.0.2") is hopefully new enough that it actually is on-par or
even beyond an upstream LLVM/Clang 8.0.1.
With that, my suggestion would now be to bump the Linux (incl. Android)
w/o-loplugin baseline to 8.0.1 (rather than that oddball 8.0.7), and
keep the Android build baseline as-is at "NDK r19c and SDK 22.6.2"
(whose Clang reports 8.0.2 and would thus pass the bumped 8.0.1 check in
configure.ac, at least nominally, and hopefully also functionality-wise).
