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

[Chandler Carruth via Phabricator via llvm-commits]

chandlerc requested changes to this revision.
chandlerc added a comment.
This revision now requires changes to proceed.

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.

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.

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.

-Chandler



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


https://reviews.llvm.org/D47073