in the large projects i've built i always set the env var in the .cargo/config.toml file, but this is a very good idea
i think we should do both - so local builds also do not reset the cache

Package Changes Through b8f5bd5

There are 3 changes which include tauri-build with patch, tauri-cli with patch, @tauri-apps/cli with patch

Add another change file through the GitHub UI by following this link.

Read about change files or the docs at github.com/jbolda/covector

i think we should do both - so local builds also do not reset the cache

we can't do both, that would overwrite this PR

unless you mean, this PR for those who didn't set the env and the env for the new projects, that would indeed make sense. sorry i should go to bed x)

unless you mean, this PR for those who didn't set the env and the env for the new projects

that's right

This PR breaks macos apps that use swift-rs. It seems that swift-rs needs the deployment target to be set.

Hmm, in my opinion this isn't our responsibility. Other crates like cc-rs / cmake-rs whatever have fallback values. I would have expected it to work already since you need to set the version in SwiftLinker::new. I guess this is the relevant issue on their side: Brendonovich/swift-rs#68

Given that swift-rs is the only way to run swift code on macos, it would be nice to maintain compatibility until the deployment target issues are fixed on their side or until tauri provides another way to run swift code on macos. For example, would you consider adding a setting to tauri.conf.json to set the macos deployment target in dev?

Nah a setting doesn't make sense, at that point I'd rather add it back and tell people to add a cargo env if they have recompilation issues.

Is it enough to insert the cargo instruction in your app's build.rs file or does swift-rs need the env var set by the tauri cli? (This PR disabled both).

Inserting the cargo instruction in build.rs works.