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

[Erich Keane via Phabricator via llvm-commits]

erichkeane added a comment.

In https://reviews.llvm.org/D47073#1155018, @chandlerc wrote:

> I like the idea of having CMake warn users about older host toolchains that are at risk of ceasing to be supported. I might target the warning point at 2 years rather than 1.5 years though.


1.5 is derived from the '3 year' limit here. We were intending to make sure that this would warn for users for at least 'a version or two'.  2 years would likely still work since we'd have a release between the 2 and 3 years.  THAT SAID, I'd be very much against a warning without some sort of date-based rule in place.  Otherwise all we end up doing is making it so that changing our required compiler version become a 2 year+ long process, since we'd need to warn for that long.

> I don't think we're ready to go to GCC 5 yet (based on the -dev list discussion). We could go to 4.9 based on my memory of that discussion w/o folks having lots of issues, but it isn't clear how valuable that would be. But moreover, I would suggest trying to get this change in independently of actually changing the values for any of the minimum tools. This patch should establish process guidelines and helpful warnings. We can have a separate patch to actually move the bar if/when there is clear consensus around that. I've suggested adjusting the specific process description you've given below based on my personal feelings about what a good process would be.

Issuing a warning as this patch proposes would require some sort of policy as to EOL'ing support.  I'm not sure what value it has without that, since it just means upgrading compilers becomes a long and nasty process.

> On an unrelated note, and making the comment here rather than elsewhere to delay reigniting that email thread, I do think that for the GCC 4.9 -> GCC 5 switch, we should advertise this really clearly and loudly. Release notes, etc., around when we plan to flip the switch so that our users actually have time to get ready. For example, switching after LLVM 8 branches would be about right for us, but maybe not for other users. We should figure out this timeframe and broadcast it pretty clearly.

I don't disagree here, clear advertising is a good idea.  I don't mind rebasing this patch on 8 (as I believe you (the 'royal' you) were the only real dissent at the time to the GCC 4.8->5 switch on llvm-dev, though admittedly that doesn't terribly mean anything.



================
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.
----------------
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.


https://reviews.llvm.org/D47073