[tools] CMake 3.15 required

[jgsogo]

CMake is one of the main external tool we call from Conan, transparent integration and reliability should be a priority. It is important to declare a minimum supported version so we can run all the tests and be confident that the user will get the
expected results and no regressions will be introduced.

---

• Upvote 👍 or downvote 👎 to show acceptance or not to the proposal (other reactions will be ignored)
  • Please, use 👀 to acknowledge you've read it, but it doesn't affect your workflow
• Comment and reviews to suggest changes to all (or part) of the proposal.

[memsharded]

It is good. I think I would add a few lines for summary and voting process in the PR comment

[a4z]

before I vote, I wonder why 3.15, what are the features that have been added with 3.15
I think all nice features I remember, like precompile header and multi config builds, came with 3.16.x ? (but I might be wrong)
so why not one of the newer ones with those features, given how easy it is to get cmake installed on your machine, this should not be a problem

[memsharded]

before I vote, I wonder why 3.15, what are the features that have been added with 3.15

The relevant features for Conan are described in the proposal document: https://github.com/conan-io/tribe/pull/4/files. They are based on what Conan needs to operate consistently and implement its logic (toolchains, generators), not on generic CMake features.

[Daniel-Roberts-Bose]

I usually support using the newer versions of tools wherever possible however, I am wondering what the motivation is here for a release that is only just over a year old.

We currently use a much older version of CMake, we could likely upgrade to be compatible with conan 2.0 but I would like to know the motivation for selecting this version for conan 2.0.

Is it simply to make the test matrix for conan smaller (ie. you need to maintain compatibility with much fewer versions of CMake, making testing easier) or are there some critical features introduced in newer versions of CMake that you plan to use and integrate with, and if so, what are they?

[memsharded]

Hi @Daniel-Roberts-Bose

Please read https://github.com/conan-io/tribe/pull/4/files. In short:

• Support for VS2019
• Support for the CMAKE_PROJECT_INCLUDE feature, that we use in the toolchains (otherwise requires more manual work in the consumer CMakeLists.txt)
• Support for CMAKE_MSVC_RUNTIME_LIBRARY to select the VS runtime

There are a couple of other things that requires at least CMake 3.14, and we have hacks in the Conan codebase, like correctly defining CMAKE_SYSTEM_NAME under Apple for iOS, watchOS...

[madebr]

I would amend the change with a requirement that every cmake script must check the cmake version:

cmake_minimum_required(VERSION 3.15)

Would it be useful to document the behaviour of the cmake generators + cmake build helpers documented such that somebody can create a CMakeLegacy* build helper or cmake_legacy` build helper?

[jonatin]

For the category of "minimum supported version of X" I'd suggest that Conan also put together a list of officially supported platforms, to include the major OS releases. Then I'd suggest enumerating the current version of the tool that's provided (or very easily obtainable) for that platform.

OS	Current available cmake version
macOS (brew)	3.18.4
Debian Stable	3.13.4
Ubuntu LTS	3.16.3
EPEL 7	3.17.3
RHEL / CentOS / Oracle Linux 8	3.11.3
etc	etc

Not every OS supports an easy way to update to current tools, so it's important to know which supported platforms are lacking and what (non-controversial) methods are available for installing the toolchain.

[davidtazy]

I do not agree.
The lowest version of its dependancies conan will support, the more users conan can expect.
recent version of dependancies is good for conan developpers , it is bad for user community.

I could not find any survey showing us % of users using at least 3.15.
I could not find minimal version required by vcpkg.

IMHO conan should support at least cmake 3.9.6 (3 years old)

[madebr]

@jgsogo
What is the ETA of conan 2.0? So we can put things in perspective.

[memsharded]

What is the ETA of conan 2.0? So we can put things in perspective.

There is still no defined ETA for Conan 2.0, depends on the scope of some core features and changes (still to be discussed), but I would say that not earlier than June 2021.

The lowest version of its dependencies conan will support, the more users conan can expect.

I don't think we should try to optimize for the needs of possible future Conan users, and choosing versions based on time is not representative of real usage. The Conan community is large enough, and this is exactly the purpose of this Tribe: lets choose the latest possible version that satisfy the current Conan user base. This should be good as a proxy for other possible future Conan users needs.

In that regard an important note: You should report what is the version support that you need, no need to design or to decide for others. You can be "selfish". The Tribe is big enough to be representative of real world constraints, if someone is constrained, lets say to CMake 3.9, because of reason X, they should report it and give that direct feedback here

[dheater]

Are we planning to use the cmake package from Conan itself as is often done for automake, autoconf`, etc...? That would make it irrelevant which version is installed by default on the OS/Distro

[puetzk]

I could not find any survey showing us % of users using at least 3.15.
I could not find minimal version required by vcpkg.

Vcpkg downloads its own cmake executable, curently 3.18.4. cmake is packaged in conan-center, so anyone who wanted could do the same with a [build_requires] in their profile...

[memsharded]

Are we planning to use the cmake package from Conan itself as is often done for automake, autoconf`, etc...? That would make it irrelevant which version is installed by default on the OS/Distro

No, we don't plan to force that as built-in, we think it is important to let users the possibility to define their own CMake, and not depend on ConanCenter if they don't want to (some might not even be able due to policies or other constraints). We think that users should be able to use their own system-installed CMake without problems.

[puetzk]

We think that users should be able to use their own system-installed CMake without problems.

I agree 100% with "should be able to", and maybe about 50% with "should have to do it". It would be very nice if (particularly if conan-io/conan#7240 becomes a thing), to have a some explicit way for a [build_requires] package (probably from the profile) to hook into the way the build helpers look for their respective tools, so one could confidently say "this profile is using the cmake/msbuild/vswhere/etc from a locked package.

But that's quite a different issue from "what's the minimum version", albeit if it existed it would be an easy way to deal with an environment whose system package is too old to meet said minimum.

[rasjani]

We just recently bumped cmake to 3.18.4. Some of our devs seems seems to have issues with upgrading cmake because we are still on vs2017 and it ships older cmake which seem to be a bit harder to bypass on the GUI side. I work 100% to shell so I don't know how much trouble this could be for general usage.

[davidtazy]

You should report what is the version support that you need, no need to design or to decide for others. You can be "selfish". The Tribe is big enough to be representative of real world constraints, if someone is constrained, lets say to CMake 3.9, because of reason X, they should report it and give that direct feedback here

actually using cmake 3.9.6

[kenfred]

We just recently bumped cmake to 3.18.4. Some of our devs seems seems to have issues with upgrading cmake because we are still on vs2017 and it ships older cmake which seem to be a bit harder to bypass on the GUI side. I work 100% to shell so I don't know how much trouble this could be for general usage.

I have also experienced this kind of logistical hurdle among dev teams. The version of cmake that comes via apt-get in the standard Debian/Ubuntu channels is behind 3.15. To get a more recent version of cmake requires additional steps. Similarly, embedded toolchains (like from Yocto recipes) lag behind in cmake version.

None of this is insurmountable - it's just a barrier to entry that may hamper adoption, particularly among large organizations with established tooling and lots of developers to keep happy.

[puetzk]

we are still on vs2017 and it ships older cmake which seem to be a bit harder to bypass on the GUI side

We filed https://developercommunity.visualstudio.com/idea/419081/add-option-to-vcvarsallbat-to-pick-and-choose-what.html a long time ago asking for a way in vcvarsall to avoid MS throwing other random tools (cmake, ninja, etc) into PATH when we were just asking for the VC compiler/Windows SDK/etc. We've actually written a [build_requires] package into our MSVC profiles whose jobs is to run vcvarsall, filter those back out, and then export an environment that has the desired PATH (and other vcvars env vars), which suppresses conan's own use of vcvars. But this is quite ugly to have to do that, and I'd certainly welcome anyone else getting bitten by this to pile some more votes on the request and see if MS can be persuaded to make it better :-)

This is of course also at root in issues like conan-io/conan#6577

[DoDoENT]

No, we don't plan to force that as built-in, we think it is important to let users the possibility to define their own CMake, and not depend on ConanCenter if they don't want to (some might not even be able due to policies or other constraints). We think that users should be able to use their own system-installed CMake without problems.

You don't have to force users to depend on ConanCenter if you mandate using the cmake version provided as conan package. It can be simply a configuration entry in conan.conf or similar - by default the version from ConanCenter would be used and users could override the default to use either system version of cmake or cmake from custom conan package. If such setting existed, it should not be a problem to bump minimum supported CMake version even with conan updates (e.g. conan 2.0 requiring cmake 3.15 (or newer), conan 2.5 requiring cmake 3.16 (or newer), etc.). If a system version is selected and is a too old version, conan can issue an error and inform the user to either update the system version of CMake, use the default version from ConanCenter, or provide custom conan package containing the correct version of CMake.

I know that some companies don't allow using packages from ConanCenter (mine included), but, at least in our case, we have a custom cmake/<version>@microblink/stable conan package that is built using a custom recipe (we did that because cmake from ConanCenter breaks when using our conan profiles). This not only benefits conan developers, as they don't have to worry about supporting very old versions of CMake, but also developers and CI maintainers, as they don't have to worry about manually installing the correct version of CMake.

[puetzk]

It can be simply a configuration entry in conan.conf or similar

One thing I would really like to see is a the ability for profiles to do overrides for [build_requires]. If using the build helper just somehow injected a [build_requires] cmake/[^3.15] (which would, per defaults, be the resolved with the conan-center package) doing a version override would be a very natural-feeling way to redirect it something else. Profiles already can override build_requires in conan 1.x, but not without also adding the build_requires in the first place; they can't currently do "override if present" like self.requires(..., override=True) does.

And I'd like profiles to be able to do overrides for [requires] as well, though for separate reasons (I sometimes want to replace dependencies with "shim" packages that use a system_requires or similar for certain profiles).

[memsharded]

One thing I would really like to see is a the ability for profiles to do overrides for [build_requires]. If using the build helper just somehow injected a [build_requires] cmake/[^3.15] (which would, per defaults, be the resolved with the conan-center package) doing a version override would be a very natural-feeling way to redirect it something else. Profiles already can override build_requires in conan 1.x, but not without also adding the build_requires in the first place; they can't currently do "override if present" like self.requires(..., override=True) does.

We will be discussing the graph-model later, and it will probably be one of the biggest thing (it will need to be broken into multiple pieces for proposals and discussions)

To clarify: we don't plan to remove the ability of users to use their own tools like CMake or Visual Studio, installed in their system in the way they like. We might provide other useful ways to install them, as with Conan packages, build_requires, or even new features, but removing the ability of users to provide their own tools directly themselves, is not under consideration. The current proposal applies mainly for this case, as for other cases as using build_requires, is not relevant.

[dheater]

Looking for a clarification. What is the intent of the minimum supported version? Is it just the minimum version that CCI will use in testing? The minimum version for use in CCI recipes? Will people still be able to use older versions of CMake (assuming it meets the cmake_minimum_required of the originating project)? Will issues raised where the user is using an older CMake be rejected?

[memsharded]

Looking for a clarification. What is the intent of the minimum supported version? Is it just the minimum version that CCI will use in testing? The minimum version for use in CCI recipes?

@dheater nothing to do with ConanCenter, but with Conan itself. The generators like cmake or cmake_find_package_multi, or the CMakeToolchain (which will be the CMake integration in Conan 2.0) will use CMake syntax that only works in CMake 3.15, if possible. This will imply of course that ConanCenter recipes will require at least this CMake version, but ConanCenter might impose other constraints, like the current one that it only works with latest Conan.

Will people still be able to use older versions of CMake (assuming it meets the cmake_minimum_required of the originating project)? Will issues raised where the user is using an older CMake be rejected?

Users might not be able to use the new standard proposed integration with cmake (basically an improved cmake_find_package_multi generator + CMakeToolchain toolchain). Users might need to provide their own integrations, explicitly opt-in into possible legacy integrations (that might not implement as many features, or might not be provided at all, depending on demand).

[rjktcby]

voted 👍 as we're using 3.17 and it wouldn't be a problem but do agree with concern that not supporting CMake that comes with apt install in major Linux distros will be an unnecessary hurdle raising eyebrows

[climblinne]

We use a custom 12.2 version, because we support our own "TI CCS" Studio (adapted from the Visual Studio support), which is not in main line.

[sztomi]

Worth noting that Visual Studio ships a CMake version, so this and #5 are possibly bound together (not for everyone, but some people do end up not installing their own CMake, so they use whatever VS gives them).

[czoido]

Hi Tribe,
Finally, we have decided to merge this proposal with this comment:
We want to develop Conan 2.0 targeting this minimum CMake version but considering that the situation will change from the moment of approval to when Conan 2.0 is released. At that moment, we will evaluate user's feedback to check if it's necessary to add some workarounds or opt-out behaviour for users chained to previous versions.
Thanks a lot for all your comments!

[jcar87]

Apologies for my late feedback on this.

If conan were to require a "recent" version of CMake (e.g such as 3.15) I believe that on most mainstream Linux distros and on windows, installing a recent version of cmake should be easy enough as to not be a big problem (e.g. for Ubuntu, Kitware maintains a repo that covers 16.04 onwards: https://apt.kitware.com/)

However it's probably worth mentioning that on certain ARM-based platforms like the Raspberry Pi or NVIDIA Jetson, it's not as trivial and may require building it from source. Raspberry Pi is currently based on Debian buster (CMake 3.13.x) and the JetPack is based on Ubuntu 18.04 (CMake 3.10) - Unfortunately kitware doesn't provide ARM binaries for 18.04. I think one of the strengths of conan is the way it handles support for multiple platforms, so having to build cmake from source may increase the cost of entry. Perhaps for these platforms it is more common to cross-compile from an x86_64 system anyway (conan handles it easily and faster!) - but it's something worth noting. I suppose at some point next year both RPi and Jetson will be updated to more recent versions anyway

[memsharded]

Thanks for the late feedback @jcar87

Perhaps for these platforms it is more common to cross-compile from an x86_64 system anyway (conan handles it easily and faster!) - but it's something worth noting. I suppose at some point next year both RPi and Jetson will be updated to more recent versions anyway

Yes, we think so, that by the time Conan 2.0 is released, some distros might have updated CMake too. It is also worth noting that requiring CMake 3.15 might not be a complete blocker in all cases, and there might be workarounds for using other older versions, the closer to 3.15, the most likely there will be viable workarounds, of course.

[mpusz]

Having a CMake minimum requirement fixed is a good thing but still, it might not be enough. You have to leave a way to be able to bump this requirement when needed or be prepared to release Conan 3.0 soon. I might be wrong but I think that in the next few CMake releases we can expect a lot of changes addressing C++20 modules and I bet you want to support them with Conan too.

[memsharded]

Having a CMake minimum requirement fixed is a good thing but still, it might not be enough. You have to leave a way to be able to bump this requirement when needed or be prepared to release Conan 3.0 soon. I might be wrong but I think that in the next few CMake releases we can expect a lot of changes addressing C++20 modules and I bet you want to support them with Conan too.

It is not incompatible. Conan can request latest CMake to support some modern features, like C++modules, still support CMake 3.15 for all the other users that do not plan to adopt modules that fast (that will probably be a large part of the Conan users). It is not necessary a Conan 3.0 to support it, the proposal is about minimum versions, but of course versions later than the minimum one should work too.

[mpusz]

Sure, just keep in mind that this is not transparent for Conan. Conan CMake helper and toolchain may need to use new or updated commands to provide modules support. Such files generated by Conan will be incompatible with CMake 3.15 which is the official minimum requirement for Conan.

[mpusz]

I just noticed one interesting point to support CMake 3.17. It introduced "Ninja Multi-Config" generator which works perfectly well with "cmake_find_package_multi". With this, one build directory is enough to build every configuration in a robust way.

mkdir build && cd build
conan install .. -s build_type=Release
conan install .. -s build_type=Debug
cmake .. -G "Ninja Multi-Config" -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake
cmake --build . --config Release
cmake --build . --config Debug