You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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 😄
What is your question?
Hi,
let's say we have the following dependency graph:
Usually, the
static
binaries won't be installed for theexe
, if I don't have the dependency fromexe
tostatic_b
.When I add the direct (or indirect) dependency to
static_b
however, I would expect only thestatic_b
binary to be installed. What happens instead is conan installs bothstatic_a
andstatic_b
binaries.To get rid of this I would have to mark the requirement from
shared
tostatic_a
asvisible=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 theshared
lib.Is there a reason for this?
Regards,
Michael
Have you read the CONTRIBUTING guide?
The text was updated successfully, but these errors were encountered: