-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
fix(embeded): Don't pollute the scripts dir with target/
#12282
Conversation
This was broken in rust-lang#12268 when we stopped using an intermediate `Cargo.toml` file. Unlike pre-rust-lang#12268, - We are hashing the path, rather than the content, with the assumption that people change content more frequently than the path - We are using a simpler hash than `blake3` in the hopes that we can get away with it Unlike the Pre-RFC demo - We are not forcing a single target dir for all scripts in the hopes that we get rust-lang#5931
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
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 for the fix.
I notice two things are broken after #12268.
- If there is a
build.rs
under the same directory,cargo <script.rs>
will run it. - If there is a
Cargo.lock
under the same directory, it will be overwritten.
Both of them don't look like desired behavior I believe.
Should I open a new issue for them? It looks like this PR might need to change accordingly when those behavior change.
rel_path.push(&hash[0..2]); | ||
rel_path.push(&hash[2..]); |
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.
(Not a blocker)
Maybe we don't need this intermediate directory as the short hash is short enough?
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.
Its not about the length of the hash but the potential for the number of children of the parent directory. I can't remember if this is true for all platforms but I think its at least on Windows, you can get some pretty bad performance.
In the prior version, I had a third level instead. Here I'm hoping we can get away with just two.
Maybe I'm missing something but not seeing why these two affect each other. |
There was a typo. The second one should be
I was thinking that if we go back to put stuff in a central place under |
So move the workspace root instead? I feel like that is a bit misleading. #12283 is now up for |
Make sense! Those issues are not really directly related to this PR. I will go ahead and merge this. Thanks for the clarification! @bors r+ |
☀️ Test successful - checks-actions |
Update cargo 12 commits in 0c14026aa84ee2ec4c67460c0a18abc8519ca6b2..dead4b8740c4b6a8ed5211e37c99cf81d01c3b1c 2023-06-14 18:43:05 +0000 to 2023-06-20 20:07:17 +0000 - Convert valid feature name warning to an error. (rust-lang/cargo#12291) - fix(embedded): Don't pollute script dir with lockfile (rust-lang/cargo#12284) - fix: remove `-Zjobserver-per-rustc` again (rust-lang/cargo#12285) - docs: some tweaks around `cargo test` (rust-lang/cargo#12288) - Enable `doctest-in-workspace` by default (rust-lang/cargo#12221) - fix(embedded): Don't auto-discover build.rs files (rust-lang/cargo#12283) - fix(embeded): Don't pollute the scripts dir with `target/` (rust-lang/cargo#12282) - feat: prepare for the next lockfile bump (rust-lang/cargo#12279) - fix(embedded): Don't create an intermediate manifest (rust-lang/cargo#12268) - refactor(embedded): Switch to `syn` for parsing doc comments (rust-lang/cargo#12258) - fix(embedded): Align package name sanitization with cargo-new (rust-lang/cargo#12255) - Clarify the default behavior of cargo-install. (rust-lang/cargo#12276) r? `@ghost`
What does this PR try to resolve?
This PR is part of #12207.
This specific behavior was broken in #12268 when we stopped using an intermediate
Cargo.toml
file.Unlike pre-#12268,
that people change content more frequently than the path
blake3
in the hopes that we can getaway with it
Unlike the Pre-RFC demo
that we get Per-user compiled artifact cache #5931
How should we test and review this PR?
A new test was added specifically to show the target dir behavior, rather than overloading an existing test or making all tests sensitive to changes in this behavior.
Additional information
In the future, we might want to resolve symlinks before we get to this point