Describe the bug
On macOS, there's a special env var MACOSX_DEPLOYMENT_TARGET that implicitly configures the system's C compiler, linker, and opts in to or out of breaking changes in macOS. Objects built for different deployment targets may be incompatible. The cc crate knows this and emits cargo:rerun-if-env-changed=MACOSX_DEPLOYMENT_TARGET, which invalidates cache of sys crates whenever cargo build sees a different value of this variable.
Unfortunately, something in Tauri is trying to override MACOSX_DEPLOYMENT_TARGET to 10.13.
This causes two bugs:
-
Even if I set MACOSX_DEPLOYMENT_TARGET env var to a different value, the project is built for 10.13 anyway.
-
The override causes cargo to invalidate cache of sys crates, and rebuild objc-sys and all of wry, tauri, and its plugins, every time cargo tauri dev sees any file change!
Dirty objc-sys v0.3.5: the env variable MACOSX_DEPLOYMENT_TARGET changed
I'm not sure where Cargo is getting another value from. I suspect that rust-analyzer is building the project in a way that doesn't support Tauri's way of overriding MACOSX_DEPLOYMENT_TARGET, or perhaps there's just a race condition in Cargo that compares an unset value from before the build start with a value set during the build.
The end result is that cargo tauri dev is painfully slow.
Reproduction
To reproduce, modify src/main.rs to add:
compile_error!(env!("MACOSX_DEPLOYMENT_TARGET"));
and run:
unset MACOSX_DEPLOYMENT_TARGET
cargo tauri dev
The expected result:
error: environment variable `MACOSX_DEPLOYMENT_TARGET` not defined at compile time
The actual result:
Second test:
export MACOSX_DEPLOYMENT_TARGET=11.0
cargo tauri dev
The expected result:
The actual result:
Expected behavior
No response
Full tauri info output
[✔] Environment
- OS: Mac OS 15.1.0 arm64 (X64)
✔ Xcode Command Line Tools: installed
✔ rustc: 1.82.0 (f6e511eec 2024-10-15)
✔ cargo: 1.82.0 (8f40fc59f 2024-08-21)
✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
✔ Rust toolchain: stable-aarch64-apple-darwin (environment override by RUSTUP_TOOLCHAIN)
- node: 23.1.0
- yarn: 1.22.22
- npm: 10.9.0
[-] Packages
- tauri 🦀: 2.0.6
- tauri-build 🦀: 2.0.2
- wry 🦀: 0.46.3
- tao 🦀: 0.30.5
- tauri-cli 🦀: 2.0.4
[-] Plugins
- tauri-plugin-shell 🦀: 2.0.2
[-] App
- build-type: bundle
- CSP: unset
- frontendDist: ../src
Stack trace
No response
Additional context
No response
Describe the bug
On macOS, there's a special env var
MACOSX_DEPLOYMENT_TARGETthat implicitly configures the system's C compiler, linker, and opts in to or out of breaking changes in macOS. Objects built for different deployment targets may be incompatible. Thecccrate knows this and emitscargo:rerun-if-env-changed=MACOSX_DEPLOYMENT_TARGET, which invalidates cache of sys crates whenevercargo buildsees a different value of this variable.Unfortunately, something in Tauri is trying to override
MACOSX_DEPLOYMENT_TARGETto10.13.This causes two bugs:
Even if I set
MACOSX_DEPLOYMENT_TARGETenv var to a different value, the project is built for 10.13 anyway.The override causes
cargoto invalidate cache of sys crates, and rebuildobjc-sysand all ofwry,tauri, and its plugins, every timecargo tauri devsees any file change!I'm not sure where Cargo is getting another value from. I suspect that
rust-analyzeris building the project in a way that doesn't support Tauri's way of overridingMACOSX_DEPLOYMENT_TARGET, or perhaps there's just a race condition in Cargo that compares an unset value from before the build start with a value set during the build.The end result is that
cargo tauri devis painfully slow.Reproduction
To reproduce, modify
src/main.rsto add:and run:
unset MACOSX_DEPLOYMENT_TARGET cargo tauri devThe expected result:
The actual result:
Second test:
export MACOSX_DEPLOYMENT_TARGET=11.0 cargo tauri devThe expected result:
The actual result:
Expected behavior
No response
Full
tauri infooutputStack trace
No response
Additional context
No response