[question] Components requirements to transitive library

[joastoe]

What is your question?

Hi, I stumbled across the following:

Let's assume my package has the following requirements
requires = ["libA/0.1.0"]

This libA in turn depends on some libB

Now I use components for the package:

def package_info(self):
    self.cpp_info.components["compA"].libs = ["compa"]
    self.cpp_info.components["compA"].requires = ["libA::libA"]

    self.cpp_info.components["compB"].libs = ["compb"]
    self.cpp_info.components["compB"].requires = ["libB::libB"]

This fails with an error:
ERROR: mypackage/1.0.0: required component package 'libB::' not in dependencies

Is there a way to overcome this without the need of adding libB to the requires?

Thanks

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @joastoe

Thanks for your question.

I am afraid no, this is by design. If a package doesn't express a explicit requires = "libb/..., then it cannot use it in is recipe or code. It is considered an implementation detail of liba, that might exist or not, but it cannot be explicitly referenced.

Note that if your package code has direct #include to libb headers, then it is considered a direct dependency, and it must have a requires = "libb/..." to it. Is this the case? And if it is the case, why would it be an issue to declare the requires?

[joastoe]

Thanks @memsharded for this fast answer.

Indeed, compB has a direct dependency to libB. But not to libA. This is why I would not add libA as a dependency to compB, altough it could work.

My concern by adding libB to requires is to run into a version conflict. Because libA could request a different version of libB than mypackage.

[memsharded]

My concern by adding libB to requires is to run into a version conflict. Because libA could request a different version of libB than mypackage.

The moment that there is a direct dependency of compB to libB, the conflict effects are already a risk, no matter of the direct or indirect declaration of requires. Because the consumer has #includes that can break by using one version or another of the dependency, conflicts arising because of different versions will result in compilation errors anyway, with a much more complicated diagnosis than if failing fast because Conan detected.

The recommended way to deal with possible conflicts and minimize them is to use version ranges. If libA contains a requires to a fixed version of libB, then using the same version wouldn't be an issue if libA doesn't automatically upgrade it within the same revision. But still, it is possible to define a version range that includes the compatible versions of libB and as long as they match the declaration of the requires in libA, they will not conflict. And if they conflict, then it is good they do, because if the range is correct it would mean there will be a conflict and error in code anyway.

[joastoe]

Thanks for this explanation. I'll then add libB to requires.

[memsharded]

Thanks for this explanation. I'll then add libB to requires.

Sounds good. I'll close the ticket as responded, but please feel free to open new tickets for any further question you might have. Thanks for the feedback!