On Tue, Apr 23, 2019 at 10:50 AM, Konstantin Tokarev
<annu...@yandex.ru> wrote:
[1] says: "we support each major Debian version until one year after
the release of the next major version"
Given that Buster is not released yet, bumping GCC requirement to 7
seems to be premature.
The dependencies policy states that toolchains are only supported until
the release of the next major version, but yes, the Debian Buster
release has not happened yet and is likely still several months away.
Still, it's been two weeks since Alex proposed to require GCC 7, and no
objections have been posted to this list. After talking with Berto,
I've confirmed that Debian is OK with building packages with Clang if
need be, and if it works for Debian it should work for Ubuntu as well.
So instead of requiring that WebKit build with the default system
compiler, we can just require that it build with *some* system compiler.
We do need to support the distro's libstdc++ for the full year after
the next release, though, as otherwise it won't be possible for the
distros to continue to update WebKit. The current policy language
regarding toolchains does not account for that. So I'd like to simplify
this by saying that we support some system compiler for one year after
the release of the next major version, but not necessarily the default
system compiler.
My proposed changes to
https://trac.webkit.org/wiki/WebKitGTK/DependenciesPolicy are:
Keep:
"""
Our dependencies policy is simple:
* We support each major Debian version until one year after the
release of the next major version.
* We support each Ubuntu LTS until one year after the release of the
next Ubuntu LTS.
"""
Then replace all the rest with:
"""
During the support period, we intend for WebKit to remain buildable on
these distributions using some system-provided compiler, not
necessarily the default system compiler, and with the default system
libstdc++. The purpose of this policy is to ensure distributions can
provide updated versions of WebKit during the support period to ensure
users receive security updates.
"""
Now, those changes would imply that we can require GCC 7 now, but not
yet libstdc++ 7, since the policy would normally require that we
continue supporting Debian Stretch for another year. But we can make a
one-time decision to ignore that, because Stretch isn't receiving
WebKit security updates, so it doesn't really matter. Now, good news:
Debian Buster will be the first version to receive WebKit updates,
thanks to our promises of stable dependencies and Ubuntu's success with
providing WebKit updates during the last two years. The goal of
providing security updates to Debian will fail if we drop support for
Debian's libstdc++ within their primary security support period (one
year after release of the next version), though; that would be a major
setback. So my proposed change makes it easier to increase our GCC
requirement (if the old distros can build with old clang, then we can
do it), but harder to increase our libstdc++ requirement (need to wait
one additional year to do so).
The proposed future would look like this:
* Imminently: require GCC 7 and libstdc++ 7
* April 2021: require libstdc++ 8 (one year after Ubuntu 20.04 release)
* Late 2021 or early 2022: require libstdc++ 9 (one year after the
successor to Debian Buster is released)
Then we can require new GCCs whenever we want, as long as the old
clangs suffice. Ubuntu 18.04 has clang 6.0, for instance, so as long as
clang 6.0 works, then we can advance to GCC 8 whenever desired. Debian
Buster has clang 7.0, so come April 2021 we'd be able to require that.
But one of the system compilers would need to work for the full three
years. Then the long support period for libstdc++ is required to make
sure our users don't get cut off from security updates. There's no way
around that: if we want to require newer standard libraries, then our
users will no longer receive updates, period.
Is this OK?
OTOH, GCC 6 has partial support of C++17 [2,3] under -std=c++1z,
which might be sufficient for now.
Beware that GCC 9, released yesterday, is the first version in which
C++ 17 support is no longer experimental. Most things should work in
GCC/libstdc++ 7, but as always, there's going to be bugs that we're
going to have to live with.
Michael
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
