-
Notifications
You must be signed in to change notification settings - Fork 13.1k
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
Don't use remap-path-prefix in dep-info files. #63342
Conversation
r? @Zoxc |
Cc @cuviper - you might have some insight into reproducible builds (or know who does) |
@bors: r+ |
📌 Commit 04eee2e has been approved by |
…ichton Don't use remap-path-prefix in dep-info files. This changes it so that dep-info files do not use remapped paths. Having remapped paths causes problems with Cargo because if you remap to a nonexistent path (like `/rustc/$HASH` which rustc distributions do), then Cargo's change tracking thinks the files don't exist and will always rebuild. I don't actually know if this is a good idea. I think it makes sense, but I do not know what the exact requirements are for reproducible builds. I consider these files separate from the binary artifacts generated, and as a build-system helper, so it seems reasonable to me. I'm also not sure if this needs a test. I'll definitely add one on the cargo side if this is merged. Closes rust-lang#63329
…ichton Don't use remap-path-prefix in dep-info files. This changes it so that dep-info files do not use remapped paths. Having remapped paths causes problems with Cargo because if you remap to a nonexistent path (like `/rustc/$HASH` which rustc distributions do), then Cargo's change tracking thinks the files don't exist and will always rebuild. I don't actually know if this is a good idea. I think it makes sense, but I do not know what the exact requirements are for reproducible builds. I consider these files separate from the binary artifacts generated, and as a build-system helper, so it seems reasonable to me. I'm also not sure if this needs a test. I'll definitely add one on the cargo side if this is merged. Closes rust-lang#63329
I haven't dealt with that much myself -- maybe @infinity0 per #34902. |
As long as the unmapped path isn't added to the final build output, it's OK to have it in intermediate build artifacts. To avoid someone in the future accidentally using these paths from the dep-info files, that results in them being put back into a final build output, a slightly safer alternative to this PR would be to leave the data as-is (i.e. mapped) but then have rustc/cargo apply the reverse mapping when reading the dep-info file. |
Rollup of 8 pull requests Successful merges: - #63261 (bump rand in libcore/liballoc test suites) - #63316 (Update rustfmt to 1.4.4) - #63332 (Add an overflow check in truncate implementation for Unix.) - #63342 (Don't use remap-path-prefix in dep-info files.) - #63366 (doc: Fix typo in float from bytes methods) - #63370 (Fix ICE #63364) - #63377 (Improved documentation for compile_error!()) - #63379 (Add test for issue 53096) Failed merges: r? @ghost
This changes it so that dep-info files do not use remapped paths.
Having remapped paths causes problems with Cargo because if you remap to a nonexistent path (like
/rustc/$HASH
which rustc distributions do), then Cargo's change tracking thinks the files don't exist and will always rebuild.I don't actually know if this is a good idea. I think it makes sense, but I do not know what the exact requirements are for reproducible builds. I consider these files separate from the binary artifacts generated, and as a build-system helper, so it seems reasonable to me.
I'm also not sure if this needs a test. I'll definitely add one on the cargo side if this is merged.
Closes #63329