-
Notifications
You must be signed in to change notification settings - Fork 782
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
cargo: add links = "python"
#1819
Conversation
FYI I'm sitting on merging this just because I want to understand whether it's really necessary. So I'd like to see the result of indygreg/PyOxidizer#433 (comment) TBH it's probably a good idea to add this key anyway, however no harm in waiting. I'll make sure this gets merged before 0.15 if deemed relevant. |
Wasn't it discussed to add |
Yes, though I can't remember exactly where. That's what I was implicitly referring to when I said "it's probably a good idea to add this key anyway" - I should have been clearer 🙃 |
Ok, shall we go ahead and merge this then? Looks like it needs a rebase; there's a CHANGELOG merge conflict and also some kind of glitch with CI which probably will get fixed with a rebase. |
PyOxidizer has crates depending on `pyo3` that would like to access the `pyo3` crate configuration. (This use case isn't unique to PyOxidizer.) Cargo has a facility for enabling the build scripts of dependent crates to access _exported_ variables via `DEP_` environment variables. However, this only works if the exporting crate defines a `links` key in its Cargo manifest. See https://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key. While `pyo3`'s build script doesn't yet export the variables that PyOxidizer will need, a prerequisite to making this work is adding the `links` key. Since this change could introduce unintended side-effects, it warrants being made in its own commit, which is why we're making this change outside of PyO3#1793. I _think_ this change should be mostly safe: the `links` key is effectively metadata advertising that a crate links against a named library. The only side-effects setting it has is to enable the aforementioned `DEP_` environment variables in build scripts and enforcing a limitation that only a single crate may link against the same native library. I believe the only potential for this change to cause problems is if there are multiple crates with `links = "python"` entries. I'm not aware of any other crates that advertise `links = "python"`: even `python3-sys` / `cpython` use `links = "python3"` so this change should not prevent dual use of `pyo3` and `cpython` in the same build.
I rebased to resolve the merge conflict. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
PyOxidizer has crates depending on
pyo3
that would like to accessthe
pyo3
crate configuration. (This use case isn't unique toPyOxidizer.)
Cargo has a facility for enabling the build scripts of dependent
crates to access exported variables via
DEP_
environmentvariables. However, this only works if the exporting crate defines a
links
key in its Cargo manifest. Seehttps://doc.rust-lang.org/cargo/reference/build-scripts.html#the-links-manifest-key.
While
pyo3
's build script doesn't yet export the variables thatPyOxidizer will need, a prerequisite to making this work is adding
the
links
key. Since this change could introduce unintendedside-effects, it warrants being made in its own commit, which is
why we're making this change outside of #1793.
I think this change should be mostly safe: the
links
key iseffectively metadata advertising that a crate links against a named
library. The only side-effects setting it has is to enable the
aforementioned
DEP_
environment variables in build scripts andenforcing a limitation that only a single crate may link against the
same native library. I believe the only potential for this change
to cause problems is if there are multiple crates with
links = "python"
entries. I'm not aware of any other crates that advertiselinks = "python"
: evenpython3-sys
/cpython
uselinks = "python3"
so this change should not prevent dual use ofpyo3
andcpython
in the same build.