[question] requirement propagated

[JNURay]

What is your question?

conan version is 1.59.0

I have libA, and libB which are consumed by conan package C. lib A is dynamic lib, lib B is static lib. An executable will be created by package C. there's a package D will be responsible to require C for integration only and will not compile or consume C as dependency.

in C conan file：

def package_id(self): self.info.requires[libA].recipe_revision_mode() self.info.requires[libB].recipe_revision_mode()

def requirements(self): self.requires("libA/@/") self.requires("libB/@/")

def package_info(self):

---

self.cpp_info.components["Cc"].requires = [
            "B::a",
            "B::b",
        ]

[question] how should I avoid A and B being propagated to D when D requires C?

I have read something in conan docs. here are possible methods but not limited:

1. change requiring A and B from requires to build_requires. in my case when packaging C, there would be an error whling finding the packages in C's CMakeLists. also the conan docs says build_requies usually is used for tools.
2. set attribute visible of requires to A and B to be False. is this a good way to do it? as I read from the doc:

It can be set to False in advanced scenarios, when we want to use different versions of the same package during the build.

Have you read the CONTRIBUTING guide?

• [X] I've read the CONTRIBUTING guide

[memsharded]

Hi @JNURay

Thanks for your question.

set attribute visible of requires to A and B to be False.

The visible=False works only in Conan 2 (with all the other requirements traits, and the new dependency resolution). So the first necessary step would be to upgrade to Conan 2 from Conan 1.X

In Conan 2, when D has a tool_requires("pkg_c/version"), it will not get propagated the libraries A and B, unless they are shared libraries in which case it will only get propagated the environment to locate and run them, but not linkage requirements.

[memsharded]

Hi @JNURay

Did the above clarify it? Any other further question or comment? Thanks for the feedback.

[JNURay]

Hi @memsharded thanks for your reply and sorry for late.

I did tests based on conan2. the tool_requires and build_requires in package C will cause CMake issue on find_package. package C could not get the findA.cmake for building. however, test_requires works.

also if set the attribute visible of requires to be False, the A B packages are still propageted to D....

[JNURay]

Hi @memsharded thanks for your reply and sorry for late.

I did tests based on conan2. the tool_requires and build_requires in package C will cause CMake issue on find_package. package C could not get the findA.cmake for building. however, test_requires works.

also if set the attribute visible of requires to be False, the A B packages are still propageted to D....

[memsharded]

Hi @JNURay

Thanks for your feedback. I have tried to have another look to your above explanations, but I am afraid that we would still be missing enough information to understand what could be happening, the above doesn't seem enough.

The best would be to have some real code that we can reproduce, like a git repo with some simple recipes (as those created with the conan new cmake_lib and cnan new cmake_exe templates), with a script in the root with the commands to reproduce the issue.