Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[question] Unnecessary binaries getting installed #16402

Closed
1 task done
michaelmayer opened this issue Jun 4, 2024 · 3 comments · May be fixed by #16412
Closed
1 task done

[question] Unnecessary binaries getting installed #16402

michaelmayer opened this issue Jun 4, 2024 · 3 comments · May be fixed by #16412
Assignees

Comments

@michaelmayer
Copy link

What is your question?

Hi,

let's say we have the following dependency graph:

exe -> shared -> static_a -> static_b
 |                            ^
 |----------------------------|

Usually, the static binaries won't be installed for the exe, if I don't have the dependency from exe to static_b.
When I add the direct (or indirect) dependency to static_b however, I would expect only the static_b binary to be installed. What happens instead is conan installs both static_a and static_b binaries.

 ~/work/tmp/exe$ conan install -s build_type=Release .
 ...
 ======== Installing packages ========
static_b/1.0: Already installed! (1 of 3)
static_a/1.0: Already installed! (2 of 3)
shared/1.0: Already installed! (3 of 3)
...

To get rid of this I would have to mark the requirement from shared to static_a as visible=False.

Of course this example is rather small, simple and ridiculous. In real life it happened through the zlib, and it took me quite some time to figure out why the "static_a" suddenly popped up for the consumers of the shared lib.

Is there a reason for this?

Regards,
Michael

Have you read the CONTRIBUTING guide?

  • I've read the CONTRIBUTING guide
@memsharded
Copy link
Member

Hi @michaelmayer

Thanks very much for your detailed report.

I have been investigating this, and proposed a PR #16412 with some tests.

You are right, the intermediate binary is not skipped when this happen. I have done some checks in the tests:

  • The traits are correct. Even if the binary is not skipped and the binary is download, it will not be linked to the application.
  • The reason that the intermediate package is not skipped is because there are some cases in which intermediate packages which binaries are not really needed, but their build scripts are needed.

I have been checking if it is possible to improve the "skip-binaries" computation, but it seems that this would be quite complex, a large effort. As this is mostly a performance improvement (the linkage is correct) that should happen only in certain cases (like in this case, where there are 2 instances/copies of the transitive static library, one inside the shared library and the other inside the executable), it seems that it wouldn't be a priority to improve it now.

@michaelmayer
Copy link
Author

Hi @memsharded,

thanks for the detailed explanation. Fair enough, at least we know now why this is the case and can continue using the visible flag, with good conscience 😄

have a nice day,
Michael

@memsharded
Copy link
Member

Thanks to you for your feedback @michaelmayer

When we can improve this in the future, I will try to come back here and let you know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants