how to implement conan_cmake_configure in conan 2.0

[laxmij-cmd]

What is your question?

Hi,

I have to start using conan 2.0. In conan 1.x, I am using conan_cmake_configure to generate conanfile.txt . How can I achieve this in conan2.0

Best Regards
Laxmi

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Moving this to the cmake-conan repo, as this is not a Conan question, but related to cmake-conan

[memsharded]

Thanks for your question @laxmij-cmd

I have to start using conan 2.0. In conan 1.x, I am using conan_cmake_configure to generate conanfile.txt . How can I achieve this in conan2.0

In Conan 2.0 integration we have moved to a more explicit approach, that works better in many cases, and that implements a fully transparent integration, that is, it is not necessary to modify at all your CMakeLists.txt, no need to add anything at all. This is achieved by:

• Declaring your dependencies in a conanfile (can be conanfile.py or conanfile.txt)
• Using the conan_provider.cmake and passing it via command line (not including it from CMakeLists.txt

[Nekto89]

Thanks for your question @laxmij-cmd

I have to start using conan 2.0. In conan 1.x, I am using conan_cmake_configure to generate conanfile.txt . How can I achieve this in conan2.0

In Conan 2.0 integration we have moved to a more explicit approach, that works better in many cases, and that implements a fully transparent integration, that is, it is not necessary to modify at all your CMakeLists.txt, no need to add anything at all. This is achieved by:

* Declaring your dependencies in a `conanfile` (can be conanfile.py or conanfile.txt)

* Using the `conan_provider.cmake` and passing it via command line (not including it from `CMakeLists.txt`

Are there any plans to allow old workflow? Maybe add some additional separate functions that will create temporary conanfile.py from input parameters and call conan install.

[memsharded]

No there are no plans for this. Because that means having CMakeLists.txt to basically generate a conanfile.txt on the fly. If you want to to do it, you can do something like:

file(WRITE conanfile.txt "[requires]\nzlib/1.2.13")

in your CMakeLists.txt, no need anymore to use an invented helper to just write that file to disk, while cluttering the CMakeLists.txt.

The call to conan install now will already happen when the first find_package() is found. No need to call it explictly from the CMakeLists.txt either, that is the advantage of using the new CMake dependency providers, now it can be fully transparent.

[pwuertz]

My workflow was also centered around conan_cmake_configure from cmake-conan 1.x.

A common pattern in larger CMake projects is to define -DWITH_XY options for enabling/disabling certain features within a build. Sometimes enabling such features causes a project to conditionally depend on a specific 3rdparty dependency you wouldn't want to deal with otherwise.

Conditionally adding REQUIRES XY to conan_cmake_configure was straight forward, but now it seems like there is no way of getting something like this to work with conan2 at all?

[laxmij-cmd]

To use cmake-conan, -DCMAKE_PROJECT_TOP_LEVEL_INCLUDES=/conan_provider.cmake is needed to be passed along in cmake command.
My users, while migrating to conan 2.0, don't want to provide this extra parameter.
One way to achieve above is to modify conan_provider.cmake. Is there any other way?

[metalMajor]

I must say I agree, it would be nice that you can contain all logic in a cmakelists.txt file instead of moving it outside. For example, we use conan for "desktop" dependencies, and the same project can be compiled as "embedded", depending on a cmake option(). In that embedded case we have a yocto toolchain with all required dependencies for which we don't need to use conan. So now people will need to remember that if they open it for desktop that they should give a specific commandline parameter.

[memsharded]

So now people will need to remember that if they open it for desktop that they should give a specific commandline parameter.

Sure, the modern CMake recommended (by CMake) way to achieve this is using cmake --preset, and the preset files define the CMAKE_PROJECT_TOP_LEVEL_INCLUDES internally, so the developers don't need to pass it manually, and this works the same in all platforms as well.

[metalMajor]

ok thanks for the pointer to cmake presets, did not know it 👍