[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.

[memsharded]

Hi @JNURay

Any further feedback here? Could you prepare that reproducible code we could check? Thanks.

[JNURay]

Hi @memsharded . sorry for long time no response and yes, I'm gonna create some repos for testing.

[JNURay]

Hi @memsharded I have set up 3 repos for test. lib_dep required by lib_subsys required by sys

[memsharded]

Hi @JNURay

Thanks for the code.

If you are in Conan 1, the VirtualRunEnv generator need to be explicit, so:

diff --git a/test_package/conanfile.py b/test_package/conanfile.py
index b4f8dc1..d4b52e8 100644
--- a/test_package/conanfile.py
+++ b/test_package/conanfile.py
@@ -5,6 +5,7 @@ from conan.tools.build import can_run

 class sysTestConan(ConanFile):
     settings = "os", "compiler", "build_type", "arch"
+    generators = "VirtualRunEnv"

     def requirements(self):
         self.requires(self.tested_reference_str)

And it will work.

[JNURay]

Hi @memsharded , thank you for your reply. However I'm a little confused about the diff you shared. you added the explicit virtualRunEnv generator. I'd like to clarify my question again.

background: lib_dep required by lib_subsys required by sys

I'm trying to find a way to avoid the propogation of lib_dep to sys through lib_subsys.

based on Conan2, in lib_subsys conan file, self.build_requires("lib_dep/0.1") or self.tool_requires("lib_dep/0.1") will cause below issue when building:

-- Conan toolchain: Setting CMAKE_POSITION_INDEPENDENT_CODE=ON (options.fPIC) -- Conan toolchain: Defining architecture flag: -m64 -- Conan toolchain: C++ Standard 17 with extensions ON -- Conan toolchain: Setting BUILD_SHARED_LIBS = OFF -- The CXX compiler identification is GNU 11.4.0 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done CMake Error at CMakeLists.txt:10 (find_package): By not providing "Findlib_dep.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "lib_dep", but CMake did not find one.

Could not find a package configuration file provided by "lib_dep" with any

of the following names:

lib_depConfig.cmake lib_dep-config.cmake

Add the installation prefix of "lib_dep" to CMAKE_PREFIX_PATH or set

"lib_dep_DIR" to a directory containing one of the above files. If

"lib_dep" provides a separate development package or SDK, be sure it has

been installed.

-- Configuring incomplete, errors occurred!

test_requires will pass the building. However, when self.requires("lib_subsys/0.1") in sys conanfile.py, the lib_dep is still required. so do when self.requires("lib_dep/0.1", visible=False) in lib_subsys

[memsharded]

You had this in your sys/test_package/conanfile.py:

class sysTestConan(ConanFile):
    settings = "os", "compiler", "build_type", "arch"

    def requirements(self):
        self.requires(self.tested_reference_str)

    def test(self):
        if can_run(self):
            self.run("sys", env="conanrun")

You are telling env="conanrun", but no conanrun file is being generated, because no one is generating it, so the test_package fails. It is necessary to add generators = "VirtualRunEnv" there to make this test_package work.

I'm trying to find a way to avoid the propogation of lib_dep to sys through lib_subsys.

I think this is not a Conan thing, not Conan 1, nor Conan2, but a C/C++ library thing.

If you have:

app (executable) -> libb (static library) -> liba (static library)

There is not such a thing as avoid the propagation of liba to app. The app executable will always have to link with both libb and liba. This is absolutely necessary, otherwise you get link errors. liba cannot be skipped, removed or hidden from the linkage of app.

Please let me know if this clarifies things.

If this is not what you mean, I'd suggest:

• Put all the recipes in the same repo, not different repos
• Then add a build.py python script in the root, that can be executed, and illustrate the exact steps, like doing the conan create liba, conan create libb, etc. until it shows the error or problem.

Because with the repos you shared, I was able to perfectly do the conan create of the packages in order, and everything worked fine, until the last test_package failed, because of above, that was why I was suggesting that fix.

[memsharded]

Hi @JNURay

Did the last comment clarify the issue and the behavior? Thanks for the feedback.

[memsharded]

Hi again @JNURay

Any feedback or new question here?

[JNURay]

Hi @memsharded, the question is answered and thank you for your time