[question] Are earlier CMake versions than 3.15 no longer supported in conan v2.0?

[saukijan]

What is your question?

Since conan v2.0 no longer supports the old cmake generators in favor of the new ones, and the new CMakeToolchain only works with CMake >= 3.15 versions, does that implicitly mean that conan v2.0 does not work with anything that uses CMake < 3.15? Or is there a way to avoid using CMakeToolchain in conan recipes?

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @saukijan

Thanks for your question.

Yes, Conan 2.0 requires at least CMake 3.15. Not only CMakeToolchain, other features from CMakeDeps too might rely on CMake 3.15. This was discussed years ago in conan-io/tribe#4, and we were even quite conservative, majority of users still wanted more modern CMake version.

If you are stuck with previous CMake versions:

• If it is because it comes in the system, the existing Conan packages for cmake will definitely help providing a modern CMake.
• If it is for some other reasons, and upgrading CMake is not possible, the recommendation would be to create your own integration and put in in a python_requires to reuse it.

[saukijan]

Thanks for the answer @memsharded, that's a real shame that no backward compatibility is available in conan. I am a bit confused about your first point. What do you mean by saying that conan packages help provide a modern cmake?

[memsharded]

that's a real shame that no backward compatibility is available in conan.

That was already discussed extensively in conan-io/tribe#4. There is no way the Conan team can provide arbitrary backwards compatibility to any arbitrary CMake version (and Meson version, and VS version, etc. etc). That would mean at the very least duplicating the maintenance effort in the generators and support. It is impossible, the resources and time are not infinite, so it is necessary to cut older versions support at some point (and CMake 3.15 is from July 2019, it is not that we are forcing the very latest CMake version).

# conan 2.0 syntax
$ conan install --tool-requires="cmake/[>3.25]" -g VirtualBuildEnv
$ conanbuild.bat  # or source conanbuild.sh
$ cmake --version
cmake version 3.25.3

And you can leverage that putting [tool_requires] in your profile or self.tool_requires() in recipes.

[saukijan]

hey @memsharded, I just tried your suggested commands on a VM with Fedora distro on it and found out that this does not work. Cmake version remains unchanged.

conan install --tool-requires="cmake/[>3.25]" -g VirtualBuildEnv outpus the expected result:

Conan Install Output

======== Input profiles ========
Profile host:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=12
os=Linux

Profile build:
[settings]
arch=x86_64
build_type=Release
compiler=gcc
compiler.cppstd=gnu17
compiler.libcxx=libstdc++11
compiler.version=12
os=Linux


======== Computing dependency graph ========
cmake/3.25.3: Not found in local cache, looking in remotes...
cmake/3.25.3: Checking remote: conancenter
Decompressing conan_export.tgz
cmake/3.25.3: Downloaded recipe revision 586c962fa58ccc886a7b2667f7c19ab9
Graph root
    cli
Build requirements
    cmake/3.25.3#586c962fa58ccc886a7b2667f7c19ab9 - Downloaded (conancenter)
Resolved version ranges
    cmake/[>3.25]: cmake/3.25.3

======== Computing necessary packages ========
Build requirements
    cmake/3.25.3#586c962fa58ccc886a7b2667f7c19ab9:63fead0844576fc02943e16909f08fcdddd6f44b#f409548eea5392efcc55b7fffb34306f - Download (conancenter)

======== Installing packages ========

-------- Downloading 1 package --------
cmake/3.25.3: Retrieving package 63fead0844576fc02943e16909f08fcdddd6f44b from remote 'conancenter' 
Downloading conanmanifest.txt
Downloading conan_package.tgz
Decompressing conan_package.tgz
cmake/3.25.3: Package installed 63fead0844576fc02943e16909f08fcdddd6f44b
cmake/3.25.3: Downloaded package revision f409548eea5392efcc55b7fffb34306f
cmake/3.25.3: Appending PATH environment variable: /home/user1/.conan2/p/cmake5b7ee79318ee9/p/bin
WARN: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN:     'env_info' used in: cmake/3.25.3

======== Finalizing install (deploy, generators) ========
cli: Writing generators to /home/user1/tmp
cli: Generator 'VirtualBuildEnv' calling 'generate()'
cli: Generating aggregated env files
cli: Generated aggregated env files: ['conanbuild.sh', 'conanrun.sh']
Install finished succesfully

First of all, the generated conanbuild.sh script does not have the correct execute permissions, so calling ./conanbuild.sh will result in:

bash: ./conanbuild.sh: Permission denied

not a big problem, simple chmod +x ./conanbuild.sh fixes that problem (for reference, original permissions were set to 644)

Second, running this script gives 0 feedback to the user, so you don't know what is happening, but looking into the script it's calling yet another script, which is supposed to update, the PATH variable to point to various bin locations, most of which are incorrect. New PATH variable content:

/home/user1/.conan2/p/cmake5b7ee79318ee9/p/bin:/home/user1/.local/bin:/home/user1/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin

I assume that this is supposed to set the path to the new cmake bin, which is installed at /home/user1/.conan2/p/cmake5b7ee79318ee9/p/bin, which is indeed set as the first part of the PATH variable, however something is terribly broken in the scripts that set it.

Running conanrun.sh script is even less helpful, because it calls a another script, which calls a for loop that has nothing to iterate over!

echo "echo Restoring environment" > "/home/user1/tmp/deactivate_conanrunenv-release-x86_64.sh"
for v in 
do
    is_defined="true"
    value=$(printenv $v) || is_defined="" || true
    if [ -n "$value" ] || [ -n "$is_defined" ]
    then
        echo export "$v='$value'" >> "/home/user1/tmp/deactivate_conanrunenv-release-x86_64.sh"
    else
        echo unset $v >> "/home/user1/tmp/deactivate_conanrunenv-release-x86_64.sh"
    fi
done

Finally, it is still not clear what am I supposed to be putting in [tool_requires] section of my profile. Conan install command? conanbuild.sh script? The new PATH variable?

It would be a lot more helpful if all of the scripts gave some user feedback, as well as the conan install command telling the user what is supposed to be done with the auto-generated scripts.

[memsharded]

bash: ./conanbuild.sh: Permission denied

You don't run the script, you source it. My instructions were to source conanbuild.sh.

I assume that this is supposed to set the path to the new cmake bin, which is installed at /home/user1/.conan2/p/cmake5b7ee79318ee9/p/bin, which is indeed set as the first part of the PATH variable, however something is terribly broken in the scripts that set it.

Sorry, it is not clear what the issue is. Did you run cmake --version and it didn't find it? What is broken?

The conanrun scripts doesn't need to be run, as I posted above only the conanbuild script is necessary for this case, as it is a build_require/tool_require.

[memsharded]

For these things, you also have a full tutorial in the docs: https://docs.conan.io/2/tutorial/consuming_packages/use_tools_as_conan_packages.html

This tutorial is hands-on, with exercises and an examples repo with code to support it.

[saukijan]

Hello @memsharded

Sorry, it is not clear what the issue is. Did you run cmake --version and it didn't find it? What is broken?

Yes, it does not find the new cmake, only the default one on my system the default one is v3.22 and the installed one is supposed to be v3.25

[memsharded]

But did you tried again with source conanbuild.sh?
Also, I have no idea why it won't work. If the new PATH clearly contains as the first element the path to the installed CMake executable, it is not very clear why this won't be used when you execute cmake --version

[saukijan]

But did you tried again with source conanbuild.sh?

I just tried it and source conanbuild.sh work, just calling the conanbuild.sh does not work. So it was just a miscommunication then. Still calling an environment definition file a script is a bit misleading and implies that you need to call it.

Either way, now I know how to do this

[memsharded]

I think the naming is correct, it must be called a shell script. Shell scripts can be sourced or executed, and they are still called shell scripts:

• https://www.baeldung.com/linux/sourcing-vs-executing-shell-script
• https://superuser.com/questions/176783/what-is-the-difference-between-executing-a-bash-script-vs-sourcing-it
• https://ss64.com/bash/source.html
  Even Microsoft calls it "sourcing the script" in their docs: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_scripts?view=powershell-7.3#script-scope-and-dot-sourcing

In fact it is very important that it is a shell script, otherwise it doesn't run. It is just the way it executes which is different, but the name is not misleading.

Thanks for the feedback and following up.