Explain rationale for single library per component

[BradHolmes]

What is your question?

I am trying to upgrade from conan 2.9.3 to the latest conan 2.12.2, and our local package fails because we have put multiple related libraries into a single component. I was unable to find guidance on the best practice, and the cpp_info.libs interface is an array, so I wanted to find out more what is going on here. Possibly related: with conan 2.9.3, BazelDeps is producing non-deterministic ordering of the library dependencies per component. I wonder if this is related. We had thought the order in libs would be respected at linking time. Perhaps a rash assumption on our part.

Relatedly, it looks like the latest changes to BazelDeps mirror this rule.

1. First, what is the rationale? I'm sure there is a good one, but I couldn't find it anywhere.
2. Second, am I right that the recent BazelDeps change is simply in line with this practice?
3. Finally, our project has 100s of libraries - with lots of interdependencies. Do you have a suggestion for the best way to organize that? We thought creating ~30 high level components, each with 5-20 libraries made sense. Looks like that might not be right.

Thanks!

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @BradHolmes

Thanks for your question

First, what is the rationale? I'm sure there is a good one, but I couldn't find it anywhere.

Yes, the rationale is converging to the CPS specification, an standardization effort that we are part of (see for example our latest CppCon23, CppCon24 conference talks), in which each component represents 1 library only.

CMake is already starting to have capabilities to produce and read CPS files, and as demostrated in CppCon24 demos, Conan is also capable of reading and creating those files.

The exact details of the changes related to BazelDeps, could be clarified by @franramirez688.