<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 4, 2019 at 11:23 AM Chris Bieneman via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Nov 4, 2019, at 10:36 AM, Jordan Rupprecht <<a href="mailto:rupprecht@google.com" target="_blank">rupprecht@google.com</a>> wrote:</div><br><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br><div>In the list of concrete reasons to bump the version of cmake, I only saw rationales up to 3.14, so I'm not sure why 3.15 is necessary. I may have missed this, sorry.</div></div></div></blockquote><div><br></div><div>There are a number of features in CMake 3.15 that are useful. I don't know that any are blocking specific LLVM development or the the absence of them is causing any significant burden.</div><div><br></div><div>The 3.15 features that I found of note are:</div><div>(1) Swift support with the Ninja generator</div><div>(2) Arbitrary job pool support for add_custom_command and add_custom_target</div><div>(3) CMake gained support for using clang to target the MSVC ABI with *nix-style arguments rather than CL comparable arguments</div><div>(4) Lots of new generator expressions that are very useful for deferring work to generation time</div><div><br></div><div>I expect uses of the generator expressions in particular will come up sooner rather than later. Which is why it was suggested that the cost of moving to 3.14 is roughly the same as moving to 3.15, so taking the newest version is probably a better approach as it might push off the next time we want to update.</div><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>in order to build I'd like to understand that objection so that we can take it into account as we move forward.</div></div></blockquote><div>Not entirely opposed to this, but the two things I see missing are:</div><div>1) I think the costs are being underestimated</div><div>2) This seems contrary to version policy elsewhere in LLVM</div><div><br></div><div>In more detail:</div><div>1) I think the costs are being underestimated</div><div>David Chisnall reported many package managers have cmake 3.15, so bumping the required version would not affect those users. However, debian/ubuntu only have up to 3.13 in their latest repos (I'll ignore that it's only 3.10 in 18.04LTS), so there would be some non-trivial amount of users that have to go through manual upgrade pain. I don't know that we have data on builders of llvm to know what platforms people use to get an actual number of people that would be affected, though it would be interesting if someone knew how to do that.</div></div></div></blockquote><div><br></div><div>I'm very sympathetic to the pain of updating builders, which is why we thought it was best to do less upgrades and grab the newest version. I'm somewhat unsympathetic to users having "manual upgrade pain" because many of our users are on Darwin where there is no officially supported package manager and many users have to get CMake themselves.</div></div></div></div></blockquote><div><br></div><div>"This hurdle exists for some users, so why not more/all users" doesn't seem like an ideal argument to me - it's still making the situation worse for some users than it is today. (though I agree that the hurdle for getting cmake seems relatively small)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div style="overflow-wrap: break-word;"><div><div> Additionally getting CMake binary from <a href="http://cmake.org/" target="_blank">cmake.org</a> or building from source are very easy (as has been mentioned on this thread). Building a working clang is *much* more complicated than building a working CMake.</div><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div><br></div><div>In my experience with open source software, sometimes it Just Works, and then other times you can lose whole days to figuring out why the thing you downloaded isn't working/building. I also think we might be a biased group: I'm confident I could download the newest cmake and configure it fairly easily, but a new contributor to llvm may just give up because it's too complicated.</div></div></div></blockquote><div><br></div><div>I would expect a new contributor could grab the binary packages from <a href="http://cmake.org/" target="_blank">cmake.org</a>. Binary packages are available for most common operating systems.</div><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div><br></div><div><div>2) This seems contrary to version policy elsewhere in LLVM</div><div>Our docs say we support a host toolchain of clang 3.5, released Sep 2014. In my earlier post, I mentioned objections on setting a minimum recommonmark version of 0.5, because only 0.4 is available widely. If we decide that grabbing new versions of software is easy, why don't we just make clang-9 the minimum support host compiler version? (Similarly for gcc, msvc, ...).</div></div><div>Having 1 thing that is required to grab outside of the host system's package manager is maybe not too bad, but if we require N things, that may be too large of a barrier for some people.</div></div></div></blockquote><div><br></div><div>I think compiler versions are very different, and comparing CMake to compiler versions is an apples-to-oranges comparison.</div></div></div></div></blockquote><div><br>Agreed - if at least because if we adopted that strategy for clang, it'd be self-referential. (clang 11 only builds with clang 10, clang 10 with clang 9, etc - so there's a lower chance you'd find an existing toolchain on your system if someone hadn't already been releasing clang on your system - whereas cmake can be built with lots of compilers, so if there's no binary distribution available for you, you can probably build one without needing a new compiler, etc)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div style="overflow-wrap: break-word;"><div><div> We support very old versions of clang and gcc because we rely on a fairly old C++ language standard. Much of the reason for that is actually because of MSVC's historically lagging C++ language support.</div></div></div></div></blockquote><div><br>That seems a bit backwards - we use an old C++ language standard because we support old versions of system compilers, rather than the other way around. If we said "just download a binary package of the compiler, add it to your PATH and use that" we could say "clang only builds with the latest clang release", for instance. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div>I don't want to derail this RFC, since the cmake version bump has real improvements (see the replies in this thread -- thanks!), but I think we should at least think about having a llvm-wide policy on this kind of thing instead of just looking at cmake.</div></div></div></blockquote><div><br></div><div>I agree that we need better specified upgrade policies for tools we use or depend on. I don't think a one-size-fits-all policy is appropriate. I actually think Tom Stellard's suggestion of always upgrading after every branch has merits, although I might tweak it slightly to "reserve the right to upgrade" after every release branch.</div><div><br></div><div>-Chris</div><br><blockquote type="cite"><div><div class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><br></div><div>Thanks,</div><div>-Chris<br><div><br><blockquote type="cite"><div>On Nov 4, 2019, at 7:23 AM, Neil Nelson <<a href="mailto:nnelson@infowest.com" target="_blank">nnelson@infowest.com</a>> wrote:</div><br><div><p><font size="-1">Here is how I would make the argument for the latest version of cmake.</font></p><font size="-1"></font><p><font size="-1">The latest version of cmake addresses a number issues we face in building LLVM including the following.</font></p><font size="-1"></font><p><font size="-1">[list the justifications]</font></p><font size="-1"></font><p><font size="-1">We realize this using of the latest versions of external software goes outside our usual method, but in this case the cmake software will not be folded into the resulting LLVM software release and only in the building of the release. Whatever issues a new cmake may present in the build will be identified during testing in that the nature of cmake should easily allow our standard testing to know if it is working properly or not.</font></p><font size="-1"></font><p><font size="-1">For those building<span> </span></font><font size="-1"><font size="-1">LLVM</font><span> </span>for standard OS release versions such as the Ubuntu LTS versions seen on our prepared build page, it is expected that those installations are dedicated to the building of LLVM and not for any other production purpose so that installing the recent version of cmake will not affect their other efforts if some problem with this latest cmake version arises.</font></p><font size="-1"></font><p><font size="-1">Neil Nelson</font></p><div><font size="-1">On 11/4/19 7:33 AM, Robinson, Paul wrote:</font><br></div><blockquote type="cite"><pre>However I think you are creating a false dichotomy. I have no real
insight into Ubuntu's methodology, but as a user, what I observe
is that Ubuntu LTS is NOT a collection of the most recent stable
well-tested versions of all components, kept up-to-date; instead,
it is a snapshot of stable, well-tested versions of all components,
which Ubuntu then commits to maintaining for N years. A given LTS
releases maintenance updates only, not new features.
And it is certainly not the case that every version of every
component after an Ubuntu LTS is a buggy, bleeding-edge untested
hacked-up mess. Ubuntu LTS chooses to stick with certain versions,
not because later versions are awful, but because picking up new
versions is not their goal.
So, when we talk about raising our minimum required CMake version,
it is not to take CMake bleeding-edge HEAD and have everyone build
their own; it is to take a more recent formal release of CMake.
Now, the CMake people might not conveniently package binaries for
everyone's environment, which might mean some people need to pull
a release's source package and build it themselves; this is the
nature of open-source.
--paulr
</pre></blockquote></div></blockquote></div><br></div></div>_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a></blockquote></div></div></blockquote></div><br></div></div>_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>