[llvm-dev] A Short Policy Proposal Regarding Host Compilers (original) (raw)

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Thu Jan 10 16:39:03 PST 2019

On Thu, Jan 10, 2019 at 4:36 PM Mehdi AMINI via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On Thu, Jan 10, 2019 at 4:32 PM JF Bastien <jfbastien at apple.com> wrote:

On Jan 10, 2019, at 4:30 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: I'm a bit puzzled as of why would a fix period of time be the best option to automatically cut support for older compilers? Historically I believe we've been looking at a combination of: 1) What new feature we gain by dropping support for a given version of the compiler 2) What major OS out there have available (possibly through PPA?). And balance the two aspects. What is the motivation for changing this approach? Historically we’ve been on C++11, minus some stuff. The motivation to change the approach is to not be stuck on older C++ versions. I don't understand why migrating to c++14 has anything to do with changing the approach. We migrated to C++11 using the framework I mentioned above, I don't see why we can't do it for C++14? I'm afraid that a fix number of year is purely arbitrary and does not serve the best interest of the users. The only "pro" I perceive is avoiding the work of discussing the tradeoff when dropping support for an old version of one of the supporter host toolchain, and making our life easier on this seems superficial to me.

I think a fixed number of years is a good basis to remind us to look and see whether it would be useful to push things up. IE, we should at least check periodically.

I think it also gives a useful baseline expectation to users and downstream folks about the rough rate of such changes to be expected.

But I agree with you that we shouldn't hold these timeframes as fixed or hard constraints. I just still see value with having them so that we're not just random in when we consider updating.

-Chandler -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190110/817d1a3d/attachment.html>

More information about the llvm-dev mailing list