Raising CMake minimum version to 3.4.3

Hello llvm-dev and cfe-dev,

I want open up the discussion of upgrading our minimum required CMake version.

In the past when we’ve discussed this one of the major reasons for not moving forward was that the Ubuntu LTS release was on CMake 2.8.12.x. A few days ago Ubuntu 16.04, the new LTS, was released, and it contains CMake 3.5.1.

I have a couple of motivations for this, the biggest of which is that I’ve hit a wall trying to overcome some limitations in the CMake ExternalProject module which I can’t get past without being on CMake 3.4 or newer. These limitations make using ExternalProject to build the LLVM test-suite and runtime libraries (compiler-rt, libcxx, etc) difficult.

The other big motivation that I have for this is the ability to cleanup code. We have a lot of CMake code that checks CMAKE_VERSION and enables and disables features used on the version. None of the places where we currently have CMAKE_VERSION checks should impact build correctness, but most people don’t realize that if you’re using Ninja your build will be faster on a newer CMake than on an older one. It would be nice if we just pushed the bar up and could remove a bunch of those conditionals.

To do this we need bot maintainers to update their CMake installations, so we need some consensus that (1) we want to do this and (2) what a reasonable timeline for doing it is.

What I’d like to do is raise the minimum version for all LLVM projects to CMake 3.4.3 at the end of May. Setting the date at the end of May gives bot maintainers and developers lots of time to update, and CMake 3.4.3 is the last CMake 3.4 release and it is widely available. For reference here’s a list of linux distributions and their CMake versions:

Ubuntu Wily -> 3.2.2
Ubuntu Xenial -> 3.5.1
Ubuntu Yakkety -> 3.5.1
Debian jessie -> 3.0.2
Debian stretch -> 3.5.1
Debian sid -> 3.5.2
FreeBSD 10.2 -> 3.5.0
FreeBSD HEAD -> 3.5.2

Feedback?

Thanks,
-Chris

Why not 3.5.1?

Cheers,
Rafael

Actually forward to LLVM-dev because I obviously don’t know how email works…

-Chris

I’m not opposed to 3.5.1, I was suggesting 3.4.3 because it is a more stable conservative release, and it is available on basically ever reasonably recent OS release except Debian jessie.

-Chris

+1. Cmake is completely trivial to install yourself. You don’t even need to install it, even, you can just run it from the build directory. IMO, if there’s any reason why a newer version would be useful, it’s totally worth just requiring an upgrade instead of spending time trying to overcome limitations of the old version.

Perhaps the buildbots could just ensure that a recent cmake is built, as the first build step, to avoid having to coordinate with all the bot maintainers.

Hello llvm-dev and cfe-dev,

I want open up the discussion of upgrading our minimum required CMake version.

In the past when we’ve discussed this one of the major reasons for not moving forward was that the Ubuntu LTS release was on CMake 2.8.12.x. A few days ago Ubuntu 16.04, the new LTS, was released, and it contains CMake 3.5.1.

I have a couple of motivations for this, the biggest of which is that I’ve hit a wall trying to overcome some limitations in the CMake ExternalProject module which I can’t get past without being on CMake 3.4 or newer. These limitations make using ExternalProject to build the LLVM test-suite and runtime libraries (compiler-rt, libcxx, etc) difficult.

The other big motivation that I have for this is the ability to cleanup code. We have a lot of CMake code that checks CMAKE_VERSION and enables and disables features used on the version. None of the places where we currently have CMAKE_VERSION checks should impact build correctness, but most people don’t realize that if you’re using Ninja your build will be faster on a newer CMake than on an older one. It would be nice if we just pushed the bar up and could remove a bunch of those conditionals.

To do this we need bot maintainers to update their CMake installations, so we need some consensus that (1) we want to do this and (2) what a reasonable timeline for doing it is.

What I’d like to do is raise the minimum version for all LLVM projects to CMake 3.4.3 at the end of May. Setting the date at the end of May gives bot maintainers and developers lots of time to update, and CMake 3.4.3 is the last CMake 3.4 release and it is widely available. For reference here’s a list of linux distributions and their CMake versions:

Ubuntu Wily -> 3.2.2
Ubuntu Xenial -> 3.5.1
Ubuntu Yakkety -> 3.5.1
Debian jessie -> 3.0.2
Debian stretch -> 3.5.1
Debian sid -> 3.5.2
FreeBSD 10.2 -> 3.5.0
FreeBSD HEAD -> 3.5.2

Feedback?

How did you determine that FreeBSD 10.2 is using cmake 3.5.0? On my FreeBSD 10.3 system, I have cmake version 3.4.1 (I think it got installed from ports when I installed other software).

Also, I see that you sent this to llvm-dev@lists.apple.com. Shouldn't this also go to llvm-dev@lists.llvm.org (or are they the same list)?

Third, just to nitpick, FreeBSD is not a Linux distribution. :slight_smile:

Regards,

John Criswell

Hello llvm-dev and cfe-dev,

I want open up the discussion of upgrading our minimum required CMake version.

In the past when we’ve discussed this one of the major reasons for not moving forward was that the Ubuntu LTS release was on CMake 2.8.12.x. A few days ago Ubuntu 16.04, the new LTS, was released, and it contains CMake 3.5.1.

I have a couple of motivations for this, the biggest of which is that I’ve hit a wall trying to overcome some limitations in the CMake ExternalProject module which I can’t get past without being on CMake 3.4 or newer. These limitations make using ExternalProject to build the LLVM test-suite and runtime libraries (compiler-rt, libcxx, etc) difficult.

The other big motivation that I have for this is the ability to cleanup code. We have a lot of CMake code that checks CMAKE_VERSION and enables and disables features used on the version. None of the places where we currently have CMAKE_VERSION checks should impact build correctness, but most people don’t realize that if you’re using Ninja your build will be faster on a newer CMake than on an older one. It would be nice if we just pushed the bar up and could remove a bunch of those conditionals.

To do this we need bot maintainers to update their CMake installations, so we need some consensus that (1) we want to do this and (2) what a reasonable timeline for doing it is.

What I’d like to do is raise the minimum version for all LLVM projects to CMake 3.4.3 at the end of May. Setting the date at the end of May gives bot maintainers and developers lots of time to update, and CMake 3.4.3 is the last CMake 3.4 release and it is widely available. For reference here’s a list of linux distributions and their CMake versions:

Ubuntu Wily → 3.2.2
Ubuntu Xenial → 3.5.1
Ubuntu Yakkety → 3.5.1
Debian jessie → 3.0.2
Debian stretch → 3.5.1
Debian sid → 3.5.2
FreeBSD 10.2 → 3.5.0
FreeBSD HEAD → 3.5.2

Feedback?

How did you determine that FreeBSD 10.2 is using cmake 3.5.0? On my FreeBSD 10.3 system, I have cmake version 3.4.1 (I think it got installed from ports when I installed other software).

I have a fully updated FreeBSD 10.2 machine and ran “pkg search cmake”. It came back with 3.5.0. I’m not sure what version it released with, but the updated version is in the ports collection.

Also, I see that you sent this to llvm-dev@lists.apple.com. Shouldn’t this also go to llvm-dev@lists.llvm.org (or are they the same list)?

I auto-completed llvm-dev incorrectly on my original email and have been fixing it on subsequent replies.

Third, just to nitpick, FreeBSD is not a Linux distribution. :slight_smile:

Should have probably said *nix :slight_smile:

-Chris

I think I see the issue: the initial ports collection provides cmake 3.4.1, but if you use pkg update, you get cmake 3.5.0. Is that correct? Ideally, I’d like LLVM to build right out of the box after I install a system. From that point of view, I’d argue for dropping your requirement from 3.4.3 to 3.4.1, which may be reasonable if there aren’t any necessary features that were added between 3.4.1 and 3.4.3 that you need. If you decide to go to cmake 3.4.3, you might want to modify the LLVM Getting Started Guide with text stating that the system will need to be updated in order to build LLVM. If you’re going to require a system update before LLVM would compile, a heads-up in the docs would be useful. Regards, John Criswell

We can’t assume every Linux is Ubuntu, nor that every platform has packages for this or that release.

You are asking for a move to built CMake support, from packages, and that’s a big move. We can’t control CMake’s progress nor its repository.

This is bigger than a simple version upgrade, regardless of which version the new Ubuntu or freebsd ships, or the fact that other systems already need to build it.

Cheers,
Renato

I’m an outsider and I really support that change. CMake evolves and being stuck to ancient versions is really a problem.
Newer versions of CMake help a lot to cleanup some mess, add some really welcome features and becomes faster.
I don’t think anyone is really stuck to any old version though:

CMake itself is released and packaged by CMake. You can download binaries from their website for major platforms.And it doesn’t have to be a DEB or RPM package, it’s a portable tar.gz file that can be unpacked with statically linked
binaries. You don’t even need to be root to use it and it could even be automated for most platforms using some build
scripts that fetch the dependencies.

For the other platforms, you could build it from source, which is really easy. Newer versions of CMake still support some
really ancient platforms, so I don’t think anyone will have issues doing that. If you’re using an exotic platform, you should
be used to compiling your own software anyway, so I don’t think this will be an issue for them.

Do Windows devs get stuck because the Windows packaging system doesn’t come with the latest version of CMake?
They don’t have any, so they download the installer, use the updated version and don’t complain (too) much.

I require the latest major version of CMake version in my own projects and I don’t think that has been an issue.
I personally have issues with “bad” build script and I’d support any effort to improve the situation.

My 2 cents,
Florent

cmake is a big dependency, but it doesn’t seem to have many dependencies itself. They say it’s just a C++ compiler and a make (not necessarily gnu). Probably there are one or two more than that :slight_smile: A shell, for a start; git or tar/gzip etc.

The current *nix source tarball is 6.4 MB gzipped. Just for fun I grabbed it and tried building on four machines:

  • 3.4 GHz i7 3770 with Ubuntu 14.04
  • 2.2 GHz 2011 i7 MacBook Pro with Yosemite
  • Odroid XU4 with Ubuntu Mate 15.10 (Exynos5422 4x A15 @2GHz, 4x A7 @1.4 GHz)
  • Raspberry Pi 3 with Raspbian (4x A53 @1.2 GHz)

I used --parallel=4 on the Pi, 8 on the others

./bootstrap

  • 1m10s linux
  • 2m05s mbp
  • 3m18s xu4
  • 7m28s pi3

make

  • 1m07s linux
  • 1m18s mbp
  • 5m14s xu4
  • 16m31s Pi3

I don’t think anyone is really stuck to any old version though:

This is a limited picture that we have addressed on previous similar
threads about CMake. Please search the archives for CMake, Ninja and
"versions" to see the whole context.

Now, to your points...

Not everyone has the ability to pick and choose whatever they want.
Also, local development is different than buildbot deployment, and we
do have a lot of obscure targets with obscure operating systems.

Most CMake development has been done on a selective way so far, and
it's working well. IFF you have CMake X.Y.Z, enable this feature. IFF
you have Ninja 1.5.X, enable that one. This is the best way to go for
now.

CMake itself is released and packaged by CMake. You can download binaries
from their website for major platforms.
And it doesn’t have to be a DEB or RPM package, it’s a portable tar.gz file
that can be unpacked with statically linked
binaries. You don’t even need to be root to use it and it could even be
automated for most platforms using some build
scripts that fetch the dependencies.

You're assuming everyone can just install whatever they want on their
company servers...

For the other platforms, you could build it from source, which is really
easy. Newer versions of CMake still support some
really ancient platforms, so I don’t think anyone will have issues doing
that. If you’re using an exotic platform, you should
be used to compiling your own software anyway, so I don’t think this will be
an issue for them.

You're assuming it's easy to compile based on your experience, but
have you tested cross-compiling it to old distributions?

Do Windows devs get stuck because the Windows packaging system doesn’t come
with the latest version of CMake?
They don’t have any, so they download the installer, use the updated version
and don’t complain (too) much.

Is this an argument that Linux users shouldn't be worried about binary
installers just because Windows users do that all the time? Because if
it is, it doesn't hold water.

cheers,
--renato

It needs a compatible version of C and C++ libraries. If you build on
a modern machine but run on an older Linux, you'll get at least
libstdc++ clashes.

Also, compiling CMake and Ninja is not the most reliable way of
deploying buildbots.

What's wrong with using newer CMake features IFF you have that
version? Then you can choose where to incur the extra deployment cost
or not based on your need of that feature.

cheers,
--renato

For the other platforms, you could build it from source, which is really
easy. Newer versions of CMake still support some
really ancient platforms, so I don’t think anyone will have issues doing
that. If you’re using an exotic platform, you should
be used to compiling your own software anyway, so I don’t think this will be
an issue for them.

Do Windows devs get stuck because the Windows packaging system doesn’t come
with the latest version of CMake?
They don’t have any, so they download the installer, use the updated version
and don’t complain (too) much.

+1

Same for OS X.

I work on linux most of the time and fully support upgrading cmake to
whatever version people writing our cmake files find useful. I have no
idea what cmake version the distribution I use ships, and I see no
point in looking that up. Building cmake is truly trivial. Anyone (or
any bot) that can build llvm can build cmake.

Cheers,
Rafael

Probably no one cares, but add to those, machines at home:

  • i7 6700k, ubuntu 14.04: bootstrap 0m32s, make 0m35s
  • Raspberry Pi 2 (4x A7 @900 MHz), Raspbian: bootstrap 9m40s, make 20m41s

Interesting that the Pi 3 only gains 25% - 30% over the Pi 2, whereas the newer i7 is double the speed of the 2012 one.

cmake is a big dependency, but it doesn't seem to have many dependencies
itself. They say it's just a C++ compiler and a make (not necessarily gnu).
Probably there are one or two more than that :slight_smile: A shell, for a start; git
or tar/gzip etc.

It needs a compatible version of C and C++ libraries. If you build on
a modern machine but run on an older Linux, you'll get at least
libstdc++ clashes.

It doesn’t link dynamically with libstdc++ and it requires glibc 2.2.5 apparently, from 2002.
They make sure it works on ancient systems when they do a release.
If you want to build a bleeding edge compiler on a system from 2002, you may have bigger issues
than trying to run CMake.

Also, compiling CMake and Ninja is not the most reliable way of
deploying buildbots.

Ninja is not the problem here though and I would agree that it’s not reliable.
Fortunately, CMake can generate projects compatible with quite old versions of Make already.

What's wrong with using newer CMake features IFF you have that
version? Then you can choose where to incur the extra deployment cost
or not based on your need of that feature.

Maintenance burden.
Few people will understand why there’s 2 code paths in the build script and will duplicate the wrong
one when creating a new module and looking for “inspiration".

cheers,
--renato
_______________________________________________
cfe-dev mailing list
cfe-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

/Florent

If you want to build a bleeding edge compiler on a system from 2002, you may have bigger issues
than trying to run CMake.

If you're cross compiling, you have less of a choice over what's on
the target and host.

Maintenance burden.
Few people will understand why there’s 2 code paths in the build script and will duplicate the wrong
one when creating a new module and looking for “inspiration".

That would be quickly caught by buildbots. We deal with that issue already.

To be clear, I'm not against moving the version up, I just want to
make sure that people understand that this is not *just* a version
upgrade, but a development philosophy move for all Linux developers
and production environments (of which we have plenty). This move was
proposed before and was rejected for the reasons I pointed out:
maintenance.

Once we go the path of accepting compiled versions of CMake, then
anyone will be able to add any feature and put the maintenance burden
on who had nothing to do with it, ie, production environment
maintainers. Having a cap on CMake/Ninja has the great advantage that
production environments will remain stable for as long as possible and
I can plan my migrations.

So far, the argument for a new CMake is that it's "nicer", not that it
has a feature that we cannot go without, and that's not strong enough,
especially when against increased production environment maintenance
cost.

--renato

To be clear, I'm not against moving the version up, I just want to
make sure that people understand that this is not *just* a version
upgrade, but a development philosophy move for all Linux developers
and production environments (of which we have plenty). This move was
proposed before and was rejected for the reasons I pointed out:
maintenance.

Yes. It is a move to put linux developers in the same position as
windows and OS X ones, which is a *very* reasonable thing to do.

Cheers,
Rafael

Apart from the fact that neither Windows nor OSX users have a choice.

We have discussed this before, Rafael, and I don't think doing it
again will yield different results unless new evidence is brought to
light.

Unless there is a feature in a newer CMake that we *must* have, I see
no need to upgrade the version. In the same way we've been holding on
C++11/14 functionality because MSVC couldn't cope with anything until
recently.

Trying to go too fast on the cool tools can create a patchwork of
versions and functionality that will make it very hard to debug
buildbot problems.

LLVM is not a toy any more, we can't just expect that everyone can get
the same environment we have on our own machines, or we'll fall into
the "works for me" style of closing bugs that is pervasive of open
source projects where only a few people ever commit code to.

Now, back to Chris' point:

Is the ExternalProject the only sane way to build compiler-rt and
libc++? Because this IS a big point.

Will it allow a way to build Compiler-RT and libc++ for *all*
supported platforms (as in -DLLVM_TARGETS_TO_BUILD)? Would it be
possible (even if not nice) to do so with an older version of CMake?
How worse would it be, if possible?

Until we can answer all these questions, build times and personal
preferences have no impact on such a big decision.

cheers,
--renato

Yes. It is a move to put linux developers in the same position as
windows and OS X ones, which is a very reasonable thing to do.

Apart from the fact that neither Windows nor OSX users have a choice.

We have discussed this before, Rafael, and I don’t think doing it
again will yield different results unless new evidence is brought to
light.

Unless there is a feature in a newer CMake that we must have, I see
no need to upgrade the version. In the same way we’ve been holding on
C++11/14 functionality because MSVC couldn’t cope with anything until
recently.

I don’t think this is really the right tradeoff.

The folks working on our build infrastructure have limited time. Making them cope with designing the usage of CMake in such a way that it gracefully degrades across many major versions of CMake makes their work substantially harder, and even if it is theoretically possible to do, it may become sufficiently annoying or slow to do that we simply don’t get improvements to how we build things.

And I think that the same tradeoff holds for C++11 features. We didn’t need any of them, and we actually pushed the Windows platform harder than all of the others because it was the one holding us back. And I think that was good because it made the developers substantially more productive. In this case, it’s just the build infrastructure and not the entire codebase, but I think a similar argument holds. If the functionality in CMake 3.4 makes Chris’s job on CMake substantially easier, and it at least seems reasonable to get access to that version of CMake, I’m very supportive of the change.

Trying to go too fast on the cool tools can create a patchwork of
versions and functionality that will make it very hard to debug
buildbot problems.

I’m not really sure how pushing towards newer released and stable versions will cause more of a patchwork of versions than following the distro installed versions. It seems to involve strictly fewer versions of CMake. But maybe I’m not understanding your concern here?

LLVM is not a toy any more, we can’t just expect that everyone can get
the same environment we have on our own machines, or we’ll fall into
the “works for me” style of closing bugs that is pervasive of open
source projects where only a few people ever commit code to.

I don’t see anyone on the thread arguing that. I think Chris is trying to argue instead that this version of CMake is sufficiently widely available that we should adopt it because the benefits outweigh the costs.

But I do think we need to carefully evaluate the availability outside of Debian and Ubuntu distros, so I did some more research and found:

  • Most major Linux distros have support out of the box in their “current” version (OpenSUSE, Fedora, Ubuntu, Debian, Arch), and several in a released version (Ubuntu, Debian, Arch).
  • FreeBSD has support out of the box in the latest port snapshot (as Chris indicated)
  • Homebrew and fink (package managers for OSX) have support out of the box, and CMake provides binaries for OSX that can be readily installed
  • Windows has binary installers available from CMake

There are some OSes where this version is unavailable even in the latest release. The most notable IMO is CentOS which doesn’t have it in any release. The next most notable is OpenSUSE which only has it in its latest “tumbleweed” rolling update. I just don’t think it is reasonable for us to continue to hold back our development tools based on these limitations. I think we regressed several more distros when we switched our requirement to GCC 4.7.

But clearly we do need a fallback option for folks that are on an OS that doesn’t provide CMake or that can’t install packages using the package manager into the primary OS. I’m totally supportive of that use case.

Here is the thing: the requirements to build and use CMake (not install!) are a strict subset of the requirements to build and use LLVM itself. So I see no way that this will be a limiting factor for folks. If it would help we could even bundle a copy of the CMake source code at a known good snapshot in the LLVM project and write a wrapper script to bootstrap it into a known location and then use it for subsequent builds … but that seems unnecessary to me.

I’ll go back to my analogy: we require a relatively modern C++ compiler (in fact, it is past due to update our requirements there…). The reason is that if you are building a compiler from source, it seems entirely reasonable to expect you to either use a relatively modern OS environment, or to have the wherewithal to bootstrap things using one of the numerous options available. Adding CMake to the potential set of things you need to bootstrap seems like an extremely small incremental burden compared to that of getting a modern C++ toolchain. (Although clearly they won’t always both be required in the same situations.)

Now, back to Chris’ point:

Is the ExternalProject the only sane way to build compiler-rt and
libc++? Because this IS a big point.

Will it allow a way to build Compiler-RT and libc++ for all
supported platforms (as in -DLLVM_TARGETS_TO_BUILD)? Would it be
possible (even if not nice) to do so with an older version of CMake?
How worse would it be, if possible?

Until we can answer all these questions, build times and personal
preferences have no impact on such a big decision.

I think removing impedance from the development of the CMake build, or enabling new functionality such as properly bootstrapped runtime libraries, are absolutely things to weigh against the cost of using a newer tool.

-Chandler