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

[Mehdi Amini]

> On Mar 11, 2015, at 5:45 AM, Renato Golin <renato.golin at linaro.org> wrote:
> 
> 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.

Note: I continue to have the impression that the discussion is oriented like there is no other option than building CMake from source.
They ship Linux binaries and there are Ubuntu PPAs available (I know that not everyone can use PPA, but many can). The burden for LTS user does not really seem “high”.

Mehdi




> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev