[llvm-dev] RFC: Updating to CMake 3.15.0

Mon Nov 4 10:36:38 PST 2019

On Mon, Nov 4, 2019 at 9:38 AM Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Neil,
>
> I'm really not sure what you're getting at. Are you objecting to the
> proposal to update?
>
> The LLVM community operates by having request-for-comment (RFC) discussion
> threads to coalesce around a plan, then just moving forward. There is no
> formal argument or proposal needed.
>
> We also don't really have an official policy regarding updating CMake. In
> your other emails on the thread you were talking about "production"
> machines, and I don't think the tools required to develop LLVM really
> factor in there at all. In a production environment you should be using a
> release of LLVM, likely obtained in binary form.
>
> If you have an objection to the LLVM trunk requiring CMake 3.15.0
>
In the list of concrete reasons to bump the version of cmake, I only saw
rationales up to 3.14, so I'm not sure why 3.15 is necessary. I may have
missed this, sorry.

> in order to build I'd like to understand that objection so that we can
> take it into account as we move forward.
>
Not entirely opposed to this, but the two things I see missing are:
1) I think the costs are being underestimated
2) This seems contrary to version policy elsewhere in LLVM

In more detail:
1) I think the costs are being underestimated
David Chisnall reported many package managers have cmake 3.15, so bumping
the required version would not affect those users. However, debian/ubuntu
only have up to 3.13 in their latest repos (I'll ignore that it's only 3.10
in 18.04LTS), so there would be some non-trivial amount of users that have
to go through manual upgrade pain. I don't know that we have data on
builders of llvm to know what platforms people use to get an actual number
of people that would be affected, though it would be interesting if someone
knew how to do that.

In my experience with open source software, sometimes it Just Works, and
then other times you can lose whole days to figuring out why the thing you
downloaded isn't working/building. I also think we might be a biased group:
I'm confident I could download the newest cmake and configure it fairly
easily, but a new contributor to llvm may just give up because it's too
complicated.

2) This seems contrary to version policy elsewhere in LLVM
Our docs say we support a host toolchain of clang 3.5, released Sep 2014.
In my earlier post, I mentioned objections on setting a minimum
recommonmark version of 0.5, because only 0.4 is available widely. If we
decide that grabbing new versions of software is easy, why don't we just
make clang-9 the minimum support host compiler version? (Similarly for gcc,
msvc, ...).
Having 1 thing that is required to grab outside of the host system's
package manager is maybe not too bad, but if we require N things, that may
be too large of a barrier for some people.

I don't want to derail this RFC, since the cmake version bump has real
improvements (see the replies in this thread -- thanks!), but I think we
should at least think about having a llvm-wide policy on this kind of thing
instead of just looking at cmake.

>
> Thanks,
> -Chris
>
> On Nov 4, 2019, at 7:23 AM, Neil Nelson <nnelson at infowest.com> wrote:
>
> Here is how I would make the argument for the latest version of cmake.
>
> The latest version of cmake addresses a number issues we face in building
> LLVM including the following.
>
> [list the justifications]
>
> We realize this using of the latest versions of external software goes
> outside our usual method, but in this case the cmake software will not be
> folded into the resulting LLVM software release and only in the building of
> the release. Whatever issues a new cmake may present in the build will be
> identified during testing in that the nature of cmake should easily allow
> our standard testing to know if it is working properly or not.
>
> For those building LLVM for standard OS release versions such as the
> Ubuntu LTS versions seen on our prepared build page, it is expected that
> those installations are dedicated to the building of LLVM and not for any
> other production purpose so that installing the recent version of cmake
> will not affect their other efforts if some problem with this latest cmake
> version arises.
>
> Neil Nelson
> On 11/4/19 7:33 AM, Robinson, Paul wrote:
>
> However I think you are creating a false dichotomy. I have no real
> insight into Ubuntu's methodology, but as a user, what I observe
> is that Ubuntu LTS is NOT a collection of the most recent stable
> well-tested versions of all components, kept up-to-date; instead,
> it is a snapshot of stable, well-tested versions of all components,
> which Ubuntu then commits to maintaining for N years. A given LTS
> releases maintenance updates only, not new features.
>
> And it is certainly not the case that every version of every
> component after an Ubuntu LTS is a buggy, bleeding-edge untested
> hacked-up mess.  Ubuntu LTS chooses to stick with certain versions,
> not because later versions are awful, but because picking up new
> versions is not their goal.
>
> So, when we talk about raising our minimum required CMake version,
> it is not to take CMake bleeding-edge HEAD and have everyone build
> their own; it is to take a more recent formal release of CMake.
> Now, the CMake people might not conveniently package binaries for
> everyone's environment, which might mean some people need to pull
> a release's source package and build it themselves; this is the
> nature of open-source.
> --paulr
>
>
>
> _______________________________________________
> 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/8016e4ed/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191104/8016e4ed/attachment.bin>