[question] CppInfo object when using components
What is your question?
Hi
When defining package layout, the cpp_info object is getting some default values (unless overridden). for example:
def package_info(self):
self.cpp_info.bindirs = ['bin']
self.cpp_info.libdirs = ['lib']
self.cpp_info.includedirs = ['include']
now, let's assume that we have components package, and assume that we have different layout for each component:
def package_info(self):
self.cpp_info.components['x'].bindirs = ['bin/x']
self.cpp_info.components['x'].libdirs = ['lib/x']
self.cpp_info.components['x'].includedirs = ['include/x']
self.cpp_info.components['x'].bindirs = ['bin/y']
self.cpp_info.components['x'].libdirs = ['lib/y']
self.cpp_info.components['x'].includedirs = ['include/y']
we will still get the defaults for the cpp_info.bindirs / cpp_info.libdirs / cpp_info.includedirs, I think when a component is being declared, the default values should be removed and set by the aggregation of the components data.
I can see at least 2 use cases when it's required:
- when using deployers, and we want to copy all bins to deployment folder, we would not want to distinguish between components package or single library package.
- when linking to the entire package - for example in cmake
target_link_directories(MyTarget PRIVATE SomeSdk::SomeSdk)
What do you think?
Have you read the CONTRIBUTING guide?
- [ ] I've read the CONTRIBUTING guide
Hi @mikirothman
Sorry this was not responded back then.
we will still get the defaults for the cpp_info.bindirs / cpp_info.libdirs / cpp_info.includedirs, I think when a component is being declared, the default values should be removed and set by the aggregation of the components data.
This is the default behavior. When components are defined, the "global" cpp_info.libdirs/bindirs/etc are ignored, not used at all (they shouldn't be defined)
when using deployers, and we want to copy all bins to deployment folder, we would not want to distinguish between components package or single library package.
This should be done differently, by using the aggregate_components functionality, see https://docs.conan.io/2/reference/tools/cpp_info.html#aggregating-information-in-custom-generators
when linking to the entire package - for example in cmake target_link_directories(MyTarget PRIVATE SomeSdk::SomeSdk)
This should work by the aggregation of the real components by a package interface target, but not necessarily by creating a single target that contains the aggregated information (this is what current CMakeDeps might be doing, but we are already starting to work on a better approach more CMake-targets native)
Closing as responded, please re-open or create a new ticket if you have any further feedback.