Problem
While working on #26148 I had to add two different workarounds for bugs in gcc 4.8's standard library (specifically: that list::insert and list::splice don't accept const_iterator arguments). One of those required a const_cast.
Describe the solution you'd like
gcc 4.9 was released in 2014. Can we cease support for 4.8? Does the project have a policy on how far back it maintains compiler support?
If we drop support for gcc-4.8, people won't be able to build C:DDA on default Red Hat Enterprise Linux 7 installations.
I don't think that's a good reason.
Ubuntu 14.04 LTS still uses gcc-4.8 and is supported through April 2019. I don't know if we need to match Ubuntu's LTS policy, but I also think we don't need to support gcc versions that aren't in a current Ubuntu LTS. So even if we decide not to remove gcc-4.8 support now, we should deprecate it and plan to remove it in April 2019.
I also think only supporting 3 or 4 years of gcc is a valid policy. I think 5 years is the maximum reasonable number, but a lower number is acceptable.
We aim to support as much compilers as possible to cover multiple rather old systems.
Some of the drivers of supporting old gccs;
Ubuntu LTS releases
Debian stable
Fedora whatsit releases
Mingw releases
Especially the mingw version bundled with Code::Blocks.
The goal here is minimizing the number of operations necessary for a new
contributor to achieve their first build. Patching in a new compiler can
be surprisingly difficult.
Cool. That makes sense. I'll close this issue for now.
As of this month:
So, I'm reopening this and proposing we advance to a minimum gcc 5.1 (or maybe 5.3?). That gives us access to all of C++14 (and in the library). gcc 5.1's C++14 support might be buggy in some corner cases, so that's why I'd prefer 5.3.
Historically C::B has been the easiest way to get started on windows, so I'm hesitant to move past 5.1, but I'm not totally sure what people are using now, so if that's no longer the case we can step up to 5.3.
Related, #27690
C::B builds are partially broken now. I think MSYS is the easiest way now.
Well there you go, if it isn't even a reliable way of getting started, no need to accommodate it, we're good to bump to 5.3. At the same time, bump clang minimum version to one that supports c++14 at least, looks like 3.4. The main limiter for clang seems to be the version that Xcode is built on, so it might be reasonable to bump to something later than that, but I have no visibility into Xcode versions.
Cool. I'll work on one or more PRs for this.
When I update the docs about compiler support, is it appropriate to describe our position as:
We aim to support gcc and clang up to the newest stable versions and back to those shipping in any supported version of a popular distribution or relevant development environment, including Ubuntu, Debian, MSYS, and XCode.
We don't provide clang support in MSYS (yet), but it has version 8 by default and default gcc version there is either 7.4 or 8.3.
@narc0tiq I note that the Linux builds (Tiles and Curses) on the primary build matrix on Jenkins are using g++-4.8. How easy is that to change to something newer?
It's almost trivial to change it, I've got it on 4.8 only because it was the bottom of our support.
Please note that I've discovered there's no available package for gcc 5.3, so we're moving to 5.5 instead for the Linux 64 builds. At the same time, though, please double-check the Windows and OSX builds, as they tend to be non-trivial to upgrade.
Thanks! On Jenkins it looks like Windows builds are using gcc 5.4 and OS X build are using clang 3.8, so I think we're good there.
Most helpful comment
As of this month:
So, I'm reopening this and proposing we advance to a minimum gcc 5.1 (or maybe 5.3?). That gives us access to all of C++14 (and in the library). gcc 5.1's C++14 support might be buggy in some corner cases, so that's why I'd prefer 5.3.