[llvm-dev] RFC: Updating to CMake 3.15.0

Sat Nov 9 21:56:35 PST 2019

I don't see a difference, assuming it is *a* copy-paste-able command and
not *10* copy-paste-able commands.

Since the bots are mentioned though, having a script would allow running on
every bot a sequence like:

mkdir build && cd build
${llvm_src}/download_and_bootstrap_cmake.sh cmake_bootstrap
cmake_bootstrap/bin/cmake ${llvm_src}/llvm/ -D....

The bots would not need to be updated when we update the version of CMake
in the script, the repo would be self-contained.

-- 
Mehdi

On Tue, Nov 5, 2019 at 8:42 AM Saleem Abdulrasool via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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
> _______________________________________________
> 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/20191109/4174f2c4/attachment.html>