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

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

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>

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>