[develop2] Variable "CONAN_<PackageName>_ROOT" not set anymore

[jacobalexis]

Greetings :)
For the migration of a C++ project from Conan 1.X to Conan 2.0, I was considering the latest version of Conan_cmake on develop2. Here is the issue that I am facing currently:

So far, we actually use several macros to keep track of each library folder, including 3rd parties That use case was satisfied by variable CONAN_<PackageName>_ROOT, which was set by calling conan_cmake_run if I understand it correctly.

The new behavior gets rid of any conan function call in the project itself. Can there still be a way to fetch the path of each library folder that is called by the conan install? What would you advise?

Many thanks in advance for your answer,
Alexis Jacob

[memsharded]

Hi @jacobalexis

Thanks for your report.
I have checked it, the old conan.cmake for Conan 1.X didn't set any _ROOT variables. This was part of the migration of the legacy cmake and cmake_find_package generators to the new CMakeDeps one. The new one is using a pure find_package() approach, that doesn't need any _ROOT variables defined.

So maybe we should move the issue to the conan repo? The idea is that you should move first the recipes to be Conan 2.0 compatible, with the latest Conan 1.X and using the modern generators.

[jacobalexis]

I understand, thanks for your quick answer.

So maybe we should move the issue to the conan repo? The idea is that you should move first the recipes to be Conan 2.0 compatible, with the latest Conan 1.X and using the modern generators.

We are in the process of migrating our libs from Conan 1.X to Conan 2.0 but some Conan 2.0 libs from conancenter do not seem to have been migrated, as they are raising warnings, cf below:

WARN: deprecated: Usage of deprecated Conan 1.X features that will be removed in Conan 2.X:
WARN: deprecated:     'user_info' used in: boost/1.82.0

Do we need to move those recipes to be Conan 2.0 compatible as well, temporarily within our own private conan center?