[develop2] My migration experience from conan.cmake to conan_provider.cmake

[tbeu]

I did not succeed when trying to work on my technical dept to migrate from Conan 1.x to 2.x. Here's what I did:

• The example in the develop2 branch only mentions a conanfile.txt based variant, but I need dependencies optionally, so I went for https://github.com/ImmanuelO/cmake_template/tree/use-conan-2.0 where a minimal example using conanfile.py is provided.
• I adapted the CMake configuration as follows: tbeu/matio@master...migrate_to_conan_2
• I wondered if it is actually necessary to increase the minimal CMake version from 3.7 to 3.24 (since Conan 2 based dependency resolution is an optional configuration)
• I wondered where I need to set the new conan remote https://center2.conan.io since conan_add_remoteno longer is availabe via CMake.
• CI fails with me no having idea, why: https://github.com/tbeu/matio/actions/runs/11996918997/job/33441929160

Thanks for your support! Any advice is appreciated.

[memsharded]

Hi again @tbeu

Thanks for your feedback.

The example in the develop2 branch only mentions a conanfile.txt based variant, but I need dependencies optionally, so I went for https://github.com/ImmanuelO/cmake_template/tree/use-conan-2.0 where a minimal example using conanfile.py is provided.

Looks good, totally valid.

set(CMAKE_PROJECT_TOP_LEVEL_INCLUDES "cmake/conan_provider.cmake")

This is not possible. Specially, doing this after project() is incorrect. Dependency providers need to be defined by command line arguments, the recommended way for this would be using CMake presets, very convenient.

I wondered if it is actually necessary to increase the minimal CMake version from 3.7 to 3.24 (since Conan 2 based dependency resolution is an optional configuration)

yes, CMake dependency providers only exist in modern CMake>=3.24, update is necessary to work

I wondered where I need to set the new conan remote https://center2.conan.io/ since conan_add_remoteno longer is availabe via CMake.

This is not really necessary for new Conan installations, installing latest Conan will already define the right remote. For existing installations, the recommended approach is to do the conan remote update directly in command line or CI, not from CMake.

CI fails with me no having idea, why: https://github.com/tbeu/matio/actions/runs/11996918997/job/33441929160

I think it is because the incorrect injection of the dependency provider. If the provider is correctly injected you should see all the conan install messages in the output.

Please let us know how it goes.

[tbeu]

Thanks @memsharded for the fast reply. I now understand that cmake-conan for Conan 2.X approach is completely orthogonal to Conan 1.X dependency resolution.

I adapted tbeu/matio@master...migrate_to_conan_2 accordingly to still keep Conan 1.X approach alive, but marked as deprecated.

I needed to downgrade minimum CMake version requirement again, since OpenBSD VM only has CMake 3.21 installed and I cannot force it as a hard requirement just for one possible way of dependency resolution.

Basically, it is working as expected, however only the default options are used. If I set -DMATIO_ENABLE_CPPCHECK=ON (or any other non-default CMake option) it does not work. How can I force that CMake defines take precedence over Conan default options? I tried to find documentation, open issues, closed issues like #666 (comment) or AI assistant, but failed to figure out.

Thanks again.

[tbeu]

Edit: By providing a profile file via -DCONAN_HOST_PROFILE I was able to overwrite the Conan default options, see https://github.com/tbeu/matio/actions/runs/12038724576/job/33565013263

However, find_program(CPPCHECK cppcheck) fails, even if the tool requirement was correctly resolved by Conan 2.X as cppcheck/2.16.0.

[memsharded]

Thanks for the feedback.

However, find_program(CPPCHECK cppcheck) fails, even if the tool requirement was correctly resolved by Conan 2.X as cppcheck/2.16.0.

Yes, this is expected at the moment (though we are working to improve this).

The thing is that tool_requires containing programs to execute are injected via environment activation, previous to CMake running. So when a recipe does cmake.configure(), that would inject the PATH environment variable including the tool_requires like cppcheck, so the find_program() might find it in the PATH. And also the conan_toolchain.cmake generated by CMakeToolchain does contain CMAKE_PROGRAM_PATH definitions to find these executables.

So when running from cmake all of this cannot happen. Because the moment conan install executes and bring dependencies, it is already late to pass the conan_toolchain.cmake.

We are doing a completely new CMakeDeps, that generates a new file that might be injected by cmake-conan to overcome this limitation. It got released already in COnan 2.9 as dev-testing (need a -c tools.cmake.cmakedeps:new=will_break_next to activate it, but support for CMAKE_PROGRAM_PATH is still not there, will be in Conan 2.10, and then cmake-conan will need to adopt the new file.

[tbeu]

Thanks for clarification of the limitation. I guess I need to revisit the migration once Conan 2.10 is released and cmake-conan adopted to the new injection.

Feel free to close this issue then.

Thanks again!

[memsharded]

Just an update that the new CMakeDeps is now in the 2.10 release in "incubating" stage, see https://docs.conan.io/2/incubating.html.

We will be testing it here in cmake-conan soon.

I am keeping this ticket open until this works with the new generator, thanks for the feedback!