[llvm-dev] Upgrading LLVM's minimum required CMake version
Shoaib Meenai via llvm-dev
Our current required minimum version is CMake 3.4.3, which was released on January 25th 2016. It’s interesting to note that LLVM started requiring 3.4.3 on May 31st 2016, which was just 4 months after its release.
Let’s look at the CMake versions available on various distros and operating systems. I’m unfamiliar with many of these, so I apologize if I get something wrong. (I’m using pkgs.org for most of this information.)
* RHEL 6 (released Nov 10th 2010) : 3.6.1 (via EPEL)
* RHEL 7 (released June 10th 2014): 3.14.7 (via EPEL)
* RHEL 8 (released May 7th 2019): 3.11.4 (maybe pkgs.org is screwy on this one, because it doesn’t make sense that RHEL 7 should have a newer available version than RHEL 8)
* Debian 9 (released June 17th 2017): 3.7.2
* Debian 10 (released July 6th 2019): 3.13.4
* Ubuntu 16.04 LTS (released April 21st 2016): 3.5.1
* Ubuntu 18.04 LTS (released April 26th 2018): 3.10.2
* FreeBSD 11 (released October 10th 2016): 3.15.5 (presumably upgraded in a point release)
* FreeBSD 12 (released December 11th 2018): 3.15.5 (presumably upgraded in a point release)
* NetBSD 8.1 (released May 31st 2019): 3.16.1
* NetBSD 9.0 (released February 14th 2020): 3.16.1
* OpenBSD: couldn’t find the version
* macOS: latest version is readily available through Homebrew
* Windows: You can install it yourself or use the one bundled with Visual Studio. I don't know what versions are bundled with Visual Studio; some searching suggests Visual Studio 2017 has CMake 3.12 and Visual Studio 2019 has 3.15, though I have no confirmation of that.
Note that CMake provides prebuilt binaries for Linux, macOS, and Windows, and it’s also straightforward to build from source (it has very conservative compiler requirements). One suggestion that was brought up in the past was for LLVM’s build system to just download a newer version of CMake if you attempted to build it using one that was too old, but there was opposition [1]. There was also a suggestion to have a script in LLVM to download and build CMake for you, but there were mixed opinions on this too [2], particularly since many developers might prefer downloading a binary release to building from source themselves (though of course the script could also download binary releases if applicable). I personally think downloading or building CMake yourself isn’t a high barrier for anyone wanting to build LLVM (and in particular it’s *much* more straightforward than building LLVM itself), but I can understand why people would prefer to stick to versions available in distros.
Another suggestion that came up last time was to set a policy for upgrading CMake versions on some regular basis. The opposition to this was that we should upgrade CMake versions only when a newer version has a compelling enough feature to justify upgrading, rather than always upgrading. I can see arguments for both approaches, but we should definitely at least think about the benefits we can get from upgrading versions. I've gone through the CMake release notes and highlighted features which seemed potentially valuable for LLVM. Note that I'm only highlighting features for which our minimum CMake version would have to be bumped up in order for our build system to take advantage of. There are other useful features in newer CMake versions, but you can take advantage of them just by using a newer CMake yourself. For example, 3.9 loosens the dependencies of object compilation, which should result in faster Ninja builds.
CMake 3.5 (released March 8th 2016):
* install(DIRECTORY) supports generator expressions
CMake 3.6 (released July 7th 2016):
* install() supports EXCLUDE_FROM_ALL
* list() supports FILTER to filter by regular expression
* Subninja support, which could theoretically be used for much faster runtimes builds, although in practice we probably want to make ExternalProject support this directly instead of trying to layer our own meta-build system on top
* CMAKE_TRY_COMPILE_TARGET_TYPE to tell try_compile to build a static library instead of an executable, which will greatly simplify the compiler-rt build
CMake 3.7 (released November 11th 2016):
* New if() comparison operators LESS_EQUAL, GREATER_EQUAL, STRLESS_EQUAL, STRGREATER_EQUAL, VERSION_LESS_EQUAL, and VERSION_GREATER_EQUAL
CMake 3.8 (released April 10th 2017):
* Compile features for C++17, which is required to build libc++ correctly
* Support for compile features for specific C++ features instead of only being able to specify standard versions
* rpath support via BUILD_RPATH target property and CMAKE_BUILD_RPATH variable
* Apple framework support for static libraries
* New swig_add_library command in the UseSWIG module
* New generator expression $<IF:cond,true-value,false-value>
CMake 3.9 (released July 18th 2017):
* install(TARGETS) and install(EXPORTS) support for object libraries, which will simplify the compiler-rt build
* TARGET_OBJECTS generator expression support in add_custom_command and file(GENERATE)
* $<TARGET_BUNDLE_DIR:tgt> and $<TARGET_BUNDLE_CONTENT_DIR:tgt> generator expressions for Apple bundles
CMake 3.10 (released November 20th 2017):
* include_guard() command for proper guarding against double includes of CMake scripts
* An interesting aside is that this is the first verion of CMake to require C++11 to build, which should give a good sense of how conservative they are about compiler requirements
CMake 3.11 (released March 28th 2018):
* add_library() and add_executable() can be called without sources as long as target_sources() is used later
* target_compile_{definitions,features,options}, target_include_directories(), target_sources(), and target_link_libraries() can set the corresponding INTERFACE_* properties on imported targets
* COMPILE_DEFINITIONS supports generator expressions
* COMPILE_OPTIONS source file property added
* INCLUDE_DIRECTORIES source file property added
* Interface libraries support custom properites
CMake 3.12 (released July 17th 2018):
* add_compile_definitions() added to add compile definitions for targets (to avoid the global pollution caused by add_definitions())
* cmake_minimum_required() supports a version range to indicate tested CMake versions and set policies accordingly
* file(TOUCH) and file(TOUCH_NOCREATE) added
* list(JOIN), list(SUBLIST) and list(TRANSFORM) added
* string(JOIN) added
* SHELL: prefix support in target_compile_options to avoid errant deduplication
* target_link_libraries() supports object libraries and propagates usage requirements
* EXPORT_PROPERTIES target property to control the target properties exported by export() and install(EXPORT)
* FindLibXml2 provides imported targets
* New FindPython, FindPython2, and FindPython3 modules to ease location Python and selecting a specific version
* Modernization of UseSWIG module
* New generator expressions $<GENEX_EVAL:...>, $<TARGET_GENEX_EVAL:target,...>, $<IN_LIST:...>, $<TARGET_EXISTS:...> and $<TARGET_NAME_IF_EXISTS:...>
* Compile features support for C++20
CMake 3.13 (released November 20th 2018):
* cmake -E create_symlink supported on Windows
* target_link_directories() and target_link_options() commands to set link options instead of awkwardly having to use target_link_libraries() for this purpose
* UseSWIG can manage INCLUDE_DIRECTORIES for SWIG compilation
CMake 3.14 (released March 14th 2019):
* file(CREATE_LINK) to create hard or symbolic links
* if(DEFINED CACHE{VAR}) for checking if a cache variable is defined
* $<IN_LIST:...> generator expression correctly handles empty argument
* Fixes for object library linking propagation
* Link options to manage position independent executables added automatically
CMake 3.15 (released July 17th 2019):
* list(PREPEND), list(POP_FRONT) and list(POP_BACK) added
* New message() types NOTICE, VERBOSE, DEBUG and TRACE
* string(REPEAT) added
* MSVC_RUNTIME_LIBRARY target property and CMAKE_MSVC_RUNTIME_LIBRARY variable to select the runtime library type for MSVC
* $<C_COMPILER_ID:...>, $<CXX_COMPILER_ID:...>, $<COMPILE_LANGUAGE:...>, and $<PLATFORM_ID:...> generator expressions support matching one value from a list
* $<COMPILE_LANG_AND_ID:...> generator expression added
* $<FILTER:list,INCLUDE|EXCLUDE,regex> generator expression added
* $<REMOVE_DUPLICATES:list> generator expression added
* New $<TARGET_FILE*> generator expressions added: $<TARGET_FILE_PREFIX:...>, $<TARGET_FILE_BASE_NAME:...>, $<TARGET_FILE_SUFFIX:...>, $<TARGET_LINKER_FILE_PREFIX:...>, $<TARGET_LINKER_FILE_BASE_NAME:...>, $<TARGET_LINKER_FILE_SUFFIX:...>, $<TARGET_PDB_FILE_BASE_NAME:...>
* $<TARGET_OBJECTS:...> generator expression supports executables and static, shared, and module libraries
CMake 3.16 (released November 26th 2019):
* Support for generator expressions in BUILD_RPATH and INSTALL_RPATH
CMake 3.17 (released March 20th 2020):
* Ninja Multi-Config generator, which among other things would greatly simplify LLVM_OPTIMIZED_TABLEGEN
* foreach(ZIP_LISTS) added to iterate multiple lists simultaneously
* New message() keywords CHECK_START, CHECK_PASS, and CHECK_FAIL
* INSTALL_NAME_DIR supports generator expressions
Our build system is incredibly complex, and many of these features can be used to clean it up and make it much more maintainable. I would personally like us to at least bump up to CMake 3.12. I also do think it's worth establishing a policy and process around upgrading CMake versions, since newer versions keep on adding useful features (particularly better generator expression support), and we want to be able to keep taking advantage of them.
[1] http://lists.llvm.org/pipermail/llvm-dev/2019-November/136485.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Louis Dionne via llvm-dev
> On Mar 26, 2020, at 16:07, Shoaib Meenai <sme...@fb.com> wrote:
>
> We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which point people suggested upgrading the CMake version used by all of LLVM), so let’s try to move this forward.
I was going to create a new thread to ask LLVM as a whole, but you did it faster and better than I could have! Thanks a lot for all the research and context you added below. This is great.
>
> [...]
>
> Our build system is incredibly complex, and many of these features can be used to clean it up and make it much more maintainable. I would personally like us to at least bump up to CMake 3.12. I also do think it's worth establishing a policy and process around upgrading CMake versions, since newer versions keep on adding useful features (particularly better generator expression support), and we want to be able to keep taking advantage of them.
I'd like to express very strong support for this. I believe 3.12 is reasonable, and it will give us a lot of features that can improve our life significantly, while still being old enough that some distributions will support it out of the box.
As far as establishing a policy goes, my preference would be to say that we systematically bump the requirement every release to e.g. the CMake released 12 months ago. I understand some people would rather have a detailed analysis of why we should upgrade every time, but I think it's unnecessary overhead because:
1. CMake keeps adding new features that can simplify the build system, so there's always "a reason" to upgrade
2. CMake is very easy to upgrade, so it makes sense to be more aggressive than for e.g. bumping compiler requirements
Bumping systematically would have the benefit of lowering the effort to making these upgrades and avoiding situations where upgrade efforts are stalled for several years due to the effort of having to convince people over again. If we bumped systematically, it would also ensure that users and bot owners are trained to upgrade from time to time.
However, no matter what the policy ends up being, I think it's important to at least bump it once soon, so I would be careful not to derail this effort in search of a perfect policy.
Cheers,
Louis
Siva Chandra via llvm-dev
> On Mar 26, 2020, at 16:07, Shoaib Meenai <sme...@fb.com> wrote:
>
> We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which point people suggested upgrading the CMake version used by all of LLVM), so let’s try to move this forward.
I was going to create a new thread to ask LLVM as a whole, but you did it faster and better than I could have! Thanks a lot for all the research and context you added below. This is great.
>
> [...]
>
> Our build system is incredibly complex, and many of these features can be used to clean it up and make it much more maintainable. I would personally like us to at least bump up to CMake 3.12. I also do think it's worth establishing a policy and process around upgrading CMake versions, since newer versions keep on adding useful features (particularly better generator expression support), and we want to be able to keep taking advantage of them.
I'd like to express very strong support for this. I believe 3.12 is reasonable, and it will give us a lot of features that can improve our life significantly, while still being old enough that some distributions will support it out of the box.
Nikita Popov via llvm-dev
Roman Lebedev via llvm-dev
+1
I think bumping it up to 3.10 may fine but i'm strongly against:
a) unconditionally bumping it just because there's a newer version
available (including delayed updates)
b) considering "pull an executable from internet and run it" as
the proper way to update cmake
c) not considering the versions available in debian stable/testing
and latest ubuntu lts as soft blockers
d) trying to update cmake from within cmakefiles (or automatically
fetching stuff from internet during build in general, for that matter)
> Regards,
> Nikita
Roman
Petr Hosek via llvm-dev
Shoaib Meenai via llvm-dev
Ubuntu 20.04 LTS will be released soon, and I believe it’ll have CMake 3.16.3, so that increases the LTS lower bound significantly.
I strongly disagree with the sentiment that the build system already works so there’s no urgent need to improve it. I believe we should treat the build system like code, and the same ideas around refactoring apply. Our build system is a huge thorny mess; there’s tons of supported configurations, lots of dependencies which rely on targets being processed in a certain order, and so on. Some of that can be cleaned up without requiring a CMake version bump, but generator expressions in particular are a very powerful mechanism which enable targets to depend on each other without requiring a particular order for processing them (which is very fragile and easy to break). In turn, build system cleanups reduce bugs (and we get plenty of those), make it much easier to add features with confidence, and make the build system much more understandable. I think a policy of “we only upgrade CMake versions when it’s absolutely necessary to do so” would be pretty harmful for the health of the build system.
Shoaib Meenai via llvm-dev
Alex Brachet-Mialot via llvm-dev
drop in the bucket compared to what it takes to build LLVM. If someone
is trying to build LLVM from source I can't imagine building CMake
would be a huge deal. Although I can't find it anymore I believe one
of the clang docs recommended building ninja from source, so if I'm
not just making that up there is precedence for us requiring (or at
least suggesting) building part of the build system from source.
Alex
On Thu, Mar 26, 2020 at 5:48 PM Shoaib Meenai via llvm-dev
Petr Hosek via llvm-dev
Ubuntu 20.04 LTS will be released soon, and I believe it’ll have CMake 3.16.3, so that increases the LTS lower bound significantly.
I strongly disagree with the sentiment that the build system already works so there’s no urgent need to improve it. I believe we should treat the build system like code, and the same ideas around refactoring apply. Our build system is a huge thorny mess; there’s tons of supported configurations, lots of dependencies which rely on targets being processed in a certain order, and so on. Some of that can be cleaned up without requiring a CMake version bump, but generator expressions in particular are a very powerful mechanism which enable targets to depend on each other without requiring a particular order for processing them (which is very fragile and easy to break). In turn, build system cleanups reduce bugs (and we get plenty of those), make it much easier to add features with confidence, and make the build system much more understandable. I think a policy of “we only upgrade CMake versions when it’s absolutely necessary to do so” would be pretty harmful for the health of the build system.
_______________________________________________
Petr Hosek via llvm-dev
Zachary Turner via llvm-dev
Shoaib Meenai via llvm-dev
Good point! I didn’t mention it because I thought LLVM in general preferred modules to precompiled headers, but it’s definitely a notable addition.
From:
Zachary Turner <ztu...@roblox.com>
Date: Thursday, March 26, 2020 at 6:10 PM
To: Shoaib Meenai <sme...@fb.com>
Cc: "llvm...@lists.llvm.org" <llvm...@lists.llvm.org>
Subject: Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
An important addition to CMake 3.16 that you didn't mention is the addition of the target_precompile_headers() command. This can greatly speedup builds for users without internal build distribution infrastructure.
Siva Chandra via llvm-dev
CMake 3.9 (released July 18th 2017):
* TARGET_OBJECTS generator expression support in add_custom_command and file(GENERATE)
CMake 3.11 (released March 28th 2018):
* add_library() and add_executable() can be called without sources as long as target_sources() is used later
CMake 3.12 (released July 17th 2018):
* target_link_libraries() supports object libraries and propagates usage requirements
CMake 3.13 (released November 20th 2018):
* target_link_directories() and target_link_options() commands to set link options instead of awkwardly having to use target_link_libraries() for this purpose
Siva Chandra via llvm-dev
On Thu, Mar 26, 2020 at 2:39 PM Shoaib Meenai via llvm-dev <llvm...@lists.llvm.org> wrote:Ubuntu 20.04 LTS will be released soon, and I believe it’ll have CMake 3.16.3, so that increases the LTS lower bound significantly.
I strongly disagree with the sentiment that the build system already works so there’s no urgent need to improve it. I believe we should treat the build system like code, and the same ideas around refactoring apply. Our build system is a huge thorny mess; there’s tons of supported configurations, lots of dependencies which rely on targets being processed in a certain order, and so on. Some of that can be cleaned up without requiring a CMake version bump, but generator expressions in particular are a very powerful mechanism which enable targets to depend on each other without requiring a particular order for processing them (which is very fragile and easy to break). In turn, build system cleanups reduce bugs (and we get plenty of those), make it much easier to add features with confidence, and make the build system much more understandable. I think a policy of “we only upgrade CMake versions when it’s absolutely necessary to do so” would be pretty harmful for the health of the build system.
Huge +1 from me! This is not about cosmetics, this is about improving the health of the project. There are known bugs in our build that we cannot solve without the use of generator expressions (for example https://reviews.llvm.org/D68833).Personally I'd really like LLVM to move to 3.15 which greatly expanded the generator expression support and would give us the biggest benefit.
Louis Dionne via llvm-dev
On Mar 26, 2020, at 16:07, Shoaib Meenai <sme...@fb.com> wrote:
Chris Tetreault via llvm-dev
Assuming this is a one-time version bump, this seems reasonable to me. Perhaps this goes without saying, but the warning for point 1 should only happen if you don’t have CMake >= 3.13.4 installed.
It sounded to me from your original message that you have an urgent need to upgrade to 3.8. Were you planning on going ahead with that right away?
From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of
Louis Dionne via llvm-dev
Sent: Thursday, April 2, 2020 7:20 AM
To: Shoaib Meenai <sme...@fb.com>
Cc: llvm...@lists.llvm.org
Louis Dionne via llvm-dev
On Apr 2, 2020, at 11:43, Chris Tetreault <ctet...@quicinc.com> wrote:Assuming this is a one-time version bump, this seems reasonable to me. Perhaps this goes without saying, but the warning for point 1 should only happen if you don’t have CMake >= 3.13.4 installed.
It sounded to me from your original message that you have an urgent need to upgrade to 3.8. Were you planning on going ahead with that right away?
Chris Tetreault via llvm-dev
My issue has always been the version bump “just because”. Bumping the CMake version right after an LLVM release seems to me to be a good time to upgrade. I just feel that we should only upgrade as far as we need to in order to use specific CMake features, never because “well, this is our only chance.”
It sounds to me like you have a good reason to bump to 3.8 and since we just branched LLVM 10, I think now would be a good time to do that. 3.8 is still really old, so most people probably already have it. I know I personally rolled my own version of source_group(TREE …) in polly, and if had CMake 3.8.2 I could get rid of it so I do feel the pain.
Perhaps we could go with your plan to upgrade to 3.13.4 for LLVM 12 and over a shorter span of time upgrade to 3.8 for LLVM 11? Since you’d be doing the work either way, I’ll leave it to you to decide if you want to go that route.
Shoaib Meenai via llvm-dev
I’m in favor of all this. Thanks for volunteering! I’m happy to help out in whatever way.
Some things it might be worth figuring out for future upgrades:
* If we want to limit ourselves to CMake versions supported by LTS releases of distros, which distros should we consider, and how far back should we go (i.e. is it just the latest LTS or the last two LTS versions)?
* For platforms like Ubuntu where CMake publishes its own packages (that you can install via the platform’s package manager), do those count, or do we only consider the CMake that comes in the OS packages?
* Do we have any limitations around how often/when we upgrade? You’re tying the upgrade to after the branch, which is pretty standard, but e.g. if we wanted to upgrade to 3.8.0 now and then upgrade to 3.13.4 after the branch, would people be okay with that, or should we limit upgrades to just shortly after a branch?
From: <ldi...@apple.com> on behalf of Louis Dionne <ldi...@apple.com>
Date: Thursday, April 2, 2020 at 7:20 AM
To: Shoaib Meenai <sme...@fb.com>
Mehdi AMINI via llvm-dev
I’m in favor of all this. Thanks for volunteering! I’m happy to help out in whatever way.
Some things it might be worth figuring out for future upgrades:
* If we want to limit ourselves to CMake versions supported by LTS releases of distros, which distros should we consider, and how far back should we go (i.e. is it just the latest LTS or the last two LTS versions)?
_______________________________________________
Neil Nelson via llvm-dev
'Supported' means that it comes from the packages available from the distribution that can be seen via this page.
These packages have been processed by the Ubuntu community to obtain a reliability expectation that would not apply, for example, to a PPA.
The difference between installing or building Clang and LLVM from original sources as against installing versions available from the distribution when compared to doing the same with cmake, is that the user accepts the inherent risks from Clang and LLVM, but Clang and LLVM can not accept the risks from the cmake group and then expect the user to merely assume that there are no additional risks from installing cmake.
The distributions are not merely just collections of software, they are collections of software that have some guarantee of working well together and without bugs and other issues because they have been used and tested by that use in the distribution community.
The importance of this distinction between the quality of software expected in a distribution as against installing directly from source is apparently lost on those who did not live through the pre-distribution days. During that time we had to gather up the dependencies ourselves, trying to get the correct versions, hoping that the software compiled and worked with the other dependencies, and hope we did not install malware and hackware. And quite often it was a futile attempt to gather together software dependencies of any size.
Those who lived through that time remember it as the dark-ages of long ago, never to be seen again.
Neil Nelson
Mehdi AMINI via llvm-dev
'Supported' means that it comes from the packages available from the distribution that can be seen via this page.
These packages have been processed by the Ubuntu community to obtain a reliability expectation that would not apply, for example, to a PPA.
The difference between installing or building Clang and LLVM from original sources as against installing versions available from the distribution
when compared to doing the same with cmake, is that the user accepts the inherent risks from Clang and LLVM, but Clang and LLVM can not accept the risks from the cmake group and then expect the user to merely assume that there are no additional risks from installing cmake.
The distributions are not merely just collections of software, they are collections of software that have some guarantee of working well together and without bugs and other issues because they have been used and tested by that use in the distribution community.
The importance of this distinction between the quality of software expected in a distribution as against installing directly from source is apparently lost on those who did not live through the pre-distribution days. During that time we had to gather up the dependencies ourselves, trying to get the correct versions, hoping that the software compiled and worked with the other dependencies, and hope we did not install malware and hackware. And quite often it was a futile attempt to gather together software dependencies of any size.
Those who lived through that time remember it as the dark-ages of long ago, never to be seen again.
Neil Nelson via llvm-dev
I have seen here on the list that some are compiling on distribution versions older than 18.04. In using, for example, the Ubuntu distribution it is assumed that those interested in reliability and the more recent and better features will upgrade to the latest LTS version at the earliest convenience. For Xenial/16.04, the upgrade to 18.04 should have been long ago.
I see you are taking precautions to restrict the
cmake install for only clang and llvm and it looks reasonable.
If this method is what is intended for clang and llvm, it would
almost seem useful to make it part of the automated download
procedure. It would become the standard with the rationale given
as against other less restricted suggestions. Just saying get
some particular cmake version does not obtain the suggested
restricted requirement.
I am also using VMs (kvm) that increase the ease of using recent
distribution releases and isolates whatever clang and llvm
decides to do.
https://help.ubuntu.com/community/KVM/Installation
VMs have a number of advantages. A new ISO can be downloaded, a VM from the ISO running quickly, and then all the additional, interesting distribution software quickly installed on the VM without disturbing anything else. If for some reason that VM begins to have trouble, just delete it and try again. Keeping additional VMs in different stages of readiness helps the process along. Run the host on an LTS version if stability is desired or for other purposes, and the VMs having later versions with the wild software isolated.
Looks like a beta-release of Xubuntu 20.04 is here.
https://xubuntu.org/news/xubuntu-20-04-testing-week/
I will see if it will fly.
Neil Nelson
Chris Tetreault via llvm-dev
Every additional dependency that we force the user to manually install (either by building from source, or adding some new PPA to their ubuntu system), raises the barrier to entry that much higher. Just because we may require the user to manually install some newer compiler on their system doesn’t mean that we should also require them to install some newer CMake than what’s on their system. (unless it is actually necessary, but we’ve beaten that dead horse long enough)
I agree with Neil’s interpretation that the definition of “supported” being used here is default system packages and not third party repos that claim to work for that system.
Shoaib Meenai via llvm-dev
What if CMake themselves are providing the APT packages (https://apt.kitware.com/)? I’m assuming it still counts as third-party, but it should carry some more weight if the creators of the software (who after all know best how it works and what dependencies it needs) are packaging it.
David Blaikie via llvm-dev
What if CMake themselves are providing the APT packages (https://apt.kitware.com/)? I’m assuming it still counts as third-party,
I'd think so, yes.
but it should carry some more weight if the creators of the software (who after all know best how it works and what dependencies it needs) are packaging it.
The inverse argument seems similarly applicable, though - that the OS distributors know best what works with their OS/other packages.
Chris Tetreault via llvm-dev
Kitware has a vested interest in ensuring that their product works correctly for the majority of its users. Canonical has a vested interest in ensuring that their supported distros work correctly for their users. The sets of systems that these to separate organizations choose to actually support well may not entirely overlap, and that’s a problem for those people who fall outside the overlapping region of that Venn diagram.
One can reasonably assume that if they are using a distro that is within it’s supported lifetime, then CMake from the repos works correctly. It’s not safe to assume that if they are using a distro that is within it’s supported lifetime, then CMake from Kitware’s PPA works correctly in that distro; Ktiware may have stopped testing “old” distros.
Personally, I’d rather build from source myself than vet a PPA. Especially for something as easy to build as CMake.
Mehdi AMINI via llvm-dev
Every additional dependency that we force the user to manually install (either by building from source, or adding some new PPA to their ubuntu system), raises the barrier to entry that much higher.
Just because we may require the user to manually install some newer compiler on their system doesn’t mean that we should also require them to install some newer CMake than what’s on their system.
Chris Tetreault via llvm-dev
> You're saying "doesn’t mean that we should" while I've been saying in this situation that "we can", there is quite a difference here I believe.
Technically “we can” do anything we want. We can always require that the project be built with the current release candidate of CMake. That doesn’t mean that we should.
From: Mehdi AMINI <joke...@gmail.com>
Sent: Tuesday, April 7, 2020 12:01 AM
To: Chris Tetreault <ctet...@quicinc.com>
Mehdi AMINI via llvm-dev
> You're saying "doesn’t mean that we should" while I've been saying in this situation that "we can", there is quite a difference here I believe.
Technically “we can” do anything we want. We can always require that the project be built with the current release candidate of CMake. That doesn’t mean that we should.
David Blaikie via llvm-dev
Chris Tetreault via llvm-dev
Agreed. My entire argument this whole time has been that there may be organization barriers to installing external CMake. Lawyers don’t care that it’s technically easy to do a thing.
Given that we don’t know everybody’s environment, we have to make reasonable choices as to what we support. Most organizations that I have experience with that use Linux use some distro as a base environment. The default packages of a distro represent the base system, and if an org uses some distro as it’s environment, then it likely has approved all packages in the repos for use. In such an environment, using a third party repo or building from source likely would come under increased scrutiny. Since our hypothetical user is expect to build LLVM, then they must have CMake installed, whose version is almost certainly greater than or equal to the version in the repo.
Basically, in the presence of locked down environments, the default CMake of popular LTS distros is much more likely to be available for use than CMake from some arbitrary external source.
Mehdi AMINI via llvm-dev
I think it does make a difference how many things we ask new developers to do to get up and running - because we've asked them to do one thing doesn't mean it's low-cost to ask them to do another thing.
Louis Dionne via llvm-dev
On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <llvm...@lists.llvm.org> wrote:On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dbla...@gmail.com> wrote:I think it does make a difference how many things we ask new developers to do to get up and running - because we've asked them to do one thing doesn't mean it's low-cost to ask them to do another thing.In this case I see it rather that if we ask them to do one quite big thing already, we should be OK with what seems like a trivial one.
Mehdi AMINI via llvm-dev
On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <llvm...@lists.llvm.org> wrote:On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dbla...@gmail.com> wrote:I think it does make a difference how many things we ask new developers to do to get up and running - because we've asked them to do one thing doesn't mean it's low-cost to ask them to do another thing.In this case I see it rather that if we ask them to do one quite big thing already, we should be OK with what seems like a trivial one.I strongly agree. I think Mehdi's point can be summarized as (Mehdi, feel free to correct me):It's incredibly trivial to install CMake, so if a user is *already* required to install a non-default toolchain (which is not so trivial), requiring them to install a non-default CMake is not increasing the barrier by much.
Chris Tetreault via llvm-dev
A line has to be drawn in the sand somewhere. How many “easy” things are we going to require the user to do? Today it’s build a specific CMake from source. What’s next?
Not having to manually track down a bunch of dependencies before building is a feature. Not having to have an internet connection at build time (if we were to script the getting of the custom CMake) is a feature. Being able to just call cmake instead of using some build_llvm.sh that (probably poorly) wraps cmake and downloads the correct version is a feature. Being able to use CMake that is distributed with visual studio so that invoking cmake from the developer powershell just works without fiddling with PATHs is a feature. Not having to install msys so that I can invoke download_cmake.sh is a feature. Not having to have the correct version of python (is it 2 or 3?) be on the path in order to invoke download_cmake.py is a feature. Not having to remember to do --recurse-submodules on the llvm repo if we include it as a git submodule is a feature. The list goes on. Yeah, these are all little things, but a bunch of little things adds up to a huge barrier.
People use Linux distos because by and large they just have all the dependencies that they need. I know I personally hate installing some open source thing on my machines when they have some dependency that’s not in the repos. Sure, it may be easy to build CMake from source. But now I have two CMakes: one that is automatically updated when I do sudo apt-get upgrade, and one that is just randomly in some folder that’s probably not on the PATH. I personally would really appreciate it if we made an attempt to reduce this sort of friction.
Thanks,
Christopher Tetreault
From: llvm-dev <llvm-dev...@lists.llvm.org>
On Behalf Of Mehdi AMINI via llvm-dev
Sent: Wednesday, April 8, 2020 9:06 AM
To: Louis Dionne <ldi...@apple.com>
Cc: llvm...@lists.llvm.org
Subject: [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
Louis Dionne via llvm-dev
On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm...@lists.llvm.org> wrote:Okay, so we've had some discussion on this thread, and although some people (including me) would like a more aggressive policy, I believe the following will not get any objection (based on the thread). On April 23rd 2020, Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will make the lower bound for LTS distributions be 3.13.4, and so I suggest we upgrade to that. Here's a proposed process:1. Immediately add a CMake warning in <root>/llvm/CMakeLists.txt saying that CMake 3.13.4 will be the new minimum version starting with LLVM 12.0.0, and mentioning the versions used in various LTSes.2. Immediately send a courtesy heads-up email to all build-bot owners telling them about the upcoming change.3. Right after we branch off the release branch for LLVM 11.0.0 (the next one), make the minimum CMake version required be 3.13.4.4. Iterate on (3) until all bots are migrated.5. Send a message to the list saying the bump is complete. At that time, projects are free to start using features from 3.13.4.Unless someone else absolutely wants to bite the bullet, I volunteer to do the above steps.
Eric Christopher via llvm-dev
_______________________________________________
Chris Tetreault via llvm-dev
Visual studio 2019 ships with CMake 3.15.5, which is pretty darn new IMO. From what I can tell, CMake versions are tied to visual studio releases. So assuming we go with “what do recent LTS distros have” as our metric, I think it’s reasonable to say “what do recent visual studio versions have”. It probably makes sense to confirm with MS though before we assume that this is the case.
From: Eric Christopher <echr...@gmail.com>
Sent: Wednesday, April 8, 2020 12:41 PM
To: Chris Tetreault <ctet...@quicinc.com>
Shoaib Meenai via llvm-dev
Yeah, I don’t anticipate Windows posing problems. Also, it’s pretty common in Windows to just install software yourself, and CMake ships prebuilt binaries and an installer, so it’s pretty easy to get set up with it.
Chris, I’m gonna reiterate a question of mine from an earlier email, since you may have thoughts on it:
* If we want to limit ourselves to CMake versions supported by LTS releases of distros, which distros should we consider, and how far back should we go (i.e. is it just the latest LTS or the last two LTS versions)?
Tobias Hieta via llvm-dev
Eric Christopher via llvm-dev
Shoaib Meenai via llvm-dev
Louis’ current proposal is to upgrade to CMake 3.13.2 after the LLVM 11 branch cut (such that the LLVM 12 release would be the first with the upgraded CMake requirement), and Visual Studio already comes with CMake 3.15.5, so we’re good on that front.
Eric Christopher via llvm-dev
Chris Tetreault via llvm-dev
We should decide who we consider the major distros to be. In my mind this is Ubuntu, Debian, Fedora, and CentOS/RHEL. We should also consider Visual Studio releases and whatever OSX and the major BSD’s have. (I honestly have no idea so I’ll refrain from speculating)
For all of these, we should try very hard to support the most recent LTS. For the previous LTS, it would be nice if we could support it, but we shouldn’t require it. Old LTSs tend to have really out of date packages, especially in times like now with Ubuntu where we’re really close to the current LTS becoming the old LTS.
That said, if CMake version X has a killer feature that we need, we should consider upgrading even if it doesn’t fit this criteria. Similarly, we should not just upgrade because the minimum bound of CMake versions supported by this set of OSs increased. The point is to upgrade only when there’s a compelling reason, and this set of OSs is just a heuristic of “most people probably already have this CMake version.”
James Y Knight via llvm-dev
Eric Christopher via llvm-dev
Chris Tetreault via llvm-dev
Whatever we decide, we should probably document it somewhere. Otherwise this conversation will be inevitable next time we want to bump the version.
If we had a documented policy on when and how to upgrade, then most of this argument could have been avoided.
Reid Kleckner via llvm-dev
Shoaib Meenai via llvm-dev
I agree that’s valuable, but then it’s also important to pin down exactly what a “modern OS” is, and which ones we should keep in mind when we’re considering e.g. which CMake versions are feasible. (The same applies even more so to toolchain requirements, of course.)
Alexandre Ganea via llvm-dev
Sorry if this was discussed,
Why not have a setup.sh/setup.bat/setup.exe which could download/install/setup everything we want, at the version we want, on a vanilla system? Handle the cases described by Chris below? Why leave the burden to the end-user?
Currently, it’s not exactly trivial to setup everything for building & running LLVM on Windows on a cloud VM if you want `ninja check-all` to pass on -DLLVM_ENABLE_PROJECTS=llvm;mlir;clang;lld;clang-tools-extra;compiler-rt;lldb. There are many manuals steps, and often things that you forget (GnuWin32 FTW). On Ubuntu it is a bit easier, but still lots of trial and error.
We use NuGet packages in our build system and for our developers, to ensure they always have the right setup. Our games always build and use the toolings from the .nugets, not the default installations on the machine. This guarantees universal determinism everywhere and makes the developer setup a one-click-exe. Setting up a similar thing for LLVM for different OSes could be a bit more tricky, but nothing insurmountable?
De : llvm-dev <llvm-dev...@lists.llvm.org> De la part de Shoaib Meenai via llvm-dev
Envoyé : April 9, 2020 4:26 PM
À : Reid Kleckner <r...@google.com>; James Y Knight <jykn...@google.com>
Cc : llvm...@lists.llvm.org
Objet : Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
Chris Tetreault via llvm-dev
Currently, it’s not hard to just invoke CMake correctly. I’m reluctant to have a wrapper script because it encourages people to change this status quo. “I can add this complicated pre-step, I’ll just update setup.sh” Then they do so, but forget to update setup.bat, or update it incorrectly and the whole thing gets out of sync. Additionally, there are issues with corner cases. What does setup.sh do on Cygwin? MSYS? git-bash? Powershell? cmd.exe? Does setup.bat do the same thing on all of these environments? How about on Windows 8? How about on Windows on ARM? Does setup.sh even work on Linux on shells other than bash? Finally, there’s the issue of customization. How much does setup.bat let me customize? Does it just generate a Ninja project for me? What if I want a Visual Studio solution?
The current system makes all of this the user’s problem. This is feasible because it’s not really that hard to build LLVM.
Shoaib Meenai via llvm-dev
CCing Tom. CentOS 8 (and presumably RHEL 8) provide CMake 3.11.4 in their system packages. CentOS 7 actually provides CMake 3.14.7 via EPEL, so we have an interesting situation where an older distro version provides a newer CMake. However, it looks like Tom has a solution in mind in https://bugzilla.redhat.com/show_bug.cgi?id=1753477 (and given the current discussion of raising LLVM’s CMake requirement to 3.13.4, we’ll need that solution soon), so it seems we should be good there.
Tom Stellard via llvm-dev
> CCing Tom. CentOS 8 (and presumably RHEL 8) provide CMake 3.11.4 in their system packages. CentOS 7 actually provides CMake 3.14.7 via EPEL, so we have an interesting situation where an older distro version provides a newer CMake. However, it looks like Tom has a solution in mind in https://bugzilla.redhat.com/show_bug.cgi?id=1753477 (and given the current discussion of raising LLVM’s CMake requirement to 3.13.4, we’ll need that solution soon), so it seems we should be good there.
>
We have the ability to add newer versions of CMake to RHEL8 if necessary.
The CMake version required by LLVM is one of the things we consider
when deciding if and when to provide a newer CMake.
-Tom
>
>
> *From: *Chris Tetreault <ctet...@quicinc.com>
> *Date: *Wednesday, April 8, 2020 at 1:35 PM
> *To: *Shoaib Meenai <sme...@fb.com>, Eric Christopher <echr...@gmail.com>
> *Cc: *"llvm...@lists.llvm.org" <llvm...@lists.llvm.org>
> *Subject: *RE: [llvm-dev] Upgrading LLVM's minimum required CMake version
>
>
>
> We should decide who we consider the major distros to be. In my mind this is Ubuntu, Debian, Fedora, and CentOS/RHEL. We should also consider Visual Studio releases and whatever OSX and the major BSD’s have. (I honestly have no idea so I’ll refrain from speculating)
>
>
>
> For all of these, we should try very hard to support the most recent LTS. For the previous LTS, it would be nice if we could support it, but we shouldn’t require it. Old LTSs tend to have really out of date packages, especially in times like now with Ubuntu where we’re really close to the current LTS becoming the old LTS.
>
>
>
> That said, if CMake version X has a killer feature that we need, we should consider upgrading even if it doesn’t fit this criteria. Similarly, we should not just upgrade because the minimum bound of CMake versions supported by this set of OSs increased. The point is to upgrade only when there’s a compelling reason, and this set of OSs is just a heuristic of “most people probably already have this CMake version.”
>
>
>
> *From:* Shoaib Meenai <sme...@fb.com>
> *Sent:* Wednesday, April 8, 2020 12:58 PM
> *To:* Chris Tetreault <ctet...@quicinc.com>; Eric Christopher <echr...@gmail.com>
> *Cc:* llvm...@lists.llvm.org
> *Subject:* [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
>
>
>
> Yeah, I don’t anticipate Windows posing problems. Also, it’s pretty common in Windows to just install software yourself, and CMake ships prebuilt binaries and an installer, so it’s pretty easy to get set up with it.
>
>
>
> Chris, I’m gonna reiterate a question of mine from an earlier email, since you may have thoughts on it:
>
>
>
> * If we want to limit ourselves to CMake versions supported by LTS releases of distros, which distros should we consider, and how far back should we go (i.e. is it just the latest LTS or the last two LTS versions)?
>
>
>
> *From: *llvm-dev <llvm-dev...@lists.llvm.org <mailto:llvm-dev...@lists.llvm.org>> on behalf of Chris Tetreault via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>
> *Reply-To: *Chris Tetreault <ctet...@quicinc.com <mailto:ctet...@quicinc.com>>
> *Date: *Wednesday, April 8, 2020 at 12:51 PM
> *To: *Eric Christopher <echr...@gmail.com <mailto:echr...@gmail.com>>
> *Cc: *"llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>" <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>>
> *Subject: *Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
>
>
>
> Visual studio 2019 ships with CMake 3.15.5, which is pretty darn new IMO. From what I can tell, CMake versions are tied to visual studio releases. So assuming we go with “what do recent LTS distros have” as our metric, I think it’s reasonable to say “what do recent visual studio versions have”. It probably makes sense to confirm with MS though before we assume that this is the case.
>
>
>
> *From:* Eric Christopher <echr...@gmail.com <mailto:echr...@gmail.com>>
> *Sent:* Wednesday, April 8, 2020 12:41 PM
> *To:* Chris Tetreault <ctet...@quicinc.com <mailto:ctet...@quicinc.com>>
> *Cc:* Mehdi AMINI <joke...@gmail.com <mailto:joke...@gmail.com>>; Louis Dionne <ldi...@apple.com <mailto:ldi...@apple.com>>; llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> *Subject:* [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
>
>
>
> Hi All,
>
>
>
> Throwing a couple of comments in:
>
>
>
> Chris's position here has a lot of good points and we want to make sure we're not raising the barrier too high. I definitely want to be able to push ahead with our versions of tools; being able to update quickly is one of the hallmarks of the llvm project. That said, binary packages that can be updated are a minimal first step IMO. I'd really like to not build anything from source :) It seems like there are binaries available for cmake for all of our current platforms, but the windows use case that he brings is definitely a significant one. Can we perhaps reach out and find out the likelihood of a reasonably soonish update there? Linux distros are probably less of a problem - while we all can't use ppas we should be able to do something, similarly with osx.
>
>
>
> Thoughts?
>
>
>
> -eric
>
>
>
>
> On Wed, Apr 8, 2020 at 9:53 AM Chris Tetreault via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
>
>
>
> A line has to be drawn in the sand somewhere. How many “easy” things are we going to require the user to do? Today it’s build a specific CMake from source. What’s next?
>
>
>
> Not having to manually track down a bunch of dependencies before building is a feature. Not having to have an internet connection at build time (if we were to script the getting of the custom CMake) is a feature. Being able to just call cmake instead of using some build_llvm.sh that (probably poorly) wraps cmake and downloads the correct version is a feature. Being able to use CMake that is distributed with visual studio so that invoking cmake from the developer powershell just works without fiddling with PATHs is a feature. Not having to install msys so that I can invoke download_cmake.sh is a feature. Not having to have the correct version of python (is it 2 or 3?) be on the path in order to invoke download_cmake.py is a feature. Not having to remember to do --recurse-submodules on the llvm repo if we include it as a git submodule is a feature. The list goes on. Yeah, these are all little things, but a bunch of little things adds up to a huge barrier.
>
>
>
> People use Linux distos because by and large they just have all the dependencies that they need. I know I personally hate installing some open source thing on my machines when they have some dependency that’s not in the repos. Sure, it may be easy to build CMake from source. But now I have two CMakes: one that is automatically updated when I do sudo apt-get upgrade, and one that is just randomly in some folder that’s probably not on the PATH. I personally would really appreciate it if we made an attempt to reduce this sort of friction.
>
>
>
> Thanks,
>
> Christopher Tetreault
>
>
>
>
>
> *From:* llvm-dev <llvm-dev...@lists.llvm.org <mailto:llvm-dev...@lists.llvm.org>> *On Behalf Of *Mehdi AMINI via llvm-dev
> *Sent:* Wednesday, April 8, 2020 9:06 AM
> *To:* Louis Dionne <ldi...@apple.com <mailto:ldi...@apple.com>>
> *Cc:* llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> *Subject:* [EXT] Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
>
>
>
>
>
>
>
> On Wed, Apr 8, 2020 at 9:02 AM Louis Dionne <ldi...@apple.com <mailto:ldi...@apple.com>> wrote:
>
>
>
>
>
> On Apr 7, 2020, at 22:16, Mehdi AMINI via llvm-dev <llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>> wrote:
>
>
>
>
>
>
>
> On Tue, Apr 7, 2020 at 11:27 AM David Blaikie <dbla...@gmail.com <mailto:dbla...@gmail.com>> wrote:
>
> I think it does make a difference how many things we ask new developers to do to get up and running - because we've asked them to do one thing doesn't mean it's low-cost to ask them to do another thing.
>
>
>
> In this case I see it rather that if we ask them to do one quite big thing already, we should be OK with what seems like a trivial one.
>
>
>
> I strongly agree. I think Mehdi's point can be summarized as (Mehdi, feel free to correct me):
>
>
>
> It's incredibly trivial to install CMake, so if a user is *already* required to install a non-default toolchain (which is not so trivial), requiring them to install a non-default CMake is not increasing the barrier by much.
>
>
>
> Thanks, this is my point indeed!
>
>
>
> I think it is even slightly stronger than what you wrote since you don't even need to *install* CMake as it can be built and used directly from the build directory: it is entirely non-intrusive on the system.
>
>
>
> --
>
> Mehdi
>
> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org <mailto:llvm...@lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=OUvi60kOTuMyRUJcCtHsN-RK1gHy4sXxEGS0pAunCoE&s=W77RObkJ6AlX4-NZ-OApzF80Y5rSjh4gDzuBG4ScjEQ&e=>
Philip Reames via llvm-dev
+1 to Reid and Chris.
Philip Reames via llvm-dev
I would be opposed to this proposal. I've worked with build
systems that went this route before. What happens is the script
grows ever more complicated, the person who wrote the script
eventually leaves, and no one knows how to build it outside of a
particular frozen set of environments. I've literally seen code
bases die (i.e. no one wants to work on them, eventual rewrite
target) due to issues this can be traced solely back to this
decision.
The fact we use standard build tools is a feature not a bug. Let's not "fix" our way into a much worse set of problems.
Philip
p.s. To be clear, I'm not stating an opinion on the original
question of whether building cmake from source was a reasonable
expectation.
Eric Christopher via llvm-dev
Philip Reames via llvm-dev
Eric,
I think you're commingling two points: "setup scripts" and "must
support default toolchain". I think it's important to keep them
separate as, IMO, we should strongly resist the temptation to do
the former, while the second is optional.
Speaking personally, I'd be open to only supporting default configuration builds on a small subset of platforms. For instance, maybe *only* Ubuntu last LTS, Windows 10 latest, and MacOS latest. Having to build a newer cmake doesn't seem like a huge hassle.
We do want the setup to be straight forward for a broad class of recent-ish distros, but there's a difference between "instructions are simple and straight forward" and "works out of the box".
Philip
Eric Christopher via llvm-dev
Eric,
I think you're commingling two points: "setup scripts" and "must support default toolchain". I think it's important to keep them separate as, IMO, we should strongly resist the temptation to do the former, while the second is optional.
Speaking personally, I'd be open to only supporting default configuration builds on a small subset of platforms. For instance, maybe *only* Ubuntu last LTS, Windows 10 latest, and MacOS latest. Having to build a newer cmake doesn't seem like a huge hassle.
We do want the setup to be straight forward for a broad class of recent-ish distros, but there's a difference between "instructions are simple and straight forward" and "works out of the box".
Chris Tetreault via llvm-dev
Just to clarify, I’m not actually suggesting that we document any minimum sort of environment (other than specific compiler and cmake versions as we currently do). Such a specification would probably be overly restrictive to us in having to maintain it, and to users who might otherwise be able to build LLVM. I’m only suggesting that we consider what’s in popular distros/environments when deciding if it’s worth it to upgrade. The only things I’m actually asking for are:
- Let’s only upgrade the CMake minimum version requirement if there is an actual compelling reason to
- Recognize that the ability to build on diverse environments is a feature, and make a good-faith attempt to support it if reasonable
- Please gosh no “setup.sh”
I support bumping the minimum CMake version. I don’t support a policy of unconditionally bumping the minimum CMake version periodically.
Thanks,
Christopher Tetreault
From: Eric Christopher <echr...@gmail.com>
Sent: Thursday, April 9, 2020 4:18 PM
Eric Christopher via llvm-dev
Chris Tetreault via llvm-dev
Well, I think I heard downthread that the version of CMake in the next Visual Studio release is really new, so maybe not that. The 3.13.4 that Louis Dionne is moving forward with is certainly seems reasonable to me.
Louis Dionne via llvm-dev
On Apr 8, 2020, at 13:06, Louis Dionne <ldi...@apple.com> wrote:On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm...@lists.llvm.org> wrote:Okay, so we've had some discussion on this thread, and although some people (including me) would like a more aggressive policy, I believe the following will not get any objection (based on the thread). On April 23rd 2020, Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will make the lower bound for LTS distributions be 3.13.4, and so I suggest we upgrade to that. Here's a proposed process:1. Immediately add a CMake warning in <root>/llvm/CMakeLists.txt saying that CMake 3.13.4 will be the new minimum version starting with LLVM 12.0.0, and mentioning the versions used in various LTSes.2. Immediately send a courtesy heads-up email to all build-bot owners telling them about the upcoming change.3. Right after we branch off the release branch for LLVM 11.0.0 (the next one), make the minimum CMake version required be 3.13.4.4. Iterate on (3) until all bots are migrated.5. Send a message to the list saying the bump is complete. At that time, projects are free to start using features from 3.13.4.Unless someone else absolutely wants to bite the bullet, I volunteer to do the above steps.Ok, so the thread has kept going, but AFAICT all the discussion is about a policy for "automatic" upgrades. So I've went ahead and did the first two steps of the above algorithm:(1) Review at https://reviews.llvm.org/D77740(2) Email sent to the owners of all build slaves listed on http://lab.llvm.org:8011/buildslavesJust to reiterate, this means that as soon as we branch LLVM 11.0.0 (the NEXT release), CMake 3.13.4 will be the minimum required version.
Cheers,LouisOn Mar 26, 2020, at 16:07, Shoaib Meenai <sme...@fb.com> wrote:We had this discussion a few months ago and it petered out, and it’s recently been revived in the context of upgrading the CMake version specifically for libc++ (at which point people suggested upgrading the CMake version used by all of LLVM), so let’s try to move this forward.
Our current required minimum version is CMake 3.4.3, which was released on January 25th 2016. It’s interesting to note that LLVM started requiring 3.4.3 on May 31st 2016, which was just 4 months after its release.
Let’s look at the CMake versions available on various distros and operating systems. I’m unfamiliar with many of these, so I apologize if I get something wrong. (I’m using pkgs.org for most of this information.)
* RHEL 6 (released Nov 10th 2010) : 3.6.1 (via EPEL)
* RHEL 7 (released June 10th 2014): 3.14.7 (via EPEL)
* RHEL 8 (released May 7th 2019): 3.11.4 (maybe pkgs.org is screwy on this one, because it doesn’t make sense that RHEL 7 should have a newer available version than RHEL 8)
* Debian 9 (released June 17th 2017): 3.7.2
* Debian 10 (released July 6th 2019): 3.13.4
* Ubuntu 16.04 LTS (released April 21st 2016): 3.5.1
* Ubuntu 18.04 LTS (released April 26th 2018): 3.10.2
* FreeBSD 11 (released October 10th 2016): 3.15.5 (presumably upgraded in a point release)
* FreeBSD 12 (released December 11th 2018): 3.15.5 (presumably upgraded in a point release)
* NetBSD 8.1 (released May 31st 2019): 3.16.1
* NetBSD 9.0 (released February 14th 2020): 3.16.1
* OpenBSD: couldn’t find the version
* macOS: latest version is readily available through Homebrew
* Windows: You can install it yourself or use the one bundled with Visual Studio. I don't know what versions are bundled with Visual Studio; some searching suggests Visual Studio 2017 has CMake 3.12 and Visual Studio 2019 has 3.15, though I have no confirmation of that.
Note that CMake provides prebuilt binaries for Linux, macOS, and Windows, and it’s also straightforward to build from source (it has very conservative compiler requirements). One suggestion that was brought up in the past was for LLVM’s build system to just download a newer version of CMake if you attempted to build it using one that was too old, but there was opposition [1]. There was also a suggestion to have a script in LLVM to download and build CMake for you, but there were mixed opinions on this too [2], particularly since many developers might prefer downloading a binary release to building from source themselves (though of course the script could also download binary releases if applicable). I personally think downloading or building CMake yourself isn’t a high barrier for anyone wanting to build LLVM (and in particular it’s *much* more straightforward than building LLVM itself), but I can understand why people would prefer to stick to versions available in distros.
Another suggestion that came up last time was to set a policy for upgrading CMake versions on some regular basis. The opposition to this was that we should upgrade CMake versions only when a newer version has a compelling enough feature to justify upgrading, rather than always upgrading. I can see arguments for both approaches, but we should definitely at least think about the benefits we can get from upgrading versions. I've gone through the CMake release notes and highlighted features which seemed potentially valuable for LLVM. Note that I'm only highlighting features for which our minimum CMake version would have to be bumped up in order for our build system to take advantage of. There are other useful features in newer CMake versions, but you can take advantage of them just by using a newer CMake yourself. For example, 3.9 loosens the dependencies of object compilation, which should result in faster Ninja builds.
CMake 3.5 (released March 8th 2016):
* install(DIRECTORY) supports generator expressions
CMake 3.6 (released July 7th 2016):
* install() supports EXCLUDE_FROM_ALL
* list() supports FILTER to filter by regular expression
* Subninja support, which could theoretically be used for much faster runtimes builds, although in practice we probably want to make ExternalProject support this directly instead of trying to layer our own meta-build system on top
* CMAKE_TRY_COMPILE_TARGET_TYPE to tell try_compile to build a static library instead of an executable, which will greatly simplify the compiler-rt build
CMake 3.7 (released November 11th 2016):
* New if() comparison operators LESS_EQUAL, GREATER_EQUAL, STRLESS_EQUAL, STRGREATER_EQUAL, VERSION_LESS_EQUAL, and VERSION_GREATER_EQUAL
CMake 3.8 (released April 10th 2017):
* Compile features for C++17, which is required to build libc++ correctly
* Support for compile features for specific C++ features instead of only being able to specify standard versions
* rpath support via BUILD_RPATH target property and CMAKE_BUILD_RPATH variable
* Apple framework support for static libraries
* New swig_add_library command in the UseSWIG module
* New generator expression $<IF:cond,true-value,false-value>
CMake 3.9 (released July 18th 2017):
* install(TARGETS) and install(EXPORTS) support for object libraries, which will simplify the compiler-rt build
* TARGET_OBJECTS generator expression support in add_custom_command and file(GENERATE)
* $<TARGET_BUNDLE_DIR:tgt> and $<TARGET_BUNDLE_CONTENT_DIR:tgt> generator expressions for Apple bundles
CMake 3.10 (released November 20th 2017):
* include_guard() command for proper guarding against double includes of CMake scripts
* An interesting aside is that this is the first verion of CMake to require C++11 to build, which should give a good sense of how conservative they are about compiler requirements
CMake 3.11 (released March 28th 2018):
* add_library() and add_executable() can be called without sources as long as target_sources() is used later
* target_compile_{definitions,features,options}, target_include_directories(), target_sources(), and target_link_libraries() can set the corresponding INTERFACE_* properties on imported targets
* COMPILE_DEFINITIONS supports generator expressions
* COMPILE_OPTIONS source file property added
* INCLUDE_DIRECTORIES source file property added
* Interface libraries support custom properites
CMake 3.12 (released July 17th 2018):
* add_compile_definitions() added to add compile definitions for targets (to avoid the global pollution caused by add_definitions())
* cmake_minimum_required() supports a version range to indicate tested CMake versions and set policies accordingly
* file(TOUCH) and file(TOUCH_NOCREATE) added
* list(JOIN), list(SUBLIST) and list(TRANSFORM) added
* string(JOIN) added
* SHELL: prefix support in target_compile_options to avoid errant deduplication
* target_link_libraries() supports object libraries and propagates usage requirements
* EXPORT_PROPERTIES target property to control the target properties exported by export() and install(EXPORT)
* FindLibXml2 provides imported targets
* New FindPython, FindPython2, and FindPython3 modules to ease location Python and selecting a specific version
* Modernization of UseSWIG module
* New generator expressions $<GENEX_EVAL:...>, $<TARGET_GENEX_EVAL:target,...>, $<IN_LIST:...>, $<TARGET_EXISTS:...> and $<TARGET_NAME_IF_EXISTS:...>
* Compile features support for C++20
CMake 3.13 (released November 20th 2018):
* cmake -E create_symlink supported on Windows
* target_link_directories() and target_link_options() commands to set link options instead of awkwardly having to use target_link_libraries() for this purpose
* UseSWIG can manage INCLUDE_DIRECTORIES for SWIG compilation
CMake 3.14 (released March 14th 2019):
* file(CREATE_LINK) to create hard or symbolic links
* if(DEFINED CACHE{VAR}) for checking if a cache variable is defined
* $<IN_LIST:...> generator expression correctly handles empty argument
* Fixes for object library linking propagation
* Link options to manage position independent executables added automatically
CMake 3.15 (released July 17th 2019):
* list(PREPEND), list(POP_FRONT) and list(POP_BACK) added
* New message() types NOTICE, VERBOSE, DEBUG and TRACE
* string(REPEAT) added
* MSVC_RUNTIME_LIBRARY target property and CMAKE_MSVC_RUNTIME_LIBRARY variable to select the runtime library type for MSVC
* $<C_COMPILER_ID:...>, $<CXX_COMPILER_ID:...>, $<COMPILE_LANGUAGE:...>, and $<PLATFORM_ID:...> generator expressions support matching one value from a list
* $<COMPILE_LANG_AND_ID:...> generator expression added
* $<FILTER:list,INCLUDE|EXCLUDE,regex> generator expression added
* $<REMOVE_DUPLICATES:list> generator expression added
* New $<TARGET_FILE*> generator expressions added: $<TARGET_FILE_PREFIX:...>, $<TARGET_FILE_BASE_NAME:...>, $<TARGET_FILE_SUFFIX:...>, $<TARGET_LINKER_FILE_PREFIX:...>, $<TARGET_LINKER_FILE_BASE_NAME:...>, $<TARGET_LINKER_FILE_SUFFIX:...>, $<TARGET_PDB_FILE_BASE_NAME:...>
* $<TARGET_OBJECTS:...> generator expression supports executables and static, shared, and module libraries
CMake 3.16 (released November 26th 2019):
* Support for generator expressions in BUILD_RPATH and INSTALL_RPATH
CMake 3.17 (released March 20th 2020):
* Ninja Multi-Config generator, which among other things would greatly simplify LLVM_OPTIMIZED_TABLEGEN
* foreach(ZIP_LISTS) added to iterate multiple lists simultaneously
* New message() keywords CHECK_START, CHECK_PASS, and CHECK_FAIL
* INSTALL_NAME_DIR supports generator expressions
Our build system is incredibly complex, and many of these features can be used to clean it up and make it much more maintainable. I would personally like us to at least bump up to CMake 3.12. I also do think it's worth establishing a policy and process around upgrading CMake versions, since newer versions keep on adding useful features (particularly better generator expression support), and we want to be able to keep taking advantage of them.
[1] http://lists.llvm.org/pipermail/llvm-dev/2019-November/136485.html
[2] http://lists.llvm.org/pipermail/llvm-dev/2019-November/136488.html
Jessica Clarke via llvm-dev
>> On Apr 8, 2020, at 13:06, Louis Dionne <ldi...@apple.com> wrote:
>>> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm...@lists.llvm.org> wrote:
>>>
>>> Okay, so we've had some discussion on this thread, and although some people (including me) would like a more aggressive policy, I believe the following will not get any objection (based on the thread). On April 23rd 2020, Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will make the lower bound for LTS distributions be 3.13.4, and so I suggest we upgrade to that. Here's a proposed process:
>>>
>>> 1. Immediately add a CMake warning in <root>/llvm/CMakeLists.txt saying that CMake 3.13.4 will be the new minimum version starting with LLVM 12.0.0, and mentioning the versions used in various LTSes.
>>> 2. Immediately send a courtesy heads-up email to all build-bot owners telling them about the upcoming change.
>>> 3. Right after we branch off the release branch for LLVM 11.0.0 (the next one), make the minimum CMake version required be 3.13.4.
>>> 4. Iterate on (3) until all bots are migrated.
>>> 5. Send a message to the list saying the bump is complete. At that time, projects are free to start using features from 3.13.4.
>>>
>>> Unless someone else absolutely wants to bite the bullet, I volunteer to do the above steps.
>>
>> Ok, so the thread has kept going, but AFAICT all the discussion is about a policy for "automatic" upgrades. So I've went ahead and did the first two steps of the above algorithm:
>>
>> (1) Review at https://reviews.llvm.org/D77740
>> (2) Email sent to the owners of all build slaves listed on http://lab.llvm.org:8011/buildslaves
>>
>> Just to reiterate, this means that as soon as we branch LLVM 11.0.0 (the NEXT release), CMake 3.13.4 will be the minimum required version.
>
> Hi,
>
> Just a heads up that about two weeks from now, we should be branching for the LLVM 11.0.0 release. Right after we branch, I will implement steps (3) and (4) of the algorithm described above, which is to make the minimum CMake version required be 3.13.4. I will do this by checking-in this patch: https://reviews.llvm.org/D78646.
>
> That patch will cause errors whenever the CMake version is less than 3.13.4 -- I will then revert and re-apply this patch until all build bots have upgraded to a sufficient CMake. The patch was crafted to be minimal and revert-friendly. Note that build bot owners have already been contacted in March and pinged several times again for those who had not yet upgraded. At this time, I think only 1-2 bots have not upgraded.
>
> Once everyone has upgraded, I will then apply this patch: https://reviews.llvm.org/D78648. That patch marks the minimum CMake version required as being 3.13.4 throughout the monorepo in a slightly more invasive but definitive way. Once that's all done, I'll report to the list that the version bump is complete and we can all start using modern CMake features.
>
> Cheers,
> Louis
I missed this entire discussion but would like to chime in. All of our department's machines run on Ubuntu 18.04 as standard. I suspect the same is true across a large number of organisations, as Ubuntu is a very popular distribution, and the 18.04 LTS is still widely supported by most projects. Whilst Ubuntu 20.04 has been released for a couple of months, it's going to be a while until everyone has updated. In fact, it isn't yet *officially supported* to upgrade from 18.04 to 20.04, as you have to wait for the first point release for that, due in August. So as far as Canonical are concerned, if you installed 18.04 LTS, you should still be on that, and 20.04 isn't ready for those people quite yet. That's a lot of people affected who may not be following llvm-dev but will suddenly find themselves in need of a custom CMake.
I would urge people to reconsider this move. I can see the attraction of moving to the latest CMake, but we've managed just fine so far, do we really need to move to the latest and greatest right now? Ditching support for 18.04 in a year's time would seem reasonable, but expecting everyone to have moved over when it's not yet officially supported after just 3 months is not, and forcing everyone on those distributions to build their own copy of CMake just for LLVM is annoying (sure, I'm perfectly capable of doing it, but it's still a nuisance that aggravates me). I'd suggest waiting at least until 20.04.1 has been released, so waiting until the next release cycle would allow that and give around 6 months for people to update, if not until the release cycle after that (though that may be a harder pill for some members to swallow). But we could at least bump to 3.10.2 in the meantime.
Jess
James Y Knight via llvm-dev
Keane, Erich via llvm-dev
It is curious to me that we had so much push back about moving host-compiler versions, yet so little on the cmake versions. In my opinion, we need to have a unified ‘dependency age’ policy. Cmake 3.13.4 was released about 18 months ago, so unless we’re willing to move our GCC version to 8.3 JUST as easily, this seems like a horrific double standard.
From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of
James Y Knight via llvm-dev
Sent: Thursday, July 16, 2020 6:21 PM
To: Jessica Clarke <jrt...@jrtc27.com>
Cc: llvm...@lists.llvm.org
Subject: Re: [llvm-dev] Upgrading LLVM's minimum required CMake version
Please, no more waiting on CMake versions in distro LTS releases. We have been way too conservative already, waiting this long.
Mehdi AMINI via llvm-dev
Mehdi AMINI via llvm-dev
Jessica Clarke via llvm-dev
Jess
Mehdi AMINI via llvm-dev
I wouldn't encourage using the apt repo. The whole PPA/random apt repo thing is bad security practice, as any package being installed has full root access to the system during its maintscripts. PPAs are marginally better since they are at least hosted on launchpad.net and so have some guarantees over the infrastructure, but you shouldn't trust a random apt repo out there has good security practices with its signing key (even if you trust the authors of the software). It is a shame Ubuntu's backports are basically non-existent (I've tried to get backports uploaded for *my own* packages before and they just sit in the queue), as I'd be completely fine with saying "just enable bionic-backports and install from there". But the world on Ubuntu is dysfunctional there, unlike Debian's sane world. Maybe I can talk to some Ubuntu developers and see if they can force a backport through.Also, please bear in mind the distro maintenance story. Firefox needs regular security updates, and depends on Rust, which itself depends on LLVM. Given the fast-moving nature of Rust, it may well be that Ubuntu needs to update to a newer Rust to support the latest Firefox ESR, and that that Rust depends on LLVM 12+, forcing them to also have to update CMake. I don't think dependency bumps of any kind should be taken lightly when LLVM is becoming such a crucial part of modern systems.
Jessica Clarke via llvm-dev
On Thu, Jul 16, 2020 at 6:57 PM Jessica Clarke via llvm-dev <llvm...@lists.llvm.org> wrote:I wouldn't encourage using the apt repo. The whole PPA/random apt repo thing is bad security practice, as any package being installed has full root access to the system during its maintscripts. PPAs are marginally better since they are at least hosted on launchpad.net and so have some guarantees over the infrastructure, but you shouldn't trust a random apt repo out there has good security practices with its signing key (even if you trust the authors of the software). It is a shame Ubuntu's backports are basically non-existent (I've tried to get backports uploaded for *my own* packages before and they just sit in the queue), as I'd be completely fine with saying "just enable bionic-backports and install from there". But the world on Ubuntu is dysfunctional there, unlike Debian's sane world. Maybe I can talk to some Ubuntu developers and see if they can force a backport through.Also, please bear in mind the distro maintenance story. Firefox needs regular security updates, and depends on Rust, which itself depends on LLVM. Given the fast-moving nature of Rust, it may well be that Ubuntu needs to update to a newer Rust to support the latest Firefox ESR, and that that Rust depends on LLVM 12+, forcing them to also have to update CMake. I don't think dependency bumps of any kind should be taken lightly when LLVM is becoming such a crucial part of modern systems.I am not super familiar with this level of details in the package build system, but CMake isn't a "public" dependency of LLVM: it is needed to build LLVM but then the resulting package does not depend on CMake. As such a dedicated version of CMake can be bootstrapped and stay private in the build-directory (cf the revision I posted separately) of LLVM when building the package itself.
Tom Stellard via llvm-dev
I think you may have a better outcome by providing feedback to
Canonical/Ubuntu that you would like a newer CMake to be available.
Just as an example, for Red Hat Enterprise Linux 7, when we needed a
newer CMake for building LLVM, we packaged it and shipped it to
customers. Yes, we had to namespace the package and call it
llvm-toolset-9.0-cmake, but this seems like something Ubuntu could
easily do.
-Tom
Shoaib Meenai via llvm-dev
A build system is just like any piece of code. LLVM's build system is a complex piece of software, and that complexity is a burden for everyone. We want to move to a newer CMake version so that we can use the new features to simplify the build system and make it work better. Note in particular that 3.15 adds lots of new generator expressions which are really useful, and that would have been our ideal upgrade target, but we stuck to 3.12.4 for now because of LTS CMake version considerations.
On 7/16/20, 5:05 PM, "llvm-dev on behalf of Jessica Clarke via llvm-dev" <llvm-dev...@lists.llvm.org on behalf of llvm...@lists.llvm.org> wrote:
On 30 Jun 2020, at 16:04, Louis Dionne via llvm-dev <llvm...@lists.llvm.org> wrote:
>> On Apr 8, 2020, at 13:06, Louis Dionne <ldi...@apple.com> wrote:
>>> On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm...@lists.llvm.org> wrote:
>>>
>>> Okay, so we've had some discussion on this thread, and although some people (including me) would like a more aggressive policy, I believe the following will not get any objection (based on the thread). On April 23rd 2020, Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will make the lower bound for LTS distributions be 3.13.4, and so I suggest we upgrade to that. Here's a proposed process:
>>>
>>> 1. Immediately add a CMake warning in <root>/llvm/CMakeLists.txt saying that CMake 3.13.4 will be the new minimum version starting with LLVM 12.0.0, and mentioning the versions used in various LTSes.
>>> 2. Immediately send a courtesy heads-up email to all build-bot owners telling them about the upcoming change.
>>> 3. Right after we branch off the release branch for LLVM 11.0.0 (the next one), make the minimum CMake version required be 3.13.4.
>>> 4. Iterate on (3) until all bots are migrated.
>>> 5. Send a message to the list saying the bump is complete. At that time, projects are free to start using features from 3.13.4.
>>>
>>> Unless someone else absolutely wants to bite the bullet, I volunteer to do the above steps.
>>
>> Ok, so the thread has kept going, but AFAICT all the discussion is about a policy for "automatic" upgrades. So I've went ahead and did the first two steps of the above algorithm:
>>
>> (2) Email sent to the owners of all build slaves listed on https://urldefense.proofpoint.com/v2/url?u=http-3A__lab.llvm.org-3A8011_buildslaves&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=xSL2Z8Pv1kbJ1QtNObh2ZtF-zEKehxxeojgGs2jeZnc&s=jM2ytDUqh-ZWevvPRhD7Ktfg1p3r_0sCL0worXGcAEU&e=
>> Just to reiterate, this means that as soon as we branch LLVM 11.0.0 (the NEXT release), CMake 3.13.4 will be the minimum required version.
>
> Hi,
>
> That patch will cause errors whenever the CMake version is less than 3.13.4 -- I will then revert and re-apply this patch until all build bots have upgraded to a sufficient CMake. The patch was crafted to be minimal and revert-friendly. Note that build bot owners have already been contacted in March and pinged several times again for those who had not yet upgraded. At this time, I think only 1-2 bots have not upgraded.
>
> Cheers,
> Louis
I missed this entire discussion but would like to chime in. All of our department's machines run on Ubuntu 18.04 as standard. I suspect the same is true across a large number of organisations, as Ubuntu is a very popular distribution, and the 18.04 LTS is still widely supported by most projects. Whilst Ubuntu 20.04 has been released for a couple of months, it's going to be a while until everyone has updated. In fact, it isn't yet *officially supported* to upgrade from 18.04 to 20.04, as you have to wait for the first point release for that, due in August. So as far as Canonical are concerned, if you installed 18.04 LTS, you should still be on that, and 20.04 isn't ready for those people quite yet. That's a lot of people affected who may not be following llvm-dev but will suddenly find themselves in need of a custom CMake.
I would urge people to reconsider this move. I can see the attraction of moving to the latest CMake, but we've managed just fine so far, do we really need to move to the latest and greatest right now? Ditching support for 18.04 in a year's time would seem reasonable, but expecting everyone to have moved over when it's not yet officially supported after just 3 months is not, and forcing everyone on those distributions to build their own copy of CMake just for LLVM is annoying (sure, I'm perfectly capable of doing it, but it's still a nuisance that aggravates me). I'd suggest waiting at least until 20.04.1 has been released, so waiting until the next release cycle would allow that and give around 6 months for people to update, if not until the release cycle after that (though that may be a harder pill for some members to swallow). But we could at least bump to 3.10.2 in the meantime.
Jess
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
Philip Reames via llvm-dev
+1 to Medhi's point here.
Using a standalone cmake is easy; using a customer toolchain is not.
Philip
Louis Dionne via llvm-dev
On Jun 30, 2020, at 11:04, Louis Dionne via llvm-dev <llvm...@lists.llvm.org> wrote:On Apr 8, 2020, at 13:06, Louis Dionne <ldi...@apple.com> wrote:On Apr 2, 2020, at 10:19, Louis Dionne via llvm-dev <llvm...@lists.llvm.org> wrote:Okay, so we've had some discussion on this thread, and although some people (including me) would like a more aggressive policy, I believe the following will not get any objection (based on the thread). On April 23rd 2020, Ubuntu 20.04 LTS will ship with CMake 3.16.x. This will make the lower bound for LTS distributions be 3.13.4, and so I suggest we upgrade to that. Here's a proposed process:1. Immediately add a CMake warning in <root>/llvm/CMakeLists.txt saying that CMake 3.13.4 will be the new minimum version starting with LLVM 12.0.0, and mentioning the versions used in various LTSes.2. Immediately send a courtesy heads-up email to all build-bot owners telling them about the upcoming change.3. Right after we branch off the release branch for LLVM 11.0.0 (the next one), make the minimum CMake version required be 3.13.4.4. Iterate on (3) until all bots are migrated.5. Send a message to the list saying the bump is complete. At that time, projects are free to start using features from 3.13.4.Unless someone else absolutely wants to bite the bullet, I volunteer to do the above steps.Ok, so the thread has kept going, but AFAICT all the discussion is about a policy for "automatic" upgrades. So I've went ahead and did the first two steps of the above algorithm:(1) Review at https://reviews.llvm.org/D77740(2) Email sent to the owners of all build slaves listed on http://lab.llvm.org:8011/buildslavesJust to reiterate, this means that as soon as we branch LLVM 11.0.0 (the NEXT release), CMake 3.13.4 will be the minimum required version.Hi,Just a heads up that about two weeks from now, we should be branching for the LLVM 11.0.0 release. Right after we branch, I will implement steps (3) and (4) of the algorithm described above, which is to make the minimum CMake version required be 3.13.4. I will do this by checking-in this patch: https://reviews.llvm.org/D78646.That patch will cause errors whenever the CMake version is less than 3.13.4 -- I will then revert and re-apply this patch until all build bots have upgraded to a sufficient CMake. The patch was crafted to be minimal and revert-friendly. Note that build bot owners have already been contacted in March and pinged several times again for those who had not yet upgraded. At this time, I think only 1-2 bots have not upgraded.Once everyone has upgraded, I will then apply this patch: https://reviews.llvm.org/D78648. That patch marks the minimum CMake version required as being 3.13.4 throughout the monorepo in a slightly more invasive but definitive way. Once that's all done, I'll report to the list that the version bump is complete and we can all start using modern CMake features.