[llvm-dev] RFC: Updating to CMake 3.15.0

Stephen Neuendorffer via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 4 09:29:33 PST 2019

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.


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>

More information about the llvm-dev mailing list