Fix remote builds by making build-config contents deterministic#5745
Fix remote builds by making build-config contents deterministic#5745
Conversation
Because of the usage of `env!`, we were baking paths to generated files in `lib.rs`. In setups where the build can be executed remotely (e.g. when building with Buck2), those paths would be different depending on whether the build ran locally or remotely. This difference propagates to `pyo3-macros`. Because Buck2 runs the metadata and codegen builds separately (for increased parallelism), they can have different contents due to the above, causing rustc to find two versions of the crate, and erroring out. This is not observable with Cargo because it runs both builds with the same rustc invocation. See facebook/buck2#1206 and rwf2/Rocket#2797 for more context. This commit fixes the issue by simply reading `OUT_DIR` at run-time, rather than compile-time, so that the content of `lib.rs` is fixed. Closes facebook/buck2#1206 Many thanks to https://github.com/cormacrelf for pointing out the root of the issue.
f112e00 to
ac4ffa1
Compare
|
Hi @davidhewitt, I hope that you don't mind the ping, I just wanted to raise that in case you had missed it. |
|
The commit message for reference:
|
Tpt
left a comment
There was a problem hiding this comment.
Make sense to me. Waiting to @davidhewitt before merging. Thank you for this!
davidhewitt
left a comment
There was a problem hiding this comment.
Thanks for the PR, and sorry to have been so slow to reply.
Sadly almost this exact patch has been proposed before, and I still think unfortunately it will have problems with cross-compilation. Please see #4579 which has my notes from the issue last time it was discussed.
|
I see, thanks for the link, I didn't find it when looking for this issue. |
See the commit message for context.
Note that it I am not 100% confident about what impact this has on cross compilation, because there are no tests/examples for it.