[question] Granularity of new requires traits vs components

[SpaceIm]

What is your question?

How conan v2 will handle fine-grained components type regarding transitive_libs/transitive_headers/run etc?

For example:

recipeA has 1 library libA, either shared or static depending on shared option

recipeB has 2 component libB1 & libB2:

• libB1: either shared or static depending on shared option
• libB2: always static, and libA is a private dependency of libB2

So we would write something like this in recipeB:

def requirements(self):
    self.requires("recipeA/x.y.y")

def package_info(self):
    self.cpp_info.components["libB1"].libs = ["B1"]
    self.cpp_info.components["libB2"].libs = ["B2"]
    self.cpp_info.components["libB2"].requires = ["recipeA::recipeA"]

How conan knows that for recipeB, deps like generators must take into account that libA must always be propagated to link flags of libB imported target (in case of CMakeDeps, but it's the same problem for other deps like generators) even when shared option of recipeB is True (since libB2 component is always static)? I have the feeling that it's not as powerful as CMake PRIVATE/PUBLIC/INTERFACE mechanism per target, but maybe I'm missing something.

Have you read the CONTRIBUTING guide?

• [x] I've read the CONTRIBUTING guide

[memsharded]

Hi @SpaceIm

Conan 2.0 requirements traits are per-package, not per component. Users need to use the traits that better model the behavior of the whole package with all its components included. If users want leverage better the traits feature and their components are not a good fit, they would need to separate the components into different packages, or manually handle the different components characteristics.

The model you are proposing in your example doesn't hold. You cannot have a shared option for a package that contains components that will not follow such option. The components should be homogeneous components, and differ in the functionality, but not in the library format, flags, build, artifact or things like that. They were never designed to have the equivalent functionality of a full fledged package, and Conan is still a package manager, not a build system.

If they are weird cases, the best approach would be to do not define shared option, and not define package_type, and handle manually all the traits, the package_id, and it will require some work at the build system level.

[SpaceIm]

I think this recipe is a good example: https://github.com/conan-io/conan-center-index/pull/16239#issuecomment-1464034621

Some libraries of aaf are built either shared or static, but some others are always shared, so on Windows bindirs must be propagated to PATH regardless of shared option, but in test package VirtualRunEnv doesn't define PATH if shared=False (and obviously it shouldn't be the responsibility of downstream to add run=True in self.requires, it's an internal recipe detail).