[fuck gmail; this was meant to go to libreoffice@lists.freedesktop.org
not libreoffice-qa@lists.freedesktop.org]
-------- Forwarded Message --------
Subject: Compiler baselines (was: [Libreoffice-qa] minutes of ESC call ...)
Date: Tue, 24 Jul 2018 12:28:21 +0200
From: Stephan Bergmann <sbergman@redhat.com>
To: libreoffice-qa@lists.freedesktop.org
On 19/07/18 16:50, Michael Meeks wrote:
* GCC 4.8 support no longer needed for master by City of Munich (Michael W)
+ prolly the only ones still using this vs. master.
+ 6.1 is the last one built for Ubuntu 14.04
+ new base-line is Ubuntu 18.04
+ gcc 7
+ would also require bumping base-line on TDF linux builds (Christian)
+ ideally wait for Stephan (Michael)
+ this may help wrt. C++ features, the VS 2017 upgrade didn’t much (Miklos)
+ due to older gcc baseline.
+ CentOS6 – continues until 2020, CentOS 7 til 2024 (Christian)
+ would like to build more KDE on a newer baseline (Thorsten)
=> when Stephan is back.
So what would we gain re C++11/14/17 support if we bump the current
master (towards LO 6.2) Linux GCC baseline from 4.8.1 to, say, 7?
One limiting factor is MSVC, where---IIUC---our current baseline is VS
2017 15.0 (aka 19.10), but many features are only available in later
15.x (aka 19.y), see
<https://en.cppreference.com/w/cpp/compiler_support>. Is there any good
reason to stick with an older version of VS 2017, or could we require
the latest version (which appears to be 15.7 aka 19.14) or at least the
second-latest one (15.6 aka 19.13)?
According to the feature matrix at
<https://en.cppreference.com/w/cpp/compiler_support>, bumping to GCC 7
and MSVC 2017 15.7 would give us almost complete C++17 support, which
would of course be a great step forward. Staying at MSVC 2017 15.0
would limit that substantially. (Clang has never been a limiting factor
in recent years. I didn't check now, but would assume that our
macOS/Xcode baseline is recent enough to provide all the features.)
As an example, the relevant feature-test macros we currently have in
config_host/config_global.h.in would be satisfied as follows:
* HAVE_CXX14_CONSTEXPR: yes (GCC 5, Clang 3.4, MSVC 19.10, "Extended
constexpr" at <https://en.cppreference.com/w/cpp/compiler_support#cpp14>).
* HAVE_GCC_PRAGMA_OPERATOR: yes (GCC 4.3, Clang, MSVC 19.0, "C99
preprocessor" at
<https://en.cppreference.com/w/cpp/compiler_support#cpp11>; so this
should already be satisfied today).
* HAVE_GCC_DEPRECATED_MESSAGE: yes (GCC 4.9, Clang 3.4, MSVC 19.0,
"[[deprecated]] attribute" at
<https://en.cppreference.com/w/cpp/compiler_support#cpp14>).
* HAVE_BROKEN_CONST_ITERATORS: yes (see "We should be able to drop the
below check when bumping the GCC baseline to 4.9 [...]" in configure.ac).
* HAVE_GCC_ATTRIBUTE_WARN_UNUSED: yes, if we don't stick to MSVC 15.0
(GCC 7, Clang 3.9, MSVC 19.11, "[[nodiscard]] attribute" at
<https://en.cppreference.com/w/cpp/compiler_support#cpp17>).
* HAVE_CPP_GUARANTEED_COPY_ELISION: yes, if we don't stick to MSVC 15.0
(GCC 7, Clang 4, MSVC 19.13, "Guaranteed copy elision" at
<https://en.cppreference.com/w/cpp/compiler_support#cpp17>).
(And we would get rid of the nuisance that GCC 4.8 still required an
explicit
return OUString("foo")
instead of just
return "foo";
.)
For the TDF Linux builds on CentOS 6 with Developer Toolset (where we
currently use Deverloper Toolset 2 with GCC 4.8.2, IIUC), my
understanding would be that Developer Toolset 7 with GCC 7 should be
available to use instead (searching the web I found
<https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/>)?
Context
- Compiler baselines (was: [Libreoffice-qa] minutes of ESC call ...) · Stephan Bergmann
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.