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

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>

Maybe a bootstrap.sh?  I understand that it can get a little tricky, but
even if it only worked 95% of the time it might be enough to lower the
barrier to entry.

Steve

On Mon, Nov 4, 2019 at 9:16 AM Chris Bieneman <chris.bieneman at me.com>
wrote:
> 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/fd35c8b4/attachment.html>

I'm not sure what benefit that would provide. For most developers they
already have configured build directories and if their CMake is too old they are
going to do a `git pull` and all of a sudden their build fails to configure.
Then they go fetch a new CMake. Not sure a bootstrap script really helps with
that. Especially since the CMake git repository contains one, and many people
might prefer to grab a binary distribution rather than build their own.

-Chris
> On Nov 4, 2019, at 9:29 AM, Stephen Neuendorffer <stephen.neuendorffer
at gmail.com> wrote:
> 
> Maybe a bootstrap.sh?  I understand that it can get a little tricky, but
even if it only worked 95% of the time it might be enough to lower the barrier
to entry.
> 
> Steve
> 
> On Mon, Nov 4, 2019 at 9:16 AM Chris Bieneman <chris.bieneman at me.com
<mailto:chris.bieneman at me.com>> wrote:
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<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/8b3d09ca/attachment-0001.html>