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

[Daniel Sanders]

> 3. Ninja "pool = console" would fix the timeout issues on slow builds,
> but it's not clear how CMake would do that by default

I'm not sure I understand the second part of that statement. As far as I know, all we have to do is add USES_TERMINAL to the appropriate targets and this change was made in r222181. At this point having CMake >= 3.2 and Ninja >= 1.5 should be enough to make this work.

> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Renato Golin
> Sent: 11 March 2015 12:45
> To: Chandler Carruth
> Cc: jroelofs; LLVM Dev; Tobias Grosser
> Subject: Re: [LLVMdev] [RFC] Raise minimum required CMake version to 3.0
> 
> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev