Make doctor passes but build fails — missing msgfmt check and stale-xcrun-cache false negative for Metal Toolchain

[szymonos]

What happened?

make doctor reports all checks passing, but make build-app then fails — meaning the doctor is not catching real build prerequisites. Two distinct gaps surfaced during a fresh from-source setup on an Apple-silicon machine:

1. msgfmt (GNU gettext) is not checked, but Ghostty hard-requires it.

The Ghostty build compiles its translation catalogs (.po → .mo) by invoking msgfmt as a system command (ThirdParty/ghostty/src/build/GhosttyI18n.zig:33: b.addSystemCommand(&.{ "msgfmt", "-o", "-" })). macOS does not ship msgfmt, and it is not declared in mise.toml or installed by any setup script. On a machine without it, the build fails with 29 identical errors:

error: failed to spawn and capture stdio from msgfmt: FileNotFound

make doctor passes cleanly beforehand, so there is no signal that this dependency is missing until deep into a multi-minute build. scripts/doctor.sh should check for msgfmt on PATH (and ideally point at a brew-free install path, e.g. nix profile add nixpkgs#gettext, since not everyone has Homebrew).

2. The Metal Toolchain check produces a false negative from a stale xcrun cache.

scripts/doctor.sh:72 detects the Metal Toolchain via xcrun metal --version. After a successful xcodebuild -downloadComponent MetalToolchain (which installs the toolchain as a cryptex mount under /private/var/run/com.apple.security.cryptexd/..., not into /Library/Developer/Toolchains/), xcrun metal still reported "missing" because xcrun had cached the earlier lookup failure. xcodebuild -showComponent MetalToolchain said Status: installed and the binary ran fine directly from the cryptex, yet the doctor kept failing. xcrun --kill-cache resolved it.

Suggestion: after a Metal Toolchain download, or as part of the doctor check, run xcrun --kill-cache before the xcrun metal --version probe (or detect via xcrun -f metal / xcodebuild -showComponent), so a stale cache doesn't masquerade as a missing toolchain.

Expected: make doctor should verify every prerequisite make build-app needs, so a green doctor means the build will not fail on a missing tool.

Steps to reproduce

1. On a fresh Apple-silicon machine without Homebrew and without GNU gettext installed, clone the repo and init submodules.
2. Install Xcode 26.3 alongside a newer Xcode, accept its license, and download the Metal Toolchain.
3. Run make doctor → all checks pass (✓ green).
4. Run make build-app → fails during the Ghostty build with error: failed to spawn and capture stdio from msgfmt: FileNotFound (×29).
5. Separately: immediately after xcodebuild -downloadComponent MetalToolchain succeeds, run make doctor → it still reports "Metal Toolchain missing" until xcrun --kill-cache is run.

Supacode version and build

Building from source at commit c4e28e2 (no installed app version — this is a build-tooling issue).

macOS version

macOS 26.5.2

System locale

en_PL

Mac hardware

Apple M5 Pro

Relevant logs or screenshots

msgfmt failure (repeated 29× across locales), from the tuist/ghostty build:

install
+- install generated to share/locale/tr/LC_MESSAGES/com.mitchellh.ghostty.mo
   +- run msgfmt failure
error: failed to spawn and capture stdio from msgfmt: FileNotFound
...
Build Summary: 199/260 steps succeeded; 29 failed

Ghostty invocation site:

ThirdParty/ghostty/src/build/GhosttyI18n.zig:33
    const msgfmt = b.addSystemCommand(&.{ "msgfmt", "-o", "-" });

Metal false negative:

$ DEVELOPER_DIR=/Applications/Xcode_26.3.app/Contents/Developer xcrun metal --version
error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain
$ DEVELOPER_DIR=... xcodebuild -showComponent MetalToolchain
Status: installed
# after `xcrun --kill-cache`, `xcrun metal --version` succeeds

[github-actions]

Thank you for filing this. A maintainer will review it and follow up here.

Please do not start any work or open a pull request until this issue is labeled ready. That label is a maintainer's go-ahead: a pull request opened against an issue that is not yet ready is labeled invalid until then. You will get a comment here the moment it is marked ready.

See CONTRIBUTING.md for the full flow.