<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 10, 2019 at 4:32 PM JF Bastien <<a href="mailto:jfbastien@apple.com">jfbastien@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Jan 10, 2019, at 4:30 PM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:</div><br class="gmail-m_5931519459199768432Apple-interchange-newline"><div><div dir="ltr"><div>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?</div><div><br></div><div>Historically I believe we've been looking at a combination of:</div><div><br></div><div>1) What new feature we gain by dropping support for a given version of the compiler</div><div>2) What major OS out there have available (possibly through PPA?).</div><div><br></div><div>And balance the two aspects.</div><div><br></div><div>What is the motivation for changing this approach?</div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>I don't understand why migrating to c++14 has anything to do with changing the approach. </div><div>We migrated to C++11 using the framework I mentioned above, I don't see why we can't do it for C++14?</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div><div></div><br><blockquote type="cite"><div><div dir="ltr"><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 7, 2019 at 4:46 PM JF Bastien via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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.<br>
<br>
Are there any remaining concerns?<br>
<br>
<br>
> On May 23, 2018, at 6:21 AM, Keane, Erich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> Hi all-<br>
> 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. <br>
> See the review here: <a href="https://reviews.llvm.org/D47073" rel="noreferrer" target="_blank">https://reviews.llvm.org/D47073</a><br>
> -Erich<br>
> <br>
> -----Original Message-----<br>
> From: Keane, Erich <br>
> Sent: Friday, May 18, 2018 8:26 AM<br>
> To: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Subject: RE: [llvm-dev] A Short Policy Proposal Regarding Host Compilers<br>
> <br>
> I've heard just about zero opposition to this, so I've put a code review together here: <a href="https://reviews.llvm.org/D47073" rel="noreferrer" target="_blank">https://reviews.llvm.org/D47073</a> With the intent of either implementing this policy change, or encouraging further discussion/bikeshed.<br>
> <br>
> Thanks all!<br>
> -Erich<br>
> <br>
> -----Original Message-----<br>
> From: Brooks Davis [mailto:<a href="mailto:brooks@freebsd.org" target="_blank">brooks@freebsd.org</a>]<br>
> Sent: Sunday, May 13, 2018 10:34 AM<br>
> To: Keane, Erich <<a href="mailto:erich.keane@intel.com" target="_blank">erich.keane@intel.com</a>><br>
> Cc: <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers<br>
> <br>
> On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev wrote:<br>
>> Hi All-<br>
>> 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:<br>
>> <br>
>> 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 <a href="https://reviews.llvm.org/D46723" rel="noreferrer" target="_blank">https://reviews.llvm.org/D46723</a>).  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).  <br>
>> <br>
>> The 3-years/1.5 years would result in our minimum GCC/Clang becoming: <br>
>> GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8<br>
> <br>
> 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).<br>
> <br>
> -- Brooks<br>
> <br>
> [0] Some of them purely external due to a lack of viable LLVM support and a policy against GPLv3 licenses in the tree.<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>
</div></blockquote></div><br></div></blockquote></div></div>