[question] PUBLIC / PRIVATE Link Libraries Separation

[lucabonifacio]

Let's take following simplified example:

find_package(Boost REQUIRED)
find_package(OpenSSL REQUIRED)

add_library(Foo)

target_link_libraries(${PROJECT_NAME}
    PUBLIC
        Boost::Boost
    PRIVATE
        OpenSSL::OpenSSL
)

#...
include(CMakePackageConfigHelpers)
configure_package_config_file(...)
install(...)

Now, let's assume we want to consume Foo:

find_package(Foo REQUIRED)

add_executable(App)

target_link_libraries(${PROJECT_NAME}
    PRIVATE
        Foo::Foo
)

Now, having OpenSSL defined as a private dependency of Foo means that App can link against it, but cannot include any API of it. Instead, in case of Boost, App can use it within the application.

CMake, when generating the Package Configuration Files, uses $<LINK_ONLY:...> to specify private link dependencies without other usage requirements.

My question is, how can I describe the PUBLIC / PRIVATE separation within package_info()?

• [x] I've read the CONTRIBUTING guide.

[memsharded]

Hi @lucabonifacio

at the moment (Conan 1.X), all requires are by default public, and linkage requirements are propagated to the consumers. This is because Conan graph model has requires and build_requires```, but there is nothing insiderequires`` that allows to define the visibility of the transitive requirements.

Conan 2.0 introduces a new model that does exactly this. Check this Tribe 2.0 proposal: https://github.com/conan-io/tribe/pull/26

[memsharded]

In Conan 1.X there are 2 alternatives:

• Just let the transitive dependencies propagate. In many cases it is not a big issue, and linker optimizes away not needed libs
• If necessary to remove those propagated dependencies, filter them out in the CMakeLists. This is not very straightforward, and not very elegant, but is doable.

[lucabonifacio]

Hi @memsharded

Are there already some release date for Conan 2.0?

[memsharded]

Not for final release. We are entering now (today) in alpha stage, check the https://github.com/conan-io/conan/releases. There will be a few months in alpha and a few months in beta.

[dornbirndevelops]

Hi @memsharded ! after a short debugging session within the package_info() method of a recipe, I saw that a yet undocumented property self.cpp_info.public_deps is available for manipulation. setting it in my example from the original value ['boost'] to [] causes the public dependency to disappear from the user package include paths unless the dependency is directly required. Is the manipulation of this public_deps an unintentional feature, or is it safe to use for this purpose?

[memsharded]

Hi @dornbirndevelops

Please don't use undocumented things in your recipe code, those will easily break, and if you do it, it is at your own risk. Specifically this one has already been removed in the new model, it will not exist via the self.dependencies model