[llvm-dev] RFC: Updating to CMake 3.15.0

Mon Nov 4 09:16:54 PST 2019

CMake doesn’t have the ability to reliably re-invoke itself in a way that would make that workflow reasonable. To do it would require a meta build system for our meta build system, and that is the road to madness.

-Chris

> On Nov 4, 2019, at 8:59 AM, Stephen Neuendorffer via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 
> 
> Since it's 'so easy', I wonder if it would make people's lives easier to add a bootstrap of cmake to the out of the box build flow.
> Maybe: "You're system Cmake is too old for us.  Downloading and building a cmake 1.15.1 locally for you...."
> 
> Steve
> 
>> On Mon, Nov 4, 2019 at 7:20 AM James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>> On Sun, Nov 3, 2019 at 7:20 PM Neil Nelson via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>> 
>>> Glad we are getting some reasonable justifications for CMake 3.15.0. There are two points we may be missing.
>>> 
>>> Is our plan to just keep updating to the most recent CMake version or will our objectives be reached with this version? If we gain what we need with this version then after a while we will have the Ubuntu LTS aligned.
>>> 
>>> For my current purposes, LLVM can get wild without much worry here. I just clone a VM and run what is useful and then delete it. A bit like use once and throw away. This is not for production purposes but for getting a better view of software structure that LLVM can provide.
>>> 
>>> When I was managing IT and the servers for a small company that needed to be live 24/7 we used the latest Ubuntu LTS version because we needed rock-solid performance as best we could get. The software in the LTS version is tested and used by a large user base with necessary updates and so we expected to have high reliability.
>>> 
>>> Those saying how easy it was to obtain the latest CMake have apparently not been faced with the absolute need for solid up-time. Installing hack-me-now, buggy, bleeding-edge software was severely discouraged. But in the LLVM environment, I can see where that is not a strong necessity.
>>> 
>>> But at the same time, does LLVM strive to be the backbone of 24/7 software? Or is it more of a cool thing with some interesting code analysis properties? I suspect its nature is a bit wild, bleeding edge. And that's OK.
>>> 
>> I'm not really sure what your worry is here -- if you're downloading and building a development version of LLVM onto this particular production machine, why is it problematic to also download a newer release version of CMake to build it with?
>> 
>> Maybe you're worried that you'd have to install the new cmake into /usr/local/bin? If that's the worry, I'll note that you are not required to install cmake into /usr/local/bin/ in order to use it to build LLVM, and I'd recommend not doing so. You can actually invoke the cmake binary directly from its build/download directory -- no "make install" required at all. Used that way, it doesn't affect anything else on your system -- if you like, the new cmake can be used ONLY for building LLVM, and affect literally nothing else other than a tiny amount of disk-space.
>> 
>> Another important point here is that the version of cmake you use to build llvm doesn't impact users of the llvm libraries or binaries that were built with the new cmake. (I'd contrast that with llvm requiring a newer version of a shared library, which _does_ have runtime impact, and thus is of potentially larger concern.)
>>  
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://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/20191104/4bedfc91/attachment.html>