-
-
Notifications
You must be signed in to change notification settings - Fork 760
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
vcpkg build-dependency now unconditionally pulled in for all targets #2031
Comments
Yes, it needs to be pulled in for cross-compile workflows. |
Ok :( That's unfortunate. I'll drop the dependency with a downstream patch then. Thanks for confirming! |
As a long term action item, it seems like maybe this scenario could be addressed by making cargo more flexible in declaring host or target build deps? |
Yeah more powerful dependency filtering would cover it. |
While So while I acknowledge the minor absurdity of the situation for a Linux distributor, even if you could resolve the dependency loop to filter it out by target on a Cargo level, it would lead to a similar situation to what I'm trying to unwrap with the assumption that you wouldn't use If you're building in
To turn around your suggestion: it does not make sense to have a hard dependency on See also: #1062 |
It looks like since openssl-sys 0.9.91, the vcpkg dependency is now hard-required, even on targets where it is unused. Would it be possible to cfg-gate the build-dependency and usage of vcpkg in build.rs? For example, it does not make sense for Linux distributions to package the vcpkg crate, but openssl-sys now can't be built without it.
Looking at the PR that introduced this change (#1982), it sounds like this is a workaround for host != target environment? If there's no other way to resolve this than to make the build-dependency unconditional, then I'll likely need to apply some downstream patches for openssl-sys for the builds in Fedora Linux.
The text was updated successfully, but these errors were encountered: