[RFC] Raise minimum required CMake version to 3.0

It came up on another thread that our current minimum required CMake version 2.8.8, has some bugs that cause issues when building with MSVC + Ninja, and one potential solution was to raise the minimum required version of CMake.

CMake 3.0 is now 6 months old and CMake 3.1 has been released. I would like to propose moving our minimum required CMake version to 3.0.

I’ve attached patches to enforce the change in case anyone wants to test it out.



CMake-3.0.0.diff (76 Bytes)

What is the latest version of CMake available for supported LTS versions of
ubuntu? The analogous other linux distros? I think if we can, we should
preserve support for their pre-installed CMake versions to make
bootstrapping easier.

I think it is fine to let folks that want to use Ninja on Windows grab a
more recent CMake -- this shouldn't block the 2013 stuff at all.

Ubuntu 14.04 has I’d be happy raising the minimum to that.

I’m not too familiar with Ubuntu’s LTS releases, but from some google digging I believe there are 3 active LTS releases.

10.04 has CMake 2.8.0 (which is already below our minimum), but 10.04 will be dropping out of LTS this year.
12.04 has CMake 2.8.7 (also below our minimum)
14.04 has CMake, which should also have the fix for MSVC

Based on this, it might be reasonable to update the minimum to instead of 3.0.0.


Looks likely to be good. Fedora 20 also has 2.8.12. I assume OS X is good
here? Windows I'm not worried about really.

Apple doesn’t ship CMake publicly. Our internal build clusters should all be running or later.

Any OS X users not on CMake can always download install packages from CMake.org.


OK, so its analogous to Windows. SGTM. (and no, I don't think you need to
wait for further review of patches)

+Galina, and Takumi

This was a very short lived change :-).

Looks like we have some bots that need to be updated.


Now, with more Galina and Takumi on the To line. :wink:


I don't oppose the subject. I will update cmake within a few days.

+ I and others have been using locally without issues for a while now, no problems with this from me.


I missed the context. We may stand on at first.

I will update my cmake from to soon.

I’m with Takumi, and prefer to go on a safe route.

Takumi, unless I’m missing something you were checking cmake 3.x with LLVM.
How does it look like? Did you discover any problem?



Chandler’s feedback was that we should go to instead of 3.0 because of Ubuntu’s LTS release.


Galina and Takumi,

Are we ready to update the minimum required version to


Ready, for me.

Ready on my side.



I just landed r230062, which sets the minimum required version to

I’ve also sent corresponding patches to cfe-commits (http://reviews.llvm.org/D7797).

If there are any problems I will revert.


Hi Chris,

this update broke my cmake LLVM+Polly buildbot (to my knowledge most other bots use autoconf). I reverted this temporarily to avoid the buildbot noise (this comes a little late, as I was traveling the last days).

The buildbot is based on the latest debian stable (wheezy), which comes with cmake 2.8.9. Is 2.8.9 enough to fix the bug?

Also, could we just limit the cmake version on windows builds? In the end on linux cmake 2.8.9 works great.


Rafael asked if updating the bot is not an option. It indeed is an option, but requires cmake to be manually downloaded and installed instead of using the available packages.

This is OK for one bot, but it will add complications for everybody who uses debian and wants to install LLVM. It also will make it more complicated to move to a fully cmake based build as all such debian based buildbots would require a manual installation of cmake (I have 12 more of these).

Before doing so I wanted to understand if it is indeed intended to require debian-stable users to *manually* install and manage cmake or if there is not a lower overhead version. Can this bug not be fixed for windows without complicating live for debian users?