[llvm-dev] RFC: Updating to CMake 3.15.0

[Stephen Neuendorffer via llvm-dev]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191104/4023f4c7/attachment.html>