Option to use different profile packages in one conan package

[dpatchi]

Hello All,

We have a scenario to use different packages generated by different profiles in requriments/build_requriments of conan reciepe.
This is because if the libs are compiled with lower version of gcc will be compatible with higer version of gcc too.

Ex:
Product A has dependency on B and C modules - ultimate goal to build product A with profile settings compiler.version=9.5 and os=linux64.
We have package for B module with same profile settings. but we dont have package for module C with same settings. Instead C module package has profiles settings compiler.version = 9.2 and we know it Package C with compiler version 9.2 will work on 9.5.

For the above scenario, how can we consume C module package in product A Conan recipe ?

I do understand that, although we are using some profile while creating package_Id i can remove one particular settings, if i do that the same package doesn't work on lower compiler.

Could you please help suggesting good approach to handle this scenario ?

Thank you

[memsharded]

Hi @dpatchi

Thanks for your question.
I think there are some possible different approaches to your case:

• Explicitly define what you want in profiles. Lets say that you are building A with gcc11, but you want to use the binary for B that was built with gcc10 and the binary for C that was built with gcc9. You can do:

[settings]
compiler = gcc
compiler.version = 11
pkgb/*: compiler.version=10
pkgc/*: compiler.version = 9

This approach is robust, simple, very explicit, with total control on your side

• Use the compatibility.py plugin to define rules for automatic binary compatibility for all packages. Please check the docs in: https://docs.conan.io/2/reference/extensions/binary_compatibility.html

Please let me know if this helps

[dpatchi]

Hello James,

Thank you for your quick response. In fact, i have couple of follow up queries. Please help.

Regarding your option 1 : We are using common profiles across around 100+ projects to maintain commonality. We feel updating common profile for few packages might not be good idea - hence if we have any option at consumer side will be really good - Do we have any such option ?

Regarding your option 2: Based on my understanding this is present in 2.0 only. Currently we are using 1.0 and working on logistics for 2.0(jfrog artifactory). Do we have any such in 1.0 ?

Thank you

[memsharded]

Regarding your option 1 : We are using common profiles across around 100+ projects to maintain commonality. We feel updating common profile for few packages might not be good idea - hence if we have any option at consumer side will be really good - Do we have any such option ?

I am not sure what you mean. The profiles are consumer side. Profiles have many features to manage reuse and flexibility like:

• Profiles can include() other profiles
• Profiles can be composed on the command line, just by passing multiple -pr=profile1 -pr=profile2 arguments
• Profiles have jinja template rendering, so they can have variables, control structures, conditionals to the os and platform, etc.

Regarding your option 2: Based on my understanding this is present in 2.0 only. Currently we are using 1.0 and working on logistics for 2.0(jfrog artifactory). Do we have any such in 1.0 ?

No, the compatibility plugin is only in Conan 2.0. You might try to use the compatibility() method in recipes in Conan 1.X, reusing it from a common python_requires to avoid too much repetition. Not sure if it is worth, probably the profiles approach is easier to implement for your use case.

[dpatchi]

Hello James,

My point here is instead of updating the profiles, can we make some changes/settings in consumer side to look for different settings ?

Lets say I am building product A -> dependens on component B and C.
When i tried to do Conan install with compiler.version 9.5 with a profile settings compiler gcc and compiler.version 9.5
I dont want to use compiler.version 9.5 of component C. I wanted to explicitly mention that for component C, i need settings of compiler version 9.2 and for rest others I need only package of compiler version 9.5.

At the same, we have another product Z -> depends on components B and C. Here in this case, we use both 9.5 packages.

For all products we use common profiles -> hence I prefer not to change anything in common profiles.

I hope i am clear ! Could you please suggest your opinion ?

[memsharded]

For all products we use common profiles -> hence I prefer not to change anything in common profiles.

You can still have your common profiles like this:

This is the common profile:

[settings]
compiler = gcc
compiler.version = 9.5

You can use it for product Z, as -pr=common

Then you can have a specific complement to define the logic for product A:

This is the productA profile:

[settings]
pkgc/*: compiler.version = 9.2

Then you can use it for product A as -pr=common -pr=productA
You can of course also do:

include(common)
[settings]
pkgc/*: compiler.version = 9.2

Then you can use it for product A as -pr=productA

This way:

• You have the common profiles specification, fully reusable and common. You don't need to change anything in common profiles.
• This is fully specified in the consumer side
• For the products that require some specific combination of settings for dependencies, you define the specific combination in product> profile, reusing the common profiles

If you want to, you can easily locate the productA profile in the same folder as the conanfile for productA, to make it evident and easy its usage, maybe that is what you are looking for? It is not mandatory to have profiles in the cache folder shared with everyone, you can also have profiles in your consumer productA repo.

Please let me know if this clarifies it a bit more. Thanks!