Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


[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


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.