[PATCH] D47073: Document and Enforce new Host Compiler Policy

Wed Jan 9 09:33:04 PST 2019

jfb added inline comments.

================
Comment at: docs/GettingStarted.rst:286-290
+For Clang and GCC, the policy of LLVM is to remove host compiler support of a
+compiler once its major version exceeds 3 years old from the previous LLVM
+release's branch date. In order to assist developers to properly prepare their
+environments, a CMake warning will be emitted for any older than 1.5 years from
+the previous LLVM release's branch date.
----------------
erichkeane wrote:
> chandlerc wrote:
> > erichkeane wrote:
> > > chandlerc wrote:
> > > > As mentioned on the -dev thread, I don't think this is (quite) the correct policy.
> > > > 
> > > > I think these kind of time frames are good *guidance* that we should use when considering what the minimum toolchains supported should be. But I think other factors should also be considered. Some relevant examples from the discussion:
> > > > 
> > > > 1) I think we should be willing to require a newer toolchain when it provides *substantial* value to LLVM, and LLVM's users won't be really negatively impacted by the requirement. For example, we might want to skip forward a bit over a release with some known big issue impacting usage of a high-value language feature. I could imagine this becoming true for C++ modules for example, although we're a long way away.
> > > > 
> > > > 2) I think we should be willing to support older toolchains when LLVM's users would be seriously harmed by dropping support. Of course I'm a bit biased here, but both Google and several other users of LLVM are still stuck needing GCC 4.9 to be a viable host toolchain. As LLVM is first and foremost a collection of libraries, I think we have to hold ourselves to a somewhat higher bar of supporting older host toolchains. Chromium for example can always ship users a prebuilt binary, but LLVM isn't in the same boat.
> > > > 
> > > > 3) (more minor point) I don't think we should raise the minimum versions of toolchains *just* because #2 didn't apply and it is more than three years old. Changes to minimum supported versions aren't free for users (even if they are reasonably easy to handle) and we shouldn't churn without cause.
> > > > 
> > > > 
> > > > The result is that I think we need to consider bumping up on a case-by-case basis when there is a motivation, and then check to see that any concerns can be addressed.
> > > > 
> > > > I'm still very happy to have temporal guidance about what our ideal state is to help direct these discussions away from pointless ones and toward where we *want* to be, even if we adjust from there for practical reasons.
> > > I'm not sure I saw it so nicely laid out in the -dev thread, so I appreciate you further elaborating (or reelaborating as the case may be).
> > > 
> > > I would think that #1 and #2 are pretty contrary to each other so they would requires a pretty fine balance.  In this case, there is a recurring interest for a large number of C++14/17 features (which many would argue are substantially valuable) which has precipitated this discussion every 6 months.
> > > 
> > > I definitely understand wanting to support older versions, though I have concern that it often stands in the way of progress.  I presume you and I agree in concept if not in magnitude.
> > > 
> > > For #3, the purpose of this was to provide a so-called 'line in the sand' to stop #2 from allowing us to ever update the compiler.  Since #2 is always going to be the status-quo, it seems to me that it'll never change without some sort of massive intervention.    I guess I'd like to prevent us from being stagnated.
> > This also still needs some update?
> I'd not updated this since I was expecting feedback here. I personally think that actually removing support for older compilers is necessary, however if we want the '3 year warning' in effect (GCC5.1, Clang 3.6) for 8.0, I'll refactor this to be the warning only for now (and revert the error messages to 4.8/3.1).  
> 
> Guidance would be appreciated.
I think for the LLVM 8 release it makes sense to have a hard error for compilers older than 3 years old, with a cmake flag to force-override. That means the error can't just be ignored, but we're being sensible because LLVM 8 doesn't technically need a newer compiler.

That way:

* A developer with a compiler older than 3 years old who compiles LLVM 8 will get an error. They'll either update their compiler, or use the cmake flag.
* A developer with a compiler older than 1.5 years just gets a warning.
* After LLVM 8, we'll hopefully be able to upgrade the C++ version LLVM uses, and the error would now become a hard error because those older compilers are actually unsupported.

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D47073/new/

https://reviews.llvm.org/D47073