-
Notifications
You must be signed in to change notification settings - Fork 763
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
Expose cross compiling configuration from pyo3-build-config #1996
Conversation
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.
Looking good! Few comments below.
I try to avoid adding dependencies to pyo3 and sub-crates as much as possible. It looks like target_lexicon
is itself a simple dependency with no other dependencies, so it's relatively lightweight. Which platforms do you feel we're lacking support for which target_lexicon
could help with?
Thanks for the quick feedback! I'll work on these suggestions. |
Thank you for helping with this. Just a reminder, this branch has conflicts that must be resolved. |
97439a3
to
7ab810a
Compare
1f16e1c
to
c8f0785
Compare
FYI, we recently merged PyO3/maturin#677 , it introduced new dependency on |
Hm, thanks for the heads up. This is already called by |
…nterpreterConfig::from_sysconfigdata.
664c31d
to
4974fc8
Compare
I know I definitely still have a couple tests to write, but I'm a bit confused by the codecov results. Is there a good way for me to run this locally? Otherwise I think this refactor definitely provides a better API now than before, so thanks for the suggestion! I'm not sure if the |
If you go into the This is definitely looking great, let me know when you want a re-review. (I think there will only be minor nits left tbh, nice work.)
Yes indeed I didn't state it but I was assuming that we would parse (and keep) the whole file contents 👍 |
(#2011 may be relevant if you're getting weird coverage results.) |
I wrote a few more tests to improve coverage (not pushed), but the cases where it is cross compiling all rely on environment variables, which I am having a hard time controlling for tests. I can set/unset in each test, but the default for Aside from that I am mostly happy with the interface and would appreciate feedback when you have time to review. I don't have a great feeling for whether pub fn cross_compiling(
host: AsRef<str>,
target_arch: Into<String>,
target_vendor: Into<String>,
target_os: Into<String>,
) -> Result<Option<CrossCompileConfig>> Edit: regarding tests/coverage Thanks - I can run the tests locally (though I could get better at actually doing that before I push), but I wasn't sure how to check for a codecov failure before pushing. I guess codecov is its own thing though even if I can measure coverage locally. I was having trouble viewing the full report but that seems working now. |
👍 I'll give this a full review in the morning, thanks! EDIT: sorry it took me an extra day and a bit 😪 |
Looks good to me! I'd recommend to actually give it a try on maturin(as a git dependency) to see if it fits. |
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.
Thank you, this is looking excellent!
I have a few minor tidy ups commented below, really just nits though.
I agree also that it's probably worth having a whirl with using this as a git dependency with maturin
(and maybe even opening that branch as a PR on the maturin repo) to confirm that we're happy with how this works downstream before we merge.
👍 this is looking great to me from the PyO3 side, thanks! I see you have opened PyO3/maturin#718, so will wait to merge this until you're happy with that one too. Ping me when ready! |
94362d1
to
2986aca
Compare
if cfg!(feature = "resolve-config") { | ||
println!("cargo:rerun-if-env-changed={}", var); | ||
} |
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.
@davidhewitt let me know if this is problematic or if there's a better way to suppress this output in maturin.
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.
This seems like a sensible way to do it to me!
Okay PyO3/maturin#718 seems good to go and I think this is ready for another look. I will make a few inline comments for areas I have questions but of course appreciate any additional feedback Merging probably needs to wait for #2040 but otherwise hopefully we can close this out soon! |
@@ -826,7 +920,7 @@ fn ends_with(entry: &DirEntry, pat: &str) -> bool { | |||
/// So we must find the file in the following possible locations: | |||
/// | |||
/// ```sh | |||
/// # distribution from package manager, lib_dir should include lib/ | |||
/// # distribution from package manager, (lib_dir may or may not include lib/) |
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.
Hopefully this is okay - see implementation below. This was requested in Maturin to support cross-compiling with PyPy, where the _sysconfigdata*.py
is not under the lib
dir.
I think we have a use case for the new |
Just as I merge I can look into adding this here if you all think it's best to have in the same PR. It doesn't seem like too much work. In any case I'd be happy to take this on as another project. |
Thanks! Do it in another PR is fine. |
No rush @davidhewitt and @messense but I'm just waiting for feedback at this point so please let me know if there's anything else needed here! My PR in Maturin is passing tests while pointed to the latest in this branch. Otherwise I will start looking into the above request to expose more features of |
Looks good to me. Let's give @davidhewitt a chance to take another look before merging. |
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.
Looks brilliant! Thank you for all the work put into this, and I'm sorry it took me so long to find time to review.
if cfg!(feature = "resolve-config") { | ||
println!("cargo:rerun-if-env-changed={}", var); | ||
} |
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.
This seems like a sensible way to do it to me!
Move changelog entry for #1996.
These modifications were proposed in #1627.
So far this exposes three functions:
cross_compiling
(altered to take arguments, with current behavior moved tocross_compiling_from_cargo_env
)find_sysconfigdata
parse_sysconfigdata
and modifies
InterpreterConfig
with three new fields:abi_flags
abi_tag
ext_suffix
The refactored
cross_compiling
takeshost
(triple),arch
,vendor
, andos
, butvendor
is not currently used separately from what I see in maturin. It might be better to change it to take only the complete "target triple" to simplify things, but splittingos
andarch
from there forCrossCompileConfig
may not be straightforward as the overall format seems a bit complicated (i.e. not always only three parts). Maturin uses another crate (target_lexicon
) for this, which could be pulled in here so it could perhaps take atarget_lexicon::Triple
. This might be the best option for supporting the most platforms.I'm also not sure I have the correct behavior for the fields added to
InterpreterConfig
- specifically I'm not sure if the defaults are handled correctly. Also, do they need to change depending on the value ofabi3
?It seems there's more in pyo3-build-config that could be exposed so I'm happy to bundle that in this PR or work on the different features separately.
TODO:
pyo3-build-config
example #1628, docs: pyo3 config files #1976)