[question] Why is this project on hold until after the 2.0 release?See original GitHub issue
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
cmake ... This sounds innocent at first but if you rely on third party tools that support cmake you no longer have the
cmake-wrapperto 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: https://github.com/conan-io/cmake-conan/issues/410#issuecomment-1095611994
In any case the
conan_toolchain.cmakeis 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.cmakemostly useles, because it should largely contain what is somewhat already defined in the current CMake run.
Am I correct?
- Created 5 months ago
- Comments:26 (16 by maintainers)
Top GitHub Comments
In my practice, I only use
conan-cmakewith 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 installwith these IDEs cmake workflow.
Another inconvenience is submodule. When a project is consumed as a submodule and
conan-cmakeworks normally and the parent project doesn’t need to care about calling
conan installas 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 installand 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.
Sorry for more of topic but the design Conan 2.0 is a beautiful thing!
Gives me a CMakeLists.txt that have no idea that Conan exists.
And the conanfile.py if short and sweet!
It’s a beautiful thing!
Thanks for your hard work!