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

Wed Jan 9 00:21:14 PST 2019

chandlerc added a comment.

I'm personally very happy for some version of this to go in, but I think the patch itself needs to be updated first? Marked bits inline.

================
Comment at: cmake/modules/CheckCompilerVersion.cmake:10
+
+LLVM requires at least GCC 5.1,
+# MSVC 2015 (Update 3), or Clang 3.5.
----------------
erichkeane wrote:
> lebedev.ri wrote:
> > Hahnfeld wrote:
> > > This looks strange.
> > This clearly should be prefixed with `#`
> Woops, all of this was supposed to have been deleted.  Looks like my 'svn diff' didn't write properly to disk?  Sorry about that.
Seems this still needs to be updated?

================
Comment at: cmake/modules/CheckCompilerVersion.cmake:24
+      elseif(CMAKE_CXX_COMPILER_VERSION VERSION_LESS GCC_WARN)
+        message(WARNING "Support for Host GCC version less than ${GCC_WARN} will soon be removed.")
       endif()
----------------
erichkeane wrote:
> dberris wrote:
> > Suggestion on the warning, to be more direct, maybe something like:
> > 
> > ```
> > GCC ${CMAKE_CXX_COMPILER_VERSION} will soon be unsupported (version < GCC ${GCC_WARN}).
> > ```
> Nice, thanks for a better wording! 
Use this in both the fatal and non-fatal versions?

================
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:
> > 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?

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

https://reviews.llvm.org/D47073