[question] CMake soon bumps version to 4.0, need to reconsider CMake's tool_requires version ranges

[leha-bot]

What is your question?

Currently there are ~157 code results with CMake version ranges:
https://github.com/search?q=repo%3Aconan-io%2Fconan-center-index+%22cmake%2F%5B%22+language%3APython&type=code
A lot of them uses "<4" as the upper bound of range.
CMake 4.0 actually compatible with previous 3.31, but drops very ancient policies upto CMake 3.5:
https://gitlab.kitware.com/cmake/cmake/-/issues/26613

We should update any CMake version ranges, with lower bound >= 3.5.
For another (<3.5, but I think, we haven't these versions), there will be an escape hatch from upstream (for some time): https://gitlab.kitware.com/cmake/cmake/-/issues/26698

Also we should to update our version ranges policies.

Cc @memsharded

[jcar87]

We should update any CMake version ranges, with lower bound >= 3.5.

I think there is some confusion here.
The CMakeDeps integration of Conan 2 requires CMake 3.15 as the minimum (even if a top-level CMakeLists.txt is compatible with a lower version) - so "implicitly", the lower bound for all Conan Center recipes is 3.15. So far our policy has been to add cmake as a tool_requires when the version required is higher than 3.15, typically to match the lower bound of the cmake_minimum_required of the top-level CMakeLists.txt of the sources we are building.

This has been confusing to some users in the past, but note that the range in cmake_minimum_required(VERSION 3.3...4.0) - does not correspond to the version range used in the recipes:

• The lower bound of the version range on the requirement can't be any lower than the lower bound of cmake_minimum_required, that much is correct. In practice for Conan Center + CMakeDeps, it can't be any lower than 3.15
• The upper bound cmake_minimum_required has nothing to do with the upper bound of the version range on the requirement - as per CMake's documentation, this is "policy max": https://cmake.org/cmake/help/latest/command/cmake_minimum_required.html - the projects are still compatible with any version of CMake that supports that policy level, even if it's higher than that "policy max" value.

What I'm gathering from the links you have provided:

• CMake 4.0 will no longer be compatible with projects that have cmake_minimum_required(VERSION 2.8.) (or lower than 3.5) - and thus will fail.
• CMake 4.0 will be compatible with projects that have either the minimum version set to 3.5 or above, or the "max policy" version set to 3.5 or above.

If this is the case:

• For recipes that don't have a current tool_requirement on CMake, but have a cmake_minimum_required set to version a version lower than 3.5 and a policy max that is not 3.5 or higher - we may want to introduce a tool requirement on CMake with an upper bound of <4 - something like: cmake/[>=3.15 <4], or alternatively, define the newly-added CMAKE_POLICY_VERSION_MINIMUM to help CMake 4 users

• For recipes that currently have a tool_requirement on CMake, it may be the case that the upper bound can be unconstrained, or set to <5 - that is, if CMake 4.0 is known to be compatible, and expected to be compatible across 4.x releases, then this is possible. However I wouldn't be overtly concerned here or rush to refactor the entire repository - because the current upper bound will still work reliably and get users to produce the correct contents of the binary packages

[leha-bot]

However I wouldn't be overtly concerned here or rush to refactor the entire repository - because the current upper bound will still work reliably and get users to produce the correct contents of the binary packages

Actually, there are some problems with some environments (alpine musl (partially worked around also via some hacks from conan-io/conan#16179 (comment)), android; non-x86 platforms) with prebuilt cmake, so I have to replace_tool_requires to system cmake, and in that case version ranges could break workflow, but I'm not sure in this