[question] best practice for 1.x and 2.x compatibility?

[jiggersplat]

What is your question?

I have machines that have 1.62 installed and cannot easily be upgraded to 2.x for various reasons. I'm using CMake to build. What's are the best practices/recommendations for such a scenario?

On my 1.x builds I use conan_basic_setup() and target_link_libraries(myapp PRIVATE ${CONAN_LIBS}) to link. 2.x doesn't like that and doesn't seem to use this model as far as I can tell and wants me to just use find_package and link it as though it was a system installed library. The other problem is just the syntax in conanfile.txt/conanfile.py, the imports are different, the generator names are different, some of the function names are different.

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @jiggersplat

Thanks for your question.

I have machines that have 1.62 installed and cannot easily be upgraded to 2.x for various reasons. I'm using CMake to build. What's are the best practices/recommendations for such a scenario?

The first important bit is that it is not necessary to use Conan 2.X for most of the upgrade effort, most of the migration effort can be done while in Conan 1.X. Some important points:

• Use always revisions-enabled feature. Always, in all machines.
• Start using the 2 profiles approach, with --profile:build=myprofile-build --profile:host=myprofile-host. This changes how the tool-requires are evaluated and propagated
• Move to the new integrations, like CMakeDeps and CMakeToolchain generators instead of the legacy cmake, cmake_find_package, etc.

Finally use the migration guide in https://docs.conan.io/1/conan_v2.html, to finish the upgrade of the recipes.

to link. 2.x doesn't like that and doesn't seem to use this model as far as I can tell and wants me to just use find_package and link it as though it was a system installed library

Yes, the new build system integrations like CMakeDeps were developed to supersede the previous ones you were using, by massive popular demand, because they require zero modifications to the user CMakeLists.txt, that can use standard CMake functions without any reference to Conan at all, what is called the "transparent integration". These new build system integrations have been around for years now in Conan 1.X (they are the used ones in Conan 2, which is already 18 months old).

[memsharded]

Hi @jiggersplat

Any further question here? Thanks for the feedback.

[jiggersplat]

I was able to get the behavior I want for the most part using a separate conanfile.py for 1.x and 2.x installations, doing some version checking in CMake, using the conandeps_legacy.cmake and aliasing CONAN_LIBS to ${CONANDEPS_LEGACY}.

[memsharded]

Thanks for the feedback

I was able to get the behavior I want for the most part using a separate conanfile.py for 1.x and 2.x installations, doing some version checking in CMake, using the conandeps_legacy.cmake and aliasing CONAN_LIBS to ${CONANDEPS_LEGACY}.

In general we recommend to have common conanfile.py for both Conan 1.X and 2.0, so they will generate the same revisions and they can be uploaded to the same server repositories. If you have different recipes, then please take into account that you will also need different server repos.

If there is no further question, I think we can close this by now. Please don't hesitate to create new tickets for any further question or issues that you might have. Many thanks for your feedback!