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

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: https://github.com/conan-io/cmake-conan/issues/410#issuecomment-1095611994

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?

[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.

[marcus-free]

Sorry for more of topic but the design Conan 2.0 is a beautiful thing!

f = os.path.join(self.package_folder, "stm32_gcc.cmake")
self.conf_info.define("tools.cmake.cmaketoolchain:user_toolchain", [f])

and

cmake = CMakeDeps(self)
cmake.build_context_activated = ["gcc-arm-none-eabi"]
cmake.generate()

tc = CMakeToolchain(self,"Ninja")
tc.cache_variables["STM32_TARGET_TRIPLET"] = "arm-none-eabi"
tc.cache_variables["STM32_CUBE_G0_PATH"] = self.dependencies.host["stm32-cube-g0"].package_folder
tc.cache_variables["STM32_TOOLCHAIN_PATH"] = os.path.join(self.dependencies.build["gcc-arm-none-eabi"].package_folder,"bin")
tc.generate()

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!