I’m really looking forward to be able to use c++17 features, and to stop supporting gcc5 !
That said we should still have some due diligence in terms of the choice of which version to upgrade to.
There is a reason why the guideline is written in very soft way with an intention for supporting 3 years minimum.
There is always binary distributions of gcc and clang people can download to build LLVM.
I think it is an overly narrow consideration.
While you may think here of the workflow of an end-user building clang/LLVM on their system to test it, LLVM is also embedded in various downstream products: the users’ toolchain here isn’t just an individual on their local machine trying to use LLVM directly, but all the users and packager of these other projects than embed LLVM.
This goes beyond all the build environment, it also gets into the deployment target!
You can’t just update the compiler on the latest Ubuntu and build and deploy to the previous Ubuntu: it may not have the suitable stdlibc++ (see below for some painful memory from the last LLVM update…).
That means that we need to consider that LLVM (probably less clang/lld/…) “as a library” is a fairly foundational component for many other projects, and updating our requirements may have significant transitive impact.
Speaking for one I’m familiar with: we embed LLVM inside Tensorflow (and XLA) and we’re tracking HEAD very closely (never more than a few days behind). We embed LLVM as part of the libraries that ship as a pip package, and I assume that we’re not the only vendor out there in a similar situation. So any toolchain requirements propagates to every platform we would want to support, and the requirements of the pip environment, etc.
An upgrade isn’t just trivially updating the toolchain for LLVM in isolation there.
The last upgrade moved from C++11 to C++14 and gcc 4.8 to 5.2: this ended up being incredibly disruptive in practice. It turned out that we couldn’t build our pip package in a way that would still be installable on Ubuntu 14.04 (at the time still widely used by data scientist & universities) because of incompatibilities in libstdc++ (related to the ABI change with std::string if I remember correctly…).
RedHat had at the same time some convoluted tooling and linker script that would allow to build packages on a recent CentOS and deploy them to a previous one.
Anyway: I’m very supportive of moving forward (we need to be able to keep the ability to move forward!), but I still wanted to bring some dose of pragmatism as well and surface the “foundational” aspect of “LLVM as a library” out there.
I have buildbots on gcc 5.4, but I’ll happily turn them down: gcc 5 has been painful ~ once a week on average (including one new “ICE” just today!).
Back to my point above: while we can always install a new compiler and build on a more recent distribution, this may bring deployment limitations as well which are more impactful.
So the list of distribution this impacts (I haven’t looked at the spreadsheet carefully yet) is really important.