Conan: [question] Private dependencies won't let CMake generator output CONAN_PKG:: variables. Bug or wanted behavior?

[jegabe]

Hello all,

I have the following problem: I want to create a shared library that's fully self-contained and acts as a plug-in. Let's call this shared libary "L". L has some dependencies to header-only and static libraries (lets' call them A and B) that are fully linked into L:

L depends on A
L depends on B

Since A and B are fully linked into the shared library and aren't visible from outside, I don't want my clients that use "L" to get transitive dependencies into A and B because they're hidden.

Now, I have a client (let's call him C) that wants to have a dependency to L. To avoid transitive dependencies, I required "A" and "B" inside the conanfile.py of "L" as "private":

conanfile.py of component "L":
requires = [("A/version@user/channel", "private"), ("B/version@user/channel", "private")]
generators = "cmake"

I use the CMake generator to build "L" and use modern CMake syntax. When I add the "private" for the dependencies "A" and "B", the variables "CONAN_PKG::A" and "CONAN_PKG::B" aren't created any more. But I need them so the targets for "L" can have a target_link_libraries(target CONAN_PKG::A CONAN_PKG::B)

Is this a bug or wanted behavior? If it is wanted: How should I design the L dependencies? If it's a bug: How can I work-around that issue (Only known work-around by me is to use build_requires with force_host_context=True)

[Carsten87]

I think this is related to my question #8480

[danimtb]

I think this is related to my question #8480

Indeed, thanks a lot for the link.

@jegabe yes, this was the use case for private requirements but the current implementation is a bit buggy at some points and we try not to encourage their use. Maybe something like adding --build=L flag makes the trick for the target if you already have A and B in the cache.

This is something we want to model better in the graph in order to have a similar scheme to the one used by CMake, but we will need to wait for Conan 2.0. Also you can check the solution provided at #8480 as well.

[SpaceIm]

I've recently created a recipe in CCI which relies on a private dependency, cmake generator and CONAN_PKG targets:
https://github.com/conan-io/conan-center-index/blob/9f31fd518de2ef8454136aa4cda1ae16b046b14e/recipes/vulkan-validationlayers/all/conanfile.py#L53
https://github.com/conan-io/conan-center-index/blob/9f31fd518de2ef8454136aa4cda1ae16b046b14e/recipes/vulkan-validationlayers/all/CMakeLists.txt#L11

It works as expected in this case.

[jegabe]

Hello @SpaceIm, did you use separate host and build profiles with your conanfile.py? That's when the problem arises in our build because we do cross-compiling (embedded)

[jegabe]

@danimtb: If usage of "private" dependency is broken, should it then be documented that usage of that should be avoided? The solution provided in #8480 works partially for our company: The linking problem disappears, but the client consuming "L" still gets version conflicts if he needs either A or B in another version that "L" needed. So basically, I need to completely hide that dependency: The dependency is implementation detail of "L". Would you recommend to use build_requires with force_host_context=True in that case? That would work because then, after building "L", the dependencies to "A" and "B" disappear. It would be really great if that could be fixed in conan 2.0 because in a plug-in based system, as we create it now, we intentionally want to "break" transitive dependencies by using shared libraries and make them self-contained (to hide all further dependencies and have the same transitive components linked in different versions by different shared libs)

[Carsten87]

I have pretty much the same issue and am also looking forward to a proper solution.

The problem I see with the "build_requires approach" is that your requirement is no longer part of the dependency graph of your product. So you lose the ability to trace what is being delivered as part of the product which could for example be problematic if you would like to collect all licenses automatically or if you need to provide a list of third party components to someone.