<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I want to chime in with an alternate
perspective. Not a counter argument per se, but something to
consider.<br>
<br>
When we first started evaluating LLVM, we were stuck with an
absolutely ancient version of gcc. We could use a newer compiler
for LLVM, but if there was an ABI breakage - like the one moving
to C++11 - between our build compiler and our choice of compiler
for LLVM, we were pretty much dead in the water. I honestly don't
know if we'd had a problem at the time, that we'd have ever moved
past it. Or to say it differently, our initial evaluation period
had a fixed number of person months allocated. If we'd spent
those person months fighting build systems, it's very likely we'd
have not reached a point sufficient to justify a "go" on the rest
of the project. <br>
<br>
Just to highlight, the primary issue to be concerned about is ABI
compatibility between whatever version of the compiler is required
to build LLVM and the "build compiler" used for everything else.
Having the compiler itself out of sync is (usually) not an issue,
but having an ABI break - intentional or otherwise - is a show
stopper.<br>
<br>
Philip<br>
<br>
On 05/11/2018 09:54 AM, Daniel Berlin via llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF4BwTUNPuAPZWjoX5WyBJA3hGNruFDhQ5WEz9gW7uKQrFa6Og@mail.gmail.com">
<div dir="ltr">I'd be opposed to 6/5, given where it would leave
us.
<div>It's simply hard to see a compelling reason to leave things
that long.</div>
<div><br>
</div>
<div>In particular, given this is about what it takes to produce
a binary release of clang/llvm from trunk (and not what it
takes to use one), i'd like to see some evidence/argument that
using 3/1.5 would actually have a material affect on the
number of contributions, etc.</div>
<div>(I have doubts it would have any affect on the abliity of
new developers to start contributing, etc).</div>
<div>All of the clang/llvm based tools i have around (cquery,
rtags, you name it) all download and ship binary releases of
clang/llvm (and FWIW, they ship and use 1-2 year old
releases).</div>
<div>It's also unclear to me it makes sense to try to make sure
any user can compile the latest version - for example,
researchers using it almost never keep up with trunk, even
with our current policy that supports things for longer. They
stick with the version that existed when they started.</div>
<div>So it's unclear that we are doing a thing users actually
want in practice anyway :)</div>
<div><br>
</div>
<div>Finally, given the rate of support for newer C++ standards
in LLVM/GCC seems to be accelerating and not slowing down
(AFAICT), keeping a time period this long will just put you
farther and farther behind over time.</div>
<div><br>
</div>
<div>It may be better to simply express it in terms of releases,
and say "we support the past 2/3 major gcc releases, the past
2/3 major clang releases, and the past 2 major msvc releases"</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, May 11, 2018 at 8:58 AM, Andrew
Kelley via llvm-dev <span dir="ltr"><<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I second this proposal, and I make a motion
to lengthen 3/1.5 to 6/5.<br>
</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, May 11, 2018 at 9:37
AM, Keane, Erich via llvm-dev <span dir="ltr"><<a
href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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"
moz-do-not-send="true">https://reviews.llvm.org/D4672<wbr>3</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: GCC5.1/Clang3.6. We would
WARN on anything older than GCC7.1/Clang3.8<br>
<br>
/End Proposal<br>
<br>
<br>
*: To Be Bikeshed<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org"
target="_blank" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org"
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>