[question] Why is this project on hold until after the 2.0 release?

[hwhsu1231]

Recently, I found that Conan decided to deprecate "cmake-conan" in Conan 2.X. For example, in this article of the blog:

The biggest drawback is you need to call conan install before cmake ... This sounds innocent at first but if you rely on third party tools that support cmake you no longer have the cmake-wrapper to call conan for you. The way CMake designed the toolchain support is that it needs to be preset at configuration before the project is declared.

Conan will no longer get its settings from CMake, rather Conan will convert its settings to CMake which you will need to pass explicitly.

Therefore, I want to confirm that:

The main reason is all about the "Chicken-And-Egg" problem which @memsharded mentioned in this issue that I posted before: #410 (comment)

In any case the conan_toolchain.cmake is mostly there to try go guarantee that your CMake configuration follows the Conan settings. As the goal of cmake-conan is the opposite, to obtain the Conan settings from the current CMake configuration, that renders the conan_toolchain.cmake mostly useles, because it should largely contain what is somewhat already defined in the current CMake run.

Am I correct?

[hwhsu1231]

According to my observation, there are some other problems that cause cmake-conan "imcompatiable" with Conan 2.0. For example, conan_cmake_autodetect() "cannot" parse the correct arguments which will be passed to conan_cmake_install().

• Conan 2.0 doesn't accept values from conan_cmake_autodetect() #421

However, the biggest problem for now is the "Chicken-And-Egg (CAE)" problem, isn't it? If so, does that mean Conan Official will put more efforts on supporting and maintaining cmake-conan if someone found or proposed a method or usage that can solve this CAE problem?

After all, it seems that those other problems are not so hard to fix (just need to take some time) compared with the CAE problem.

[memsharded]

The main problem is:

• Users heavily pushed for having a "transparent" CMake integration that doesn't require to modify CMakeLists.txt at all
• That means using find_package() for dependencies and a toolchain.cmake file for configuration
• If Conan is generating the conan_toolchain.cmake file when it is called, and the toolchain file needs to be passed to CMake at invocation time only, can't be done later, then chicken-and-egg, and basically nothing can be done, besides calling conan install and then cmake, in this order
• The only alternative is assume that cmake-conan will work without the toolchain information at all, but that is a very fragile assumption that can bring problems, at the very least a bad user experience.

[hwhsu1231]

@memsharded Thanks for your reply!

And let me check whether I fully understand what you listed:

• For the 1st one, it means that the usage should be as SIMPLE as possible and had better become NON-INTRUSIVE integration with CMake.

• For the 2nd and 4th one, it means that the usage should be worked when we specify CMakeDeps and CMakeToolchain generators in our recipe SIMULTANEOUSLY. And we need to:

  • find_package the xxx-config.cmake (generaeted by CMakeDeps).
  • include the conan_toolchain.cmake (generated by CMakeToolchain) BEFORE the invocation of project() command.

• For the 3rd one, it is exactly what I mentioned above, the CAE problem.

Am I correct? And if someone can propose a METHOD that can properly tackle all these problems, will Conan Official RECONSIDER the cmake-conan?

[memsharded]

Yes, sure, let us know your ideas about this. Just in case, have a look to the repo and previous issues, for example we have considered using the initial cache conan-io/conan#12034, and it didn't move forward.

[hwhsu1231]

@memsharded

In short, my idea is to "rewrap the APIs of cmake-conan into a toolchain file", conan-setup.cmake. For usage, users just need to do the following two things:

• Prepare a conan recipe (conanfile.txt or conanfile.py) alongside with CMakeLists.txt in the root directory.
• Specify cache variable CMAKE_PROJECT_INCLUDE_BEFORE with conan-setup.cmake when running cmake command.

And then, everything will be done automatically.

I've already created a prototype. And I'm still writing the documentation and doing some tests with different compilers and cmake-level generators. So it might take a while. In terms of the usage, do you think it is simple enough? (Suppose that it satisfies all the other conditions)

[memsharded]

Not fully clear yet, so the conan-setup.cmake file will be the one calling conan install? That will result in a conan_toolchain.file. How is this toolchain file passed to cmake, via CMAKE_TOOLCHAIN_FILE variable?

Does this work for CMAKE_PROJECT_INCLUDE_BEFORE? My understanding is that this inclusion happens after the processing of the toolchain file happens, which might be a limitation?

[hwhsu1231]

I will explain the detailed mechanism when proposing the whole project. (please wait for a while)

I guarantee that it can work successfully. The following is the output log of using MSVC compilers:

Click to expand

F:\Git-Repo\cmake-project-template-conan>vcvarsall x64
**********************************************************************
** Visual Studio 2019 Developer Command Prompt v16.11.19
** Copyright (c) 2021 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

F:\Git-Repo\cmake-project-template-conan>cmake --preset win32-msvc-x64-ninja-multi
Preset CMake variables:

  CMAKE_CONAN_ERROR_QUIET:BOOL="TRUE"
  CMAKE_CONAN_OUTPUT_QUIET:BOOL="TRUE"
  CMAKE_CONFIGURATION_TYPES="Debug;Release"
  CMAKE_CXX_COMPILER="cl.exe"
  CMAKE_C_COMPILER="cl.exe"
  CMAKE_INSTALL_PREFIX:PATH="F:/Git-Repo/cmake-project-template-conan/install/win32-msvc-x64-ninja-multi"
  CMAKE_PROJECT_INCLUDE_BEFORE="F:/Git-Repo/cmake-project-template-conan/cmake/conan-setup.cmake"

-- Using Conan toolchain: F:/Git-Repo/cmake-project-template-conan/build/win32-msvc-x64-ninja-multi/conan-dependencies/conan_toolchain.cmake
-- The C compiler identification is MSVC 19.29.30146.0
-- The CXX compiler identification is MSVC 19.29.30146.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
========== cmake-project-template-conan ==========
-- Conan: Component target declared 'fmt::fmt'
-- Conan: Target declared 'asio::asio'
-- Conan: Target declared 'CLI11::CLI11'
-- Conan: Component target declared 'Eigen3::Eigen'
-- Conan: Component target declared 'libpqxx::pqxx'
-- Conan: Component target declared 'libpq::pgcommon'
-- Conan: Component target declared 'libpq::pgport'
-- Conan: Component target declared 'libpq::pq'
-- Conan: Target declared 'PostgreSQL::PostgreSQL'
-- Conan: Component target declared 'CURL::libcurl'
-- Conan: Component target declared 'OpenSSL::Crypto'
-- Conan: Component target declared 'OpenSSL::SSL'
-- Conan: Target declared 'openssl::openssl'
-- Conan: Including build module from 'D:/.conan/short/d461c0/1/lib/cmake/conan-official-openssl-variables.cmake'
-- Conan: Target declared 'ZLIB::ZLIB'
-- Configuring done
-- Generating done
-- Build files have been written to: F:/Git-Repo/cmake-project-template-conan/build/win32-msvc-x64-ninja-multi

As we can see in the above log message, there are -- Using Conan toolchain: and -- Conan: Target dechlared messages. That is, it indeed includes conan_toolchain.cmake before the project() command and find_packages xxx-config.cmake.

For now, I just want to confirm whether the usage method of my idea is simple enough?

For usage, users just need to do the following two things:

• Prepare a conan recipe (conanfile.txt or conanfile.py) alongside with CMakeLists.txt in the root directory.
• Specify cache variable CMAKE_PROJECT_INCLUDE_BEFORE with conan-setup.cmake when running cmake command.

[memsharded]

Yes, it is looking good for me. Lets see what @czoido and @jcar87 think too.

Transferring this issue to cmake-conan repo, this is something to implement there, I don't think this require changes in the Conan client only in the cmake-conan integration

[Talkless]

That means using find_package() for dependencies and a toolchain.cmake file for configuration

If this gonna be the ONLY way in 2.0 to consume Conan packages, I see it a rather show stopper.

For non-opensource project at work I don't care about "transparency", and since my usages is mainly via QtCreator IDE, keeping convenience of use (that QtCreator + cmake-conan provides) has rather high priority.

For example, if I use cmake-conan, I can:

1. Open CMakeLists.txt with QtCreator, as any other "Project" in any other IDE.
2. Switch to whatever Qt Kit (Desktop, Android,..) I need.
3. Choose Release or Debug or Whatever configuration I need.
4. Just invoke "Build" and conan install is invoked automatically by cmake-conan.

Now, if on Conan 2.0 toolchain generator will be the only way, I will have to make helper scripts like conna_install_desktop_release.sh, conan_install_android_debug.sh, ..., and run them before launching QtCreator and changing Kit and Debug/Release configuration? Will have to hard-code QtCreators "shadow build" automatically-created directories which change depending on used Qt Kit / configuration so that conan install will place required files where needed?

Though maybe I am missing something and over-reacting?

I believe there was some work in QtCreator, Qt itself to make it work better with Conan. @memsharded are you aware of any of that?

[SuTanTank]

In my practice, I only use conan-cmake with CMakeDeps generator to generate xxx-config.cmake files and then add the output directory to CMAKE_PREFIX_PATH. The build configurations inside the toolchain is good, but not that useful for an already-exist CMake project - many of them have their own cmake options to handle build configs on different platforms and even some already has their own toolchains.

Besides, almost all the modern C++ IDEs like CLion, VS 2022, Android Studio, have built-in CMake support, which makes it very inconvenient to manually call conan install with these IDEs cmake workflow.

Another inconvenience is submodule. When a project is consumed as a submodule and add_subdirectory(). conan-cmake works normally and the parent project doesn't need to care about calling conan install as long as conan is installed in the environment, but now the inner project maintainer needs to tell the user: don't use submodule, or call conan install and do a long list of things to adapt to conan and even start to learn how conan works. In the worst case, one needs to introduce conan to all the dev teams in the company and make them use it - it's really difficult.

[Nekto89]

I don't really understand how I will be able to use conan without being able to call it multiple times during CMake generation. In my workflow input for conan is generated dynamically based on what libraries from project have been enabled (there are more than 600 targets). Also some options might be changed dynamically based on CMake variables. All this logic is hidden under many layers of CMake. And it becomes even more complex with more added layers on top of this project that also allow to choose what part should be enabled.