[LLVMdev] [RFC] Raise minimum required CMake version to 3.0

[Renato Golin]

On 11 March 2015 at 04:14, Chandler Carruth <chandlerc at google.com> wrote:
> Just to rebase things a bit, here is some context.
>
> - This is a 60+ email thread spreading across a month of time.
> - I've not read every single email and I don't think it makes sense to
> assume the context of the first email applies to the most recent.

I think we all agree that we've all earned the "Bike Shed Master Badge" today.

Let me re-list all the reasons why we should move on, then all the
problems of doing so, so we can base our arguments on current facts.

== Pro move ==

1. Using OBJECT libraries (2.8.8) has massive improvement when linking
on Windows
2. CMAKE_SYSROOT and CMAKE_<LANG>_COMPILER_TARGET (3.0) would help fix
compiler-rt builds
3. Ninja "pool = console" would fix the timeout issues on slow builds,
but it's not clear how CMake would do that by default
4. Windows and OSX users already build by hand anyway

Item (1) was already solved by the move to 2.8.12, item (2) is pending
an upgrade to 3.0 and item (3) is uncertain that any move will fix
that.

Item (4) is circumstantial, at best.

== Problems ==

A. LTS Linux users (by far, the biggest constituency among Linux
users) are stuck old versions of CMake in their packages.
B. Installing by hand on Linux is, of course, possible, but it
increases the cost of package management (see below). (ref item 4).
C. The number of types of machines Linux runs on eclipses anything
Windows and Mac added together. The number of people affected by this
move would be very big.

In a nutshell, building by hand on Linux is easy, but upsets the
management balance, which multiplied by the number of people and the
number of machines each one of them manages, amounts to an appreciable
cost.

As a concrete example, between ARM and AArch64, we have currently 12
buildbots, and a larger number of internal bots, test boxes,
development boards. Every update would have us to upgrade the
packages, possibly re-build cmake, and re-install it, and work around
library names that are not exactly right (like libX.so.12 instead of
libX.so.11), etc. Doing that on buildbots is never a wise choice.

Windows and Mac users will never have these problems when installing
CMake from source/tarball.

== Discussion ==

I just built CMake 3.0 from scratch on a Chromebook 2 and it took me
less than the time I'm writing this email. A user that is advanced
enough to want to compiler LLVM and Clang will most certainly be able
to build CMake (and Ninja) first. Some won't even need to, since CMake
does provide binary releases for Linux on their website.

The biggest problem seems to be a potential increase in the cost of
package management, which is limited to Ubuntu and RHEL. Debian Jesse
(to be marked stable *very* soon) will come with 3.0, and Fedora, Arch
and others are already on it or newer. But LTS users are a large
number of users.

The refusal is not that strong, I agree, but the concrete benefits,
which right now is just "a nicer way to fix compiler-rt" also don't
seem strong enough to counter that weak refusal.

== Conclusion ==

I think neither of sides have a strong argument. That's made clearer
by the amount of bikeshedding we've done. This also seem to have
turned into a Windows vs. Linux battle, which is never a good thing.

We have made intentional to follow LTS releases on our versioning, and
this change would break the model. Breaking the model is not always
bad, but it requires a strong argument. We don't have one. Even if the
counter-argument is also weak, it holds true to our previous
intentions. We did break the model when we moved to C++11 and that was
a good thing. I don't want to move the build infrastructure too
because of that momentum alone.

I personally don't care that much which version of CMake we use, and
I'm trying to be unbiased here. If there is a stronger argument than
item 2 above, then I'd be in favour of moving. Right now, the
arguments are not strong enough, for me, personally.

cheers,
--renato