chore: Do not bust Rust build cache when opening projects with dev build #26278
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Running `cargo run .` twice in Zed repository required a rebuild two times in a row. The second rebuild was triggered around libz-sys, which in practice caused a rebuild of the ~entire project. Zed build script on MacOS sets MACOSX_DEPLOYMENT_TARGET to 10.15. This is fine. However, **cargo propagates all environment variables to child processes during `cargo run`**. This then affects Rust Analyzer spawned by dev Zed - it clobbers build cache of whatever package it touches, because it's behavior is not same between running it with `cargo run` (where MACOS_DEPLOYMENT_TARGET gets propagated to child Zed) and running it directly via `target/debug/zed` or whatever (where the env variable is not set, so that build behaves roughly like Zed Dev.app). We'll unset that env variable from user environment when we're reasonably confident that we're running under `cargo run` by exploiting other env variables set by cargo: https://doc.rust-lang.org/cargo/reference/environment-variables.html CARGO_PKG_NAME is always set to `zed` when running it via `cargo run`, as it's the value propagated from the build.
cla-bot
bot
added
the
cla-signed
I've realized that 6079b7b breaks things the other way. If one has MACOSX_DEPLOYMENT_TARGET set in their shell profile, they'd start experiencing these issues until they unset it. Thus, let's instead ensure that regardless of whether MACOSX_DEPLOYMENT_TARGET is set or not, we always set it for cargo, which should allow us to skip rebuilds too. As a bonus, the runner approach I've mentioned in OP is no better in that regard.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Running
cargo run .twice in Zed repository required a rebuild two times in a row. The second rebuild was triggered around libz-sys, which in practice caused a rebuild of the ~entire project.Some concrete examples:
or
What's going on
Zed build script on MacOS sets MACOSX_DEPLOYMENT_TARGET to 10.15. This is fine. However, cargo propagates all environment variables to child processes during
cargo run. This then affects Rust Analyzer spawned by dev Zed - it clobbers build cache of whatever package it touches, because it's behavior is not same between running it withcargo run(where MACOS_DEPLOYMENT_TARGET gets propagated to child Zed) and running it directly viatarget/debug/zedor whatever (where the env variable is not set, so that build behaves roughly like Zed Dev.app).Solution
We'll unset that env variable from user environment when we're reasonably confident that we're running undercargo runby exploiting other env variables set by cargo: https://doc.rust-lang.org/cargo/reference/environment-variables.html CARGO_PKG_NAME is always set tozedwhen running it viacargo run, as it's the value propagated from the build.The alternative I've considered is running via a custom runner, though the problem here is that we'd have to use a shell script to unset the env variable - that could be problematic with e.g. fish. I just didn't want to deal with that, though admittedly it would've been cleaner in other aspects.Redact all above. We'll just set MACOSX_DEPLOYMENT_TARGET regardless of whether you have it in your OG shell environment or not. This means that
target/debug/zedis now the one that can run into the same problem, but.. 🤷Release Notes: