d1c67897c5
## 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: ``` cargo test -p project # Requires a rebuild (warranted) cargo run . cargo test -p project # Requires a rebuild (unwarranted) ``` or ``` cargo run . # Requires a rebuild (warranted) cargo run . # Requires a rebuild (unwarranted) ``` ## 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 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). ## Solution ~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.~ ~The alternative I've considered is running [via a custom runner](https://doc.rust-lang.org/cargo/reference/config.html#targetcfgrunner), 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. Release Notes: - N/A |
||
|---|---|---|
| .. | ||
| ci-config.toml | ||
| collab-config.toml | ||
| config.toml | ||