Greetings,
This has been discussed many times, and there are a lot of pro’s and con’s on each side, but increasingly I think the project needs to draw a line in the sand and put in place long-term policies around support for building LLVM & Clang with older C++ toolchains. It also would have the benefit of removing divergence between LLVM sub-projects already using C++11 features. As they have grown in popularity and as code moves back and forth across project boundaries, I think this is a growing strain.
I am seriously concerned that if we don’t do this now, we will miss out on the accelerating trend of C++ as a language.
Concrete long term proposal:
We support building with C++ toolchains which were released and widely available on their respective target platforms at least 2 years prior to the next 6-month-cycle release. Immediately after each branch of a release, mainline can move the bar forward by 6 months. Thus, each release should build with the four previous releases.
Some observations:
-
I specifically am wording this to enable the mainline to use features sooner. People who are unable to use an even more modern toolchain will necessarily stay with each release.
-
This is an aggressive timeline. That is intentional. There is increasing pressure for LLVM to make use of new C++ language and library features.
-
There is always the option of checking out an old release, building it, and then using that compiler to build the latest release or to build the mainline compiler.
-
The goal is to only change the supported toolchain set and thus C++ dialect after a release branches to avoid confusion, churn, and impeding QA on a release. People can check out trunk and get an idea of whether they will have problems with the next release.
-
I have historically been more conservative on this topic, but listening to many people and looking at some of the C++ features we are missing, I think the right strategy for the project is a more aggressive one.
One short term caveat: Windows is special.
I don’t think we should follow the 2-year rule for Windows. It really is special for at least three reasons:
- We can’t bootstrap on Windows. While there is tons of exciting work going on here to change that, even then the quality of Windows support is likely to change very rapidly.
- Visual Studio’s C++ support moved very slowly for a long time, and is now improving at an amazing rate. We shouldn’t be hampered by past problems and should take advantage of this recent progress.
- We have less insight into when new versions of the MSVC++ toolchain will arrive.
So my suggestion is that, at least during the rapid evolution of VS’s C++11 support and Clang’s Windows support, we support building with the most recent 2 versions of VS available at the prior release. For example when we branch for 3.4, the two versions will be 2012 and 2013. Those two would be supported on mainline from then through 3.5, and when we branch for 3.5 we would re-evaluate.
NOTE: This would drop support for VS 2010!!! That is a huge change, hence my suggesting it only after we branch for 3.4. It gives us an entire release cycle of notice for people relying on it.
Now for the carrot: if we go with this plan, then immediately after branching for 3.4, we would be able to use the vast majority of C++11 features, targeting the following as the oldest toolchains supported through the 3.5 release timeframe:
GCC 4.7
Clang 3.1
VS 2012
Some notable features we would get to use:
- r-value references, move semantics, etc
- auto
- range for loops
- lambdas
- static_assert
- nullptr
- std::unique_ptr, std::tuple, some other nice library stuff
These days, this list seems increasingly worth the cost of forcing users to get a modern toolchain onto their systems.
-Chandler
