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
31 lines
887 B
TOML
31 lines
887 B
TOML
[build]
|
|
# v0 mangling scheme provides more detailed backtraces around closures
|
|
rustflags = ["-C", "symbol-mangling-version=v0", "--cfg", "tokio_unstable"]
|
|
|
|
[alias]
|
|
xtask = "run --package xtask --"
|
|
|
|
[target.x86_64-unknown-linux-gnu]
|
|
linker = "clang"
|
|
rustflags = ["-C", "link-arg=-fuse-ld=mold"]
|
|
|
|
[target.aarch64-unknown-linux-gnu]
|
|
linker = "clang"
|
|
rustflags = ["-C", "link-arg=-fuse-ld=mold"]
|
|
|
|
[target.aarch64-apple-darwin]
|
|
rustflags = ["-C", "link-args=-Objc -all_load"]
|
|
|
|
[target.x86_64-apple-darwin]
|
|
rustflags = ["-C", "link-args=-Objc -all_load"]
|
|
|
|
[target.'cfg(target_os = "windows")']
|
|
rustflags = [
|
|
"--cfg",
|
|
"windows_slim_errors", # This cfg will reduce the size of `windows::core::Error` from 16 bytes to 4 bytes
|
|
"-C",
|
|
"target-feature=+crt-static", # This fixes the linking issue when compiling livekit on Windows
|
|
]
|
|
|
|
[env]
|
|
MACOSX_DEPLOYMENT_TARGET = "10.15.7"
|