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

Mehdi AMINI via llvm-dev
Fri, 11 Jan 2019 00:35:41 -0000

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>