[llvm-dev] A Short Policy Proposal Regarding Host Compilers

Thu Jan 10 16:35:41 PST 2019

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.

-- 
Mehdi

>
> --
> Mehdi
>
>
>
> On Mon, Jan 7, 2019 at 4:46 PM JF Bastien via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I’d like us to move forward with something along the lines Erich proposed
>> back in May, ideally early enough in the LLVM 8 release process that people
>> testing the release will be able to provide feedback.
>>
>> Are there any remaining concerns?
>>
>>
>> > On May 23, 2018, at 6:21 AM, Keane, Erich via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>> >
>> > Hi all-
>> > I just wanted to bump this again, I know I sent it out on a Friday :)
>> I realize this is a minor code change with significant implications, so it
>> seems to me that I should ensure it gets extensive exposure.
>> > See the review here: https://reviews.llvm.org/D47073
>> > -Erich
>> >
>> > -----Original Message-----
>> > From: Keane, Erich
>> > Sent: Friday, May 18, 2018 8:26 AM
>> > To: llvm-dev at lists.llvm.org
>> > Subject: RE: [llvm-dev] A Short Policy Proposal Regarding Host Compilers
>> >
>> > I've heard just about zero opposition to this, so I've put a code
>> review together here: https://reviews.llvm.org/D47073 With the intent of
>> either implementing this policy change, or encouraging further
>> discussion/bikeshed.
>> >
>> > Thanks all!
>> > -Erich
>> >
>> > -----Original Message-----
>> > From: Brooks Davis [mailto:brooks at freebsd.org]
>> > Sent: Sunday, May 13, 2018 10:34 AM
>> > To: Keane, Erich <erich.keane at intel.com>
>> > Cc: llvm-dev at lists.llvm.org
>> > Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers
>> >
>> > On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev
>> wrote:
>> >> Hi All-
>> >> As we all know, the C++14 discussion is flaring up again.  Chandler
>> brought up that he would like a concrete plan to switch.  In my opinion,
>> this is insufficient, as it will result in us simply having this discussion
>> AGAIN next release.  Instead, I would prefer us to have a concrete Policy
>> on our host compilers.  That way, changes like this are unsurprising to our
>> users, and advance our codebase sufficiently.  I believe the arguments
>> for/against upgrading have been made repeatedly, so I won't repeat them
>> here.  My proposal is thus:
>> >>
>> >> Starting with the Clang 7.0 release, we will officially support any
>> major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in
>> the past 3* years from our previous branch date to give trunk-developers
>> time to transition (so for 7.0, 3 years before January 3, 2018).  This will
>> be enforced via the CMake CheckCompilerVersion script (ala
>> https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be
>> issued for any major release less than 1.5* years old to give our users
>> sufficient time to transition/upgrade their compilers.  Finally, our
>> dependent C++ version will be the best released standard officially
>> supported by the collection of compilers (for example, we'd support -C++20
>> if all compilers had std=c++20 or eqiv, but NOT std=c++2a).
>> >>
>> >> The 3-years/1.5 years would result in our minimum GCC/Clang becoming:
>> >> GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8
>> >
>> > Historically 3/1.5 would have caused us problems on FreeBSD, but we're
>> moving to supporting all architectures via an external toolchain[0] so I
>> don't think it will have a major impact.  We'll have to amend our statement
>> of which systems you can bootstrap from to include the need to install a
>> compiler package in some cases (or be more aggressive about merging new
>> compiler versions to stable branches).
>> >
>> > -- Brooks
>> >
>> > [0] Some of them purely external due to a lack of viable LLVM support
>> and a policy against GPLv3 licenses in the tree.
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > llvm-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190110/05743935/attachment.html>