llvm dev - Nov 2019 - RFC: Updating to CMake 3.15.0

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

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>

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>

James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 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.
Are we sure that's true for the CMake config files installed with LLVM?

I lean toward the newest CMake but want to make sure we don't
accidentally set up a CMake version bump requirement for users of LLVM
libraries.

                        -David

> On Nov 8, 2019, at 7:53 AM, David Greene via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes:
> 
>> 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.
> 
> Are we sure that's true for the CMake config files installed with LLVM?
The CMake files installed with LLVM can really be broken up into two categories.

(1) The files required for CMake's `findPackage` function
(2) The LLVM CMake modules shared for other projects use

The later will almost certainly require whatever CMake version LLVM is
requiring. The former should not.

There are only two files that are required for the `findPackage` function. One
is generated by CMake and sticks pretty tightly to old CMake language features.
The other is `LLVM-Config.cmake` which we own. That file changes relatively
infrequently, and it can go away if we kill off LLVMBuild. It also largely uses
very old and stable CMake features and there is little reason to change that.

Does that answer your question?
> 
> I lean toward the newest CMake but want to make sure we don't
> accidentally set up a CMake version bump requirement for users of LLVM
> libraries.
> 
>                        -David
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev