At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers.
Historically we've taken into account recent versions of Visual Studio, Xcode and Linux distribution long term support packages when deciding what CMake version to require. While this does work, it has held us to old versions of CMake for long periods of time.
During the roundtable we discussed that the amount of effort involved in updating to a modern CMake is more or less the same regardless of what version we choose. We believe this to be true because most OS package managers have older versions, like the Ubuntu 18.04 LTS which has CMake 3.10.2 which was released January 18, 2018. Additionally CMake.org provides binary and source downloads, and building CMake from source has lower system requirements than LLVM and is very simple.
With all of this in mind at the roundtable we decided to propose raising the minimum required CMake version for all LLVM sub-projects to 3.15.0. Assuming there are no objections to this proposal, I propose a cut-over date of December 2, 2019.
Thanks,
-Chris
At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers.
Historically we've taken into account recent versions of Visual Studio, Xcode and Linux distribution long term support packages when deciding what CMake version to require. While this does work, it has held us to old versions of CMake for long periods of time.
During the roundtable we discussed that the amount of effort involved in updating to a modern CMake is more or less the same regardless of what version we choose. We believe this to be true because most OS package managers have older versions, like the Ubuntu 18.04 LTS which has CMake 3.10.2 which was released January 18, 2018. Additionally CMake.org provides binary and source downloads, and building CMake from source has lower system requirements than LLVM and is very simple.
With all of this in mind at the roundtable we decided to propose raising the minimum required CMake version for all LLVM sub-projects to 3.15.0. Assuming there are no objections to this proposal, I propose a cut-over date of December 2, 2019.
Will users of the CMake export files generated by LLVM also need to use 3.15.0 or
is it possibly to have the export files require an older version?
The 10.0 branchpoint will be in early January, I think it would be better
to wait until after the branch. Mainly because that doesn't give us a
lot of time to actually take advantage of the new features in 3.15.0 before the
branch, so I don't see much benefit in switching over at that date.
I think we should also decide on a long-term plan for CMake requirements.
If the conclusion is that users should be able to handle using the latest
(3.15.0) version of CMake, maybe we should just plan to always up-date to the
latest version in trunk after each release branch is created.
-Tom
+1 to bumping cmake version and cleaning build system somewhat.
> At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers.
>
> Historically we've taken into account recent versions of Visual Studio, Xcode and Linux distribution long term support packages when deciding what CMake version to require. While this does work, it has held us to old versions of CMake for long periods of time.
>
> During the roundtable we discussed that the amount of effort involved in updating to a modern CMake is more or less the same regardless of what version we choose. We believe this to be true because most OS package managers have older versions, like the Ubuntu 18.04 LTS which has CMake 3.10.2 which was released January 18, 2018. Additionally CMake.org provides binary and source downloads, and building CMake from source has lower system requirements than LLVM and is very simple.
>
> With all of this in mind at the roundtable we decided to propose raising the minimum required CMake version for all LLVM sub-projects to 3.15.0. Assuming there are no objections to this proposal, I propose a cut-over date of December 2, 2019.
>
Will users of the CMake export files generated by LLVM also need to use 3.15.0 or
is it possibly to have the export files require an older version?
The 10.0 branchpoint will be in early January, I think it would be better
to wait until after the branch. Mainly because that doesn't give us a
lot of time to actually take advantage of the new features in 3.15.0 before the
branch, so I don't see much benefit in switching over at that date.
I think we should also decide on a long-term plan for CMake requirements.
If the conclusion is that users should be able to handle using the latest
(3.15.0) version of CMake, maybe we should just plan to always up-date to the
latest version in trunk after each release branch is created.
Would it please be possible to have some reasonably sane
dependency versioning policy? Even debian sid only has 3.13.4-1.
How about accepting/requiring version which is at least 1 year old?
That would incidentally, result in requiring cmake v3.13
-Tom
Roman
+1 to bumping cmake version and cleaning build system somewhat.
At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers.
Historically we’ve taken into account recent versions of Visual Studio, Xcode and Linux distribution long term support packages when deciding what CMake version to require. While this does work, it has held us to old versions of CMake for long periods of time.
During the roundtable we discussed that the amount of effort involved in updating to a modern CMake is more or less the same regardless of what version we choose. We believe this to be true because most OS package managers have older versions, like the Ubuntu 18.04 LTS which has CMake 3.10.2 which was released January 18, 2018. Additionally CMake.org provides binary and source downloads, and building CMake from source has lower system requirements than LLVM and is very simple.
With all of this in mind at the roundtable we decided to propose raising the minimum required CMake version for all LLVM sub-projects to 3.15.0. Assuming there are no objections to this proposal, I propose a cut-over date of December 2, 2019.
Will users of the CMake export files generated by LLVM also need to use 3.15.0 or
is it possibly to have the export files require an older version?
The 10.0 branchpoint will be in early January, I think it would be better
to wait until after the branch. Mainly because that doesn’t give us a
lot of time to actually take advantage of the new features in 3.15.0 before the
branch, so I don’t see much benefit in switching over at that date.
I think we should also decide on a long-term plan for CMake requirements.
If the conclusion is that users should be able to handle using the latest
(3.15.0) version of CMake, maybe we should just plan to always up-date to the
latest version in trunk after each release branch is created.
Would it please be possible to have some reasonably sane
dependency versioning policy?
I’m not sure “sane” captures the nuance of your position - only suggests that Tom’s suggestion of upgrading to the latest release is “insane”?
What is it you’d like to avoid or that you find important/valuable about a one year old version of CMake, for instance? It means users have to update their CMake as frequently (since it doesn’t skip versions) - but allows some users to get this based on their distributions release, rather than having to do it manually/explicitly?
+1 to bumping cmake version and cleaning build system somewhat.
>
> > At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers.
> >
> > Historically we've taken into account recent versions of Visual Studio, Xcode and Linux distribution long term support packages when deciding what CMake version to require. While this does work, it has held us to old versions of CMake for long periods of time.
> >
> > During the roundtable we discussed that the amount of effort involved in updating to a modern CMake is more or less the same regardless of what version we choose. We believe this to be true because most OS package managers have older versions, like the Ubuntu 18.04 LTS which has CMake 3.10.2 which was released January 18, 2018. Additionally CMake.org provides binary and source downloads, and building CMake from source has lower system requirements than LLVM and is very simple.
> >
> > With all of this in mind at the roundtable we decided to propose raising the minimum required CMake version for all LLVM sub-projects to 3.15.0. Assuming there are no objections to this proposal, I propose a cut-over date of December 2, 2019.
> >
>
> Will users of the CMake export files generated by LLVM also need to use 3.15.0 or
> is it possibly to have the export files require an older version?
>
> The 10.0 branchpoint will be in early January, I think it would be better
> to wait until after the branch. Mainly because that doesn't give us a
> lot of time to actually take advantage of the new features in 3.15.0 before the
> branch, so I don't see much benefit in switching over at that date.
>
> I think we should also decide on a long-term plan for CMake requirements.
> If the conclusion is that users should be able to handle using the latest
> (3.15.0) version of CMake, maybe we should just plan to always up-date to the
> latest version in trunk after each release branch is created.
Would it please be possible to have some reasonably sane
dependency versioning policy?
I'm not sure "sane" captures the nuance of your position - only suggests that
Tom's suggestion of upgrading to the latest release is "insane"?
The "insane" word is not in my mail.
I'm only saying it will be good to document the actual versioning policy,
and it will be great if it's not "just manually download XYZ and use it".
What is it you'd like to avoid or that you find important/valuable about a one year old
version of CMake, for instance? It means users have to update their CMake
as frequently (since it doesn't skip versions) - but allows some users to get this
based on their distributions release, rather than having to do it manually/explicitly?
Extremely precisely, yes.
If you require The freshest version of something, it is all but guaranteed to
be not packaged in distributions, so basically *everyone* will have to
work around the packaging system. If the version is //somewhat// aged,
then it is not unreasonable to expect for it to be present in
//some// proper packaged form in //most// distros.
All that of course does not apply to platforms with no native packaging
system (windows?).
The exact definition of "aged" will not be precisely definable though,
I would guess 1 year is somewhat around what could be considered middle-ground.
Even debian sid only has 3.13.4-1.
How about accepting/requiring version which is at least 1 year old?
That would incidentally, result in requiring cmake v3.13
> -Tom
Roman
At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers.
Historically we’ve taken into account recent versions of Visual Studio, Xcode and Linux distribution long term support packages when deciding what CMake version to require. While this does work, it has held us to old versions of CMake for long periods of time.
During the roundtable we discussed that the amount of effort involved in updating to a modern CMake is more or less the same regardless of what version we choose. We believe this to be true because most OS package managers have older versions, like the Ubuntu 18.04 LTS which has CMake 3.10.2 which was released January 18, 2018. Additionally CMake.org provides binary and source downloads, and building CMake from source has lower system requirements than LLVM and is very simple.
With all of this in mind at the roundtable we decided to propose raising the minimum required CMake version for all LLVM sub-projects to 3.15.0. Assuming there are no objections to this proposal, I propose a cut-over date of December 2, 2019.
Will users of the CMake export files generated by LLVM also need to use 3.15.0 or
is it possibly to have the export files require an older version?
The export files don’t contain cmake version requirements, so they should work on older versions.
The 10.0 branchpoint will be in early January, I think it would be better
to wait until after the branch. Mainly because that doesn’t give us a
lot of time to actually take advantage of the new features in 3.15.0 before the
branch, so I don’t see much benefit in switching over at that date.
No objection from me.
I think we should also decide on a long-term plan for CMake requirements.
If the conclusion is that users should be able to handle using the latest
(3.15.0) version of CMake, maybe we should just plan to always up-date to the
latest version in trunk after each release branch is created.
This also sounds reasonable to me.
-Chris
+1 to bumping cmake version and cleaning build system somewhat.
At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers.
Historically we’ve taken into account recent versions of Visual Studio, Xcode and Linux distribution long term support packages when deciding what CMake version to require. While this does work, it has held us to old versions of CMake for long periods of time.
During the roundtable we discussed that the amount of effort involved in updating to a modern CMake is more or less the same regardless of what version we choose. We believe this to be true because most OS package managers have older versions, like the Ubuntu 18.04 LTS which has CMake 3.10.2 which was released January 18, 2018. Additionally CMake.org provides binary and source downloads, and building CMake from source has lower system requirements than LLVM and is very simple.
With all of this in mind at the roundtable we decided to propose raising the minimum required CMake version for all LLVM sub-projects to 3.15.0. Assuming there are no objections to this proposal, I propose a cut-over date of December 2, 2019.
Will users of the CMake export files generated by LLVM also need to use 3.15.0 or
is it possibly to have the export files require an older version?
The 10.0 branchpoint will be in early January, I think it would be better
to wait until after the branch. Mainly because that doesn’t give us a
lot of time to actually take advantage of the new features in 3.15.0 before the
branch, so I don’t see much benefit in switching over at that date.
I think we should also decide on a long-term plan for CMake requirements.
If the conclusion is that users should be able to handle using the latest
(3.15.0) version of CMake, maybe we should just plan to always up-date to the
latest version in trunk after each release branch is created.
Would it please be possible to have some reasonably sane
dependency versioning policy?
I’m not sure “sane” captures the nuance of your position - only suggests that
Tom’s suggestion of upgrading to the latest release is “insane”?
The “insane” word is not in my mail.
I’m only saying it will be good to document the actual versioning policy,
and it will be great if it’s not “just manually download XYZ and use it”.
What is it you’d like to avoid or that you find important/valuable about a one year old
version of CMake, for instance? It means users have to update their CMake
as frequently (since it doesn’t skip versions) - but allows some users to get this
based on their distributions release, rather than having to do it manually/explicitly?
Extremely precisely, yes.
If you require The freshest version of something, it is all but guaranteed to
be not packaged in distributions, so basically everyone will have to
work around the packaging system. If the version is //somewhat// aged,
then it is not unreasonable to expect for it to be present in
//some// proper packaged form in //most// distros.
Experience show that distros don’t keep CMake up to date anyway.
So why bother waiting 1 year, as it will most probably not change anything.
Moreover, cmake version is only a requirement for LLVM developers themselves and not LLVM users.
It is not uncommon to have to update the installed build tools when wanting to checkout and build a project, especially one of this size.
+1 to bumping cmake version and cleaning build system somewhat.
At the LLVM Developer Meeting on October 23rd we held a CMake roundtable. One of the items we discussed was adopting a more regular timeline for CMake upgrades. During the roundtable there was overwhelming support for upgrading CMake, and support for treating CMake differently than how we treat upgrading host compilers.
Historically we’ve taken into account recent versions of Visual Studio, Xcode and Linux distribution long term support packages when deciding what CMake version to require. While this does work, it has held us to old versions of CMake for long periods of time.
During the roundtable we discussed that the amount of effort involved in updating to a modern CMake is more or less the same regardless of what version we choose. We believe this to be true because most OS package managers have older versions, like the Ubuntu 18.04 LTS which has CMake 3.10.2 which was released January 18, 2018. Additionally CMake.org provides binary and source downloads, and building CMake from source has lower system requirements than LLVM and is very simple.
With all of this in mind at the roundtable we decided to propose raising the minimum required CMake version for all LLVM sub-projects to 3.15.0. Assuming there are no objections to this proposal, I propose a cut-over date of December 2, 2019.
Will users of the CMake export files generated by LLVM also need to use 3.15.0 or
is it possibly to have the export files require an older version?
The 10.0 branchpoint will be in early January, I think it would be better
to wait until after the branch. Mainly because that doesn’t give us a
lot of time to actually take advantage of the new features in 3.15.0 before the
branch, so I don’t see much benefit in switching over at that date.
I think we should also decide on a long-term plan for CMake requirements.
If the conclusion is that users should be able to handle using the latest
(3.15.0) version of CMake, maybe we should just plan to always up-date to the
latest version in trunk after each release branch is created.
Would it please be possible to have some reasonably sane
dependency versioning policy?
I’m not sure “sane” captures the nuance of your position - only suggests that
Tom’s suggestion of upgrading to the latest release is “insane”?
The “insane” word is not in my mail.
I’m only saying it will be good to document the actual versioning policy,
and it will be great if it’s not “just manually download XYZ and use it”.
What is it you’d like to avoid or that you find important/valuable about a one year old
version of CMake, for instance? It means users have to update their CMake
as frequently (since it doesn’t skip versions) - but allows some users to get this
based on their distributions release, rather than having to do it manually/explicitly?
Extremely precisely, yes.
If you require The freshest version of something, it is all but guaranteed to
be not packaged in distributions, so basically everyone will have to
work around the packaging system. If the version is //somewhat// aged,
then it is not unreasonable to expect for it to be present in
//some// proper packaged form in //most// distros.
Experience show that distros don’t keep CMake up to date anyway.
Do you have some data on that? It’d be interesting to see what sort of time horizon would help and by how much/little.
So why bother waiting 1 year, as it will most probably not change anything.
Moreover, cmake version is only a requirement for LLVM developers themselves and not LLVM users.
The same argument applies to the host compiler, though - which we’ve been more cautious about requiring more recent versions of.
CMake is extremely easy for developers to download and build locally – or just download binaries for if you like, too. It’s MUCH simpler than upgrading the host C compiler toolchain. Doing that can be extremely tricky – to the point of being nearly impossible for all but the most dedicated person. That’s the major reason why I think it’s entirely reasonable to require a new version of cmake, and not at all viable to require a new compiler.
As far as distro inclusion – if LLVM 10 requires CMake 3.15, I have full confidence that distros will manage to upgrade CMake first, before pulling in LLVM 10. I don’t think that’ll be a hardship to distro maintainers.
IMO, it will reduce overall pain if we attempt to keep the number of times we require a newer cmake as infrequent as we can. And we’ll get the most benefit if we use the latest release each time we do require such an upgrade.
Is there any script we can/would provide to help with this? Or is it so simple that two lines in the “getting started” instructions would be enough?
CMake is extremely easy for developers to download and build locally – or just download binaries for if you like, too.
Is there any script we can/would provide to help with this? Or is it so simple that two lines in the “getting started” instructions would be enough?
The instructions for building cmake are very simple: https://cmake.org/install/
We could easily link to that page from our docs.
-Chris
I am sure quite a number of packages not supported in the distribution are easy to build and install into /usr/local/bin and such.
It is not that it is easy to defeat the standard distribution and update procedures as that doing so puts that software out of sync with the standard update procedure. From then on the distribution update for cmake has no effect. I suspect there are fairly rigid rules on production computers against doing this.
I read an email below that said it is common that these kinds of out of distribution updates are required anyway. The only manual updates I have had to do outside the Ubuntu distribution packages (19.04) are for tbb and z3 which are not in the distribution anyway. I have had to install a number of additional packages from the distribution, but this is not the case under discussion.
For cmake then we are making a new, unique case, a case that I expect is against standard procedures for common production installations.
If there are no pressing reasons for this manual requirement, it is on its face a bad choice to make. It is against how common distribution software is done and has been done for some time now.
Neil Nelson
One note: CMake is available with pip, see
That makes it easy to install with system having python-pip, which is very likely on a developer machine.
Regards, Jonas
Previously when we suggested upgrading the documentation buildbots to use a newer version of recommonmark (see [1], with selected responses in [2], [3]), the feedback we got was that we should not upgrade the buildbots, because it would create a requirement on a version of recommonmark that isn’t available in any common package manager. (pip is explicitly mentioned as not a supported package manager). This was completely understandable, although very sad, because it limits adoption of markdown in documentation. We’ve even reverted some markdown back to rst because of it.
So now I’m confused why we’d be proposing that everyone must get download their own version of cmake (3.15) that no package manager has (e.g. latest debian repos have 3.13: https://packages.debian.org/search?keywords=cmake). Why not just bump the minimum to 3.10, which seems much more widely available?
[1] http://lists.llvm.org/pipermail/llvm-dev/2019-June/133038.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2019-June/133068.html
[3] http://lists.llvm.org/pipermail/llvm-dev/2019-June/133075.html
'Everyone' is overstating it a bit. For the platforms that I use for LLVM-related work, the 3.15.4 release of CMake was available via the common package system on the following dates:
- macOS, via Homebrew: 4 October, 2019.
- Windows, via Chocolatey: 2 October, 2019
- FreeBSD, via the package system on 5 October, 2019
It was tagged on 30 September, 2019 in CMake git (I presume it was then immediately released, but the CMake release notes and history page don't actually include dates), so that's a time from release to packaging of under a week for the slowest platform on that list.
Unless you're planning on moving to the new release on the day of the release, it will not be a problem for a large subset of the community.
The question if whether the cost of requiring people on platforms with lagging package sets to download a CMake binary or source tarball outside of their normal packaging infrastructure is higher than the cost of maintaining support for old versions of CMake.
David
Here's an argument for why to *lower* the minimum supported CMake version:
LLVM is a compiler backend.
LLVM is already the most difficult dependency to provide for most
projects that use it as a compiler backend. This is certainly true for
Zig, for example. This makes the requirements of building LLVM a
bottleneck in the bootstrapping process.
Any bump in minimum required CMake version increases the requirements of
the system to bootstrap a project which depends on LLVM.
For programming languages, a more minimal bootstrapping process is a
feature.
Therefore, bumping the minimum required CMake version of LLVM *removes a
feature* from any languages that depend on LLVM. This is O(N) cost where
N is the number of projects that depend on LLVM.
Zig has cmake_minimum_required(VERSION 2.8.5). LLVM's higher CMake
requirement is already the most demanding CMake version of all Zig's
dependencies. Making it any higher than it already is is strictly worse.
Why is newer CMake needed? What is LLVM's build process doing that is so
complicated that it needs bleeding edge CMake?
Regards,
Andrew
Such a script or instructions would be a more complicated build process
than before. A more complicated build process is anti-progress.
What specific benefits of bleeding edge CMake is so important, that this
anti-progress is worth it?
Andrew
Some concrete examples we talked about:
CMake 3.14 introduced CMAKE_TRY_COMPILE_TARGET_TYPE which allows using static libraries rather than executables when performing compiler checks which is important when building runtimes (you cannot link an executable when you don’t have a fully functional toolchain). This allows eliminating modules like https://github.com/llvm/llvm-project/blob/master/compiler-rt/cmake/Modules/BuiltinTests.cmake
CMake 3.12 introduced more powerful generator expressions that are evaluated only at generation time which means they aren’t dependent on the order in which individual CMake files were executed. This allows cleaning some of the hacks we currently rely on in places like libc++, see for example https://reviews.llvm.org/D68880
We can work around many of these issues, but these workarounds are expensive to maintain and error prone (especially with growing number of configurations).
3.14 has features that are pretty important for LLDB at the moment. The python library selection is a nest of flags and options that only clutter the configuration and make it difficult to easily build LLDB with python support, especially so on Windows.
For Windows, Visual Studio 2019 currently ships with CMake 3.15.1 in the installation, so it’s effectively a system package. Chocolatey may be useful if a newer snapshot is needed of course.