Is it possible to install two packages with different build types

[nesc1]

Hello, i'm trying to install in my cmake project two conan package dependencies, one (A) that is a normal library and other (B) that is a package that exports binaries.

The first one (A) i want that the build type to be equal to the one specified by the client, and the one that exports binaries (B) I want that build_type is always in Release mode.

How can i acomplish this for my cmake project?

And if these two packages, A and B, both requires another dependency C, can we manage these also?

Thanks

[Johnnyxy]

It is possible.
You have to use conan profiles for that.
If you do not specify anything all settings will be shared with all dependencies. With profiles you can specify settings for any dependency.

I am doing exactly this as I have a thrid party lib that contains only Release and Debug libs. But to use the dependency with RelWithDebInfo I have to set the build_type for this specific dependency to Release.

profile example

...
[settings]
NAME_OF_B:build_type=Release
...

commands examples

conan install ... --profile="PATH_TO_YOUR_PROFILE_WITH_FILENAME"

conan create ... --profile="PATH_TO_YOUR_PROFILE_WITH_FILENAME"

[nesc1]

yes you are right @Johnnyxy thanks for the hint.

And how do you manage if both packages A and B depend on the same C library. I wanted also that A (debug) links with C (debug) and B (Release) links with C (Release)... how do you manage this? or what is the best way to manage this?

[Johnnyxy]

Generally this is not recommended that you link the same library twice in different flavours.

Under really rare circumstances you can do something like that if C-lib is compiled as shared library (.dll, .so) and has a pure C interface with the same function prototypes, macros (if you use any), etc. (API) for Debug and Release, it would be possible if C-Debug and C-Release have different filenames. But this is definitely a bad idea. As this would imply further constraints on A and B. Like C is not allowed to be in the link interface of A and B. ... ... etc ... etc...

I strongly advise you against doing something like that. In the history of C/C++ this led to much pain and many hours of bug hunting.

Can you elaborate the scenario a little bit more?
Over which code do you have control? (A, B, C)
What type of compilation are your A, B, C? (static libs .lib, .a; dynamic libs .dll, .so)
How are A and B related to C? Do they link them privately or is C part of the public API of A or B?

...

[nesc1]

Hi @Johnnyxy , i basically put all the dependencies of the package that i require to be built in a specific build type private and i think this acomplish what i want, the only strange thing is that when i also use override with private both =True then in linux the requirements does not happear, is like no requirement exist for the package (in windows all is ok...)

Best Regards,
Nuno

[jgsogo]

Hi, @nesc1.

There is a problem with the override argument in requirements that might not be well explained in the documentation: it is not possible to use override=True and add the library as a dependency at the same time.

At this moment this is not a big issue, as a normal require will also override upstream dependencies to use the same version, but in the future (v1.14) once merged #4771, it will be necessary in order to declare for a requirement both behaviors: explicit override and dependency (it is an open issue here: #4779).

It should behave the same on windows and linux, so I would ask you to double check what you commented and open an issue/bug if it works different for different architectures.

Thanks!

[jgsogo]

I'm closing this issue, I think the question is more or less exhausted, but feel free to open it again if you want to add something.

Thanks!