llvm dev - Jan 2019 - A Short Policy Proposal Regarding Host Compilers

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

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?

-- 
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/ccb34077/attachment.html>

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

> -- 
> Mehdi
> 
> 
> 
> On Mon, Jan 7, 2019 at 4:46 PM JF Bastien via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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 <mailto: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
<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 <mailto: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
<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 <mailto:brooks at
freebsd.org>]
> > Sent: Sunday, May 13, 2018 10:34 AM
> > To: Keane, Erich <erich.keane at intel.com <mailto:erich.keane
at intel.com>>
> > Cc: llvm-dev at lists.llvm.org <mailto: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
<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 <mailto:llvm-dev at lists.llvm.org>
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/d49bd1c0/attachment.html>