Conan: Please feedback: Minimum CMake version required

[memsharded]

We are discussing about the new toolchain() feature (https://github.com/conan-io/conan/pull/5919), and what would be the minimum cmake version that will be required in future Conan 2.0 releases.

There are some goodies in latests CMake versions that we are already using in some parts of the toolchain:

• CMAKE_PROJECT_INCLUDE
• CMAKE_MSVC_RUNTIME_LIBRARY

We have been supporting back to cmake 2.8.12, and some parts of the generators (targets) require using CMake >= 3.3.

We are defining a minimum required CMake version as a base for future development. Please provide your feedback, why is the CMake version you are using, plans to upgrade if any, and other requirements.

[tru]

We stay on the latest at least within 6 months.

[tonka3000]

The minimum I use is 3.7

[torfinnberset]

We are currently on 3.15, planning to move to 3.17 soon

[jpovedano]

Currently using 3.12, planning to move to more recent versions sometime soon

[andreya108]

3.10 (currently the latest officially supported by Android SDK)
But I hope they will update it...

[wdobbe]

Some of our older Yocto SDKs are on CMake 3.12 so that is the current minimum in our company.
However it wouldn't be a problem if Conan 2 would require a newer CMake version, we would simply use the Conan cmake package i.s.o. the cmake in the SDK.

[GordonJess]

3.15, planning to move to 3.17

[Artalus]

3.13 at work, 3.17 at home. The only thing delaying rolling updates is laziness, we have to update several system images which is currently cumbersome to do "just because we wanted".

[barmaglot27]

CMake 3.9.6 as it is highest version that still supports HP-UX (pls don't judge)

[Johnnyxy]

I am using multiple but recent versions of CMake.
But I also had to use Linux distributions (Debian, older Ubuntu, openSUSE, ...) which had no recent CMake version available (including no Python 3). Some more conservative systems like Debian could be a good starting point for such discussions as they live a "long time".

The following table contains some examples of "older" distributions and their CMake availbility (on release). The online repositories normally contain newer versions (often seen 3.10. or later e.g. Ubuntu 16.04 repo).

| OS | Date | CMake |
|----------------------|-----------------|-------|
| Debian 8 (jessie) | 26 April 2015 | 3.0 |
| Debian 9 (stretch) | 17 June 2017 | 3.7 |
| Debian 10.4 (buster) | 6 July 2019 | 3.13 |
| Ubuntu (14.04 LTS) | 17 April 2014 | 3.0 |
| Ubuntu (16.04 LTS) | 21 October 2015 | 3.5 |
| Ubuntu (18.04 LTS) | 26 April 2018 | 3.10 |

[tru]

Fortunately there are Conan packages with CMake and the cmake website offers static binaries to download. I don't think much consideration should be given to really old dists since there is a easy way to upgrade.

[Johnnyxy]

Generally yes and specifially no :).
Yes, one can upgrade CMake (sometimes with some effort) as the source is available.
No, CMake binaries are only available for a limited range of targets (e.g. Linux x86 has been dropped since CMake 3.7). Coincidentally I have such case at the moment where I have to use an older openSUSE x86 variant (openSUSE 13.1 x86; CMake 3.11.4) to build via Conan and CMake and this is not the oldest variant I have been _blessed_ with.

[MarcelRaad]

The oldest one I'm using is 3.11 on RHEL 8. Otherwise mostly 3.15.

[GrimSqueaker]

CMake 3.11 is the oldest that we use in some builds, because VS 2005 (don't ask...) support was dropped in CMake 3.12.

[puetzk]

We have 3.17 deployed everywhere but except a couple legacy projects in VS2005 (which is stuck at 3.11 as @GrimSqueaker points out). We conan export packages with these binaries (so that their files can be imported) but don't use conan (or CMake) in their build process because it's not due to be invented for a while yet, so the old CMake is just for the test_package.

Right now most of our CMakeLists have minimum 3.16, for PCH support.

[boussaffawalid]

We always use latest greatest version of cmake.

[KerstinKeller]

If Conan Center Index can provide prebuild binaries for common distros and a working recipe for all others, there is no need to stay on an old CMake Version. . CMake itself has almost no dependencies to be build, just curl for newer versions. Then it can easily be consumed as a build requirement Conan package,

As it's only a build requirement, I see no disadvantages for using a Conan CMake package over the system package, as, in the end, both CMake versions should produce the same binaries.

Some newer features which might be helpful: Alias targets of imported targets (3.11), CMAKE_FIND_PACKAGE_PREFER_CONFIG variable (3.15), ...

[Johnnyxy]

Consuming a CMake recipe from within another recipe and starting the consumed CMake variant will not work if conan gets started from CMake initially (see here).

The reason is that CMake is already running (e.g. v3.10) and by design cannot just start another CMake instance from a different variant (e.g. v3.16). It may work with some changes to the CMake configuration (like setting CMAKE_ROOT) but I did not manage to make it work without problems until now.

[ytimenkov]

Having any recent CMake is a 1 line in profile.
Thanks to the full path to cmake executable stored in the generated build system there is no need for extra environment activation, i.e. if CMakeLists.txt change proper CMake will be used.
The only trick is the initial configuration... (See #7226)