[llvm-dev] RFC: Updating to CMake 3.15.0

[David Blaikie via llvm-dev]

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

>
>
> On Nov 4, 2019, at 10:36 AM, Jordan Rupprecht <rupprecht at google.com>
> wrote:
>
>
> 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.
>
>
> There are a number of features in CMake 3.15 that are useful. I don't know
> that any are blocking specific LLVM development or the the absence of them
> is causing any significant burden.
>
> The 3.15 features that I found of note are:
> (1) Swift support with the Ninja generator
> (2) Arbitrary job pool support for add_custom_command and add_custom_target
> (3) CMake gained support for using clang to target the MSVC ABI with
> *nix-style arguments rather than CL comparable arguments
> (4) Lots of new generator expressions that are very useful for deferring
> work to generation time
>
> I expect uses of the generator expressions in particular will come up
> sooner rather than later. Which is why it was suggested that the cost of
> moving to 3.14 is roughly the same as moving to 3.15, so taking the newest
> version is probably a better approach as it might push off the next time we
> want to update.
>
>
>
>> 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.
>
>
> I'm very sympathetic to the pain of updating builders, which is why we
> thought it was best to do less upgrades and grab the newest version. I'm
> somewhat unsympathetic to users having "manual upgrade pain" because many
> of our users are on Darwin where there is no officially supported package
> manager and many users have to get CMake themselves.
>

"This hurdle exists for some users, so why not more/all users" doesn't seem
like an ideal argument to me - it's still making the situation worse for
some users than it is today. (though I agree that the hurdle for getting
cmake seems relatively small)


> Additionally getting CMake binary from cmake.org or building from source
> are very easy (as has been mentioned on this thread). Building a working
> clang is *much* more complicated than building a working CMake.
>
>
> 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.
>
>
> I would expect a new contributor could grab the binary packages from
> cmake.org. Binary packages are available for most common operating
> systems.
>
>
> 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 think compiler versions are very different, and comparing CMake to
> compiler versions is an apples-to-oranges comparison.
>

Agreed - if at least because if we adopted that strategy for clang, it'd be
self-referential. (clang 11 only builds with clang 10, clang 10 with clang
9, etc - so there's a lower chance you'd find an existing toolchain on your
system if someone hadn't already been releasing clang on your system -
whereas cmake can be built with lots of compilers, so if there's no binary
distribution available for you, you can probably build one without needing
a new compiler, etc)


> We support very old versions of clang and gcc because we rely on a fairly
> old C++ language standard. Much of the reason for that is actually because
> of MSVC's historically lagging C++ language support.
>

That seems a bit backwards - we use an old C++ language standard because we
support old versions of system compilers, rather than the other way around.
If we said "just download a binary package of the compiler, add it to your
PATH and use that" we could say "clang only builds with the latest clang
release", for instance.

> 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.
>
>
> I agree that we need better specified upgrade policies for tools we use or
> depend on. I don't think a one-size-fits-all policy is appropriate. I
> actually think Tom Stellard's suggestion of always upgrading after every
> branch has merits, although I might tweak it slightly to "reserve the right
> to upgrade" after every release branch.
>
> -Chris
>
>
>
>>
>> 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
>
>
> _______________________________________________
> 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/6d777174/attachment-0001.html>