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

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>

On Mon, Nov 4, 2019 at 9:34 AM Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I'm not sure what benefit that would provide. For most developers they
> already have configured build directories
>
While I agree adding a bootstrap script is probably not worth the cost -
an/the important benefit wouldn't be to existing developers, but to making
the barrier of entry lower to encourage new contributors, I think.

> 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>
> 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
>>
>>
> _______________________________________________
> 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/9d51f086/attachment.html>

I realize that this seems like a dumb question, and it’s only a matter of
perception, but, what’s the difference between a bootstrap script and a
copy-paste-able command in the documentation?  Would that be sufficient to
reduce the barrier to entry?

On Mon, Nov 4, 2019 at 9:39 AM David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Mon, Nov 4, 2019 at 9:34 AM Chris Bieneman via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I'm not sure what benefit that would provide. For most developers
they
>> already have configured build directories
>>
>
> While I agree adding a bootstrap script is probably not worth the cost -
> an/the important benefit wouldn't be to existing developers, but to
making
> the barrier of entry lower to encourage new contributors, I think.
>
>
>> 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>
>> 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
>>>
>>>
>> _______________________________________________
>> 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
>
-- 
Saleem Abdulrasool
compnerd (at) compnerd (dot) org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20191105/1280f9d4/attachment.html>