<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Apr 27, 2016 at 10:54 AM Renato Golin via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27 April 2016 at 15:39, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>> wrote:<br>
> Yes. It is a move to put linux developers in the same position as<br>
> windows and OS X ones, which is a *very* reasonable thing to do.<br>
<br>
Apart from the fact that neither Windows nor OSX users have a choice.<br>
<br>
We have discussed this before, Rafael, and I don't think doing it<br>
again will yield different results unless new evidence is brought to<br>
light.<br>
<br>
Unless there is a feature in a newer CMake that we *must* have, I see<br>
no need to upgrade the version. In the same way we've been holding on<br>
C++11/14 functionality because MSVC couldn't cope with anything until<br>
recently.<br></blockquote><div><br></div><div>I don't think this is really the right tradeoff.</div><div><br></div><div>The folks working on our build infrastructure have limited time. Making them cope with designing the usage of CMake in such a way that it gracefully degrades across many major versions of CMake makes their work substantially harder, and even if it is theoretically possible to do, it may become sufficiently annoying or slow to do that we simply don't get improvements to how we build things.</div><div><br></div><div>And I think that the same tradeoff holds for C++11 features. We didn't *need* any of them, and we actually pushed the Windows platform harder than all of the others because it was the one holding us back. And I think that was good because it made the developers substantially more productive. In this case, it's just the build infrastructure and not the entire codebase, but I think a similar argument holds. If the functionality in CMake 3.4 makes Chris's job on CMake substantially easier, and it at least seems reasonable to get access to that version of CMake, I'm very supportive of the change.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Trying to go too fast on the cool tools can create a patchwork of<br>
versions and functionality that will make it very hard to debug<br>
buildbot problems.<br></blockquote><div><br></div><div>I'm not really sure how pushing towards newer released and stable versions will cause *more* of a patchwork of versions than following the distro installed versions. It seems to involve strictly fewer versions of CMake. But maybe I'm not understanding your concern here?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
LLVM is not a toy any more, we can't just expect that everyone can get<br>
the same environment we have on our own machines, or we'll fall into<br>
the "works for me" style of closing bugs that is pervasive of open<br>
source projects where only a few people ever commit code to.<br></blockquote><div><br></div><div>I don't see anyone on the thread arguing that. I think Chris is trying to argue instead that this version of CMake is sufficiently widely available that we should adopt it because the benefits outweigh the costs.</div><div><br></div><div>But I do think we need to carefully evaluate the availability outside of Debian and Ubuntu distros, so I did some more research and found:</div><div><br></div><div>- Most major Linux distros have support out of the box in their "current" version (OpenSUSE, Fedora, Ubuntu, Debian, Arch), and several in a released version (Ubuntu, Debian, Arch).</div><div>- FreeBSD has support out of the box in the latest port snapshot (as Chris indicated)</div><div>- Homebrew and fink (package managers for OSX) have support out of the box, and CMake provides binaries for OSX that can be readily installed</div><div>- Windows has binary installers available from CMake</div><div><br></div><div>There are some OSes where this version is unavailable even in the latest release. The most notable IMO is CentOS which doesn't have it in any release. The next most notable is OpenSUSE which only has it in its latest "tumbleweed" rolling update. I just don't think it is reasonable for us to continue to hold back our development tools based on these limitations. I think we regressed several more distros when we switched our requirement to GCC 4.7.</div><div><br></div><div>But clearly we *do* need a fallback option for folks that are on an OS that doesn't provide CMake or that can't install packages using the package manager into the primary OS. I'm totally supportive of that use case.</div><div><br></div><div>Here is the thing: the requirements to build and *use* CMake (not install!) are a strict subset of the requirements to build and *use* LLVM itself. So I see no way that this will be a limiting factor for folks. If it would help we could even bundle a copy of the CMake source code at a known good snapshot in the LLVM project and write a wrapper script to bootstrap it into a known location and then use it for subsequent builds ... but that seems unnecessary to me.</div><div><br></div><div><br></div><div>I'll go back to my analogy: we require a relatively modern C++ compiler (in fact, it is past due to update our requirements there....). The reason is that if you are building a compiler from source, it seems entirely reasonable to expect you to either use a relatively modern OS environment, or to have the wherewithal to bootstrap things using one of the numerous options available. Adding CMake to the potential set of things you need to bootstrap seems like an extremely small incremental burden compared to that of getting a modern C++ toolchain. (Although clearly they won't always both be required in the same situations.)</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Now, back to Chris' point:<br>
<br>
Is the ExternalProject the only sane way to build compiler-rt and<br>
libc++? Because this IS a big point.<br>
<br>
Will it allow a way to build Compiler-RT and libc++ for *all*<br>
supported platforms (as in -DLLVM_TARGETS_TO_BUILD)? Would it be<br>
possible (even if not nice) to do so with an older version of CMake?<br>
How worse would it be, if possible?<br>
<br>
Until we can answer all these questions, build times and personal<br>
preferences have no impact on such a big decision.<br></blockquote><div><br></div><div>I think removing impedance from the development of the CMake build, or enabling new functionality such as properly bootstrapped runtime libraries, are absolutely things to weigh against the cost of using a newer tool.</div><div><br></div><div>-Chandler</div></div></div>