fix(build): stop forcing a nonexistent DEVELOPER_DIR on Command Line Tools-only machines

[4ni1ak]

Summary

• .cargo/config.toml unconditionally set DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer (with force = false) for every macOS cargo invocation, meant as a "belt-and-suspenders" fallback for a contributor who has Xcode installed but xcode-select pointed at the Command Line Tools.
• Cargo's [env] table is static TOML — there is no way to check whether that path actually exists before applying it. On a machine with only the Command Line Tools installed (no Xcode.app at all), or Xcode installed under a non-standard name like Xcode-beta.app, this pointed every dependency's build-script linker step at a path that doesn't exist. cargo build/check/test failed before compiling a single workspace crate — not just the GUI's Metal shader step this was meant to help.
• force = false never protected against this: it only yields to a DEVELOPER_DIR already exported in the calling shell, which a plain xcode-select misconfiguration never sets on its own — so the override always won in exactly the broken case.

Changes

• crates/.cargo/config.toml: removed the static [env] DEVELOPER_DIR block, replaced with a comment explaining why and pointing at the one-time system fix (sudo xcode-select -s /Applications/Xcode.app/Contents/Developer) for a contributor who does have Xcode but a misconfigured selector.

Testing

• cargo fmt --all -- --check
• RUSTFLAGS="-D warnings" cargo clippy --workspace --all-targets -- -D warnings
• RUSTFLAGS="-D warnings" cargo test --workspace
• RUSTDOCFLAGS="-D warnings" cargo doc --workspace --no-deps --document-private-items --exclude openlogi-ui --exclude openlogi-desktop --exclude openlogi-overlay --exclude openlogi-agent
• Full tier since .cargo/config.toml is a workspace-wide build input.
• Verified devenv.nix sets its own DEVELOPER_DIR independently (its own hardcoded path plus a requireXcodeMetal check that fails loudly with an actionable message when Metal isn't available), and .github/workflows/build.yml/release.yml set their own DEVELOPER_DIR env at the workflow level — neither depends on the removed block, so devenv and CI builds are unaffected.
• Not verified on a real Command-Line-Tools-only macOS machine (this box is Linux); the fix is a straightforward removal of a value that could only ever point at a wrong path in that exact environment, with no logic change for any other platform or workflow.

Fixes #1079

[greptile-apps]

Confidence Score: 4/5

The configuration change appears safe to merge, with a non-blocking documentation correction recommended for its description of macOS CI.

Findings

1.  CI claim is inaccurate ▶

Summary

Removes Cargo’s workspace-wide, hardcoded macOS DEVELOPER_DIR override so Command-Line-Tools-only machines and nonstandard Xcode installations are no longer directed to a nonexistent path.

• Explains why force = false did not protect affected environments.
• Retains guidance for correcting xcode-select when a full standard Xcode installation is available.
• Contains one inaccurate documentation claim about all CI workflows setting DEVELOPER_DIR.

_{Reviews (1) · Last reviewed commit: "fix(build): stop forcing a nonexistent D..."}

[greptile-apps]

CI claim is inaccurate

The comment says CI workflows set their own DEVELOPER_DIR, but the macOS checks and tests in .github/workflows/ci.yml do not set it and instead rely on the hosted runner’s selected Xcode. Narrow this statement to the build and release workflows so it does not mislead future build debugging.

Suggested change

	# sets. devenv (`devenv.nix`) and CI (`.github/workflows/*.yml`) already set
	# their own correct `DEVELOPER_DIR` independently of this file, so removing
	# it doesn't affect either. A contributor building the GUI outside devenv
	# sets. devenv (`devenv.nix`) and the build/release workflows set their own
	# correct `DEVELOPER_DIR` independently of this file, so removing it doesn't
	# affect those paths. A contributor building the GUI outside devenv