What
Linux-specific compilation failures cannot be caught on the development machine. It runs macOS with no Linux Rust target installed, and the Tauri crate depends on GTK and WebKit system libraries that cross-compilation does not provide. Any platform-conditional code therefore reaches CI unverified, and CI is the only place a Linux build error can surface. This is recorded as an accepted gap, not a bug to fix.
The mitigation is procedural rather than technical: every #[cfg] on platform-specific code is reasoned through for all targets before pushing, not after CI goes red. This is weaker than a local Linux build — it depends on discipline and will fail again eventually. Closing as wontfix rather than pretending a local Linux toolchain is coming; standing up a container or VM with the GTK and WebKit dependencies is possible, but the cost of maintaining a second toolchain currently exceeds the cost of learning the same thing from CI.
Evidence
rustup target list --installed reports aarch64-apple-darwin and nothing else.
- Concrete instance, not hypothetical:
tauri::RunEvent::Reopen does not exist off macOS — it is wired from AppKit's applicationShouldHandleReopen:. The match arm (grep -rn "RunEvent::Reopen" --include="*.rs" . → lumenator/src-tauri/src/lib.rs:526) failed to compile on Linux and reached CI red. It needed a #[cfg(target_os = "macos")] gate, which is now on line 525.
- Related but a different cause: the frontend suite.
node --version reports v22.20.0; Angular requires v22.22.3+; nvm already had v26.5.0 installed. Those 298 tests had simply never been run locally. That one was self-inflicted tooling drift, not a platform limit.
What would change this
How to re-measure
rustup target list --installed
# expect: aarch64-apple-darwin only
# The next two commands change the machine — they install the very target this
# issue's premise says is absent. Run them only to re-confirm the cross-compile
# wall, then undo with the remove line so the check above still reads true.
rustup target add x86_64-unknown-linux-gnu
cargo check --manifest-path lumenator/src-tauri/Cargo.toml \
--target x86_64-unknown-linux-gnu
# expect: the GTK/WebKit -sys build scripts fail — pkg-config declines to
# cross-compile — rather than a clean check
rustup target remove x86_64-unknown-linux-gnu
node --version # expect v22.20.0 (Angular requires v22.22.3+)
nvm ls # expect v26.5.0 present; needs nvm loaded in the shell
What
Linux-specific compilation failures cannot be caught on the development machine. It runs macOS with no Linux Rust target installed, and the Tauri crate depends on GTK and WebKit system libraries that cross-compilation does not provide. Any platform-conditional code therefore reaches CI unverified, and CI is the only place a Linux build error can surface. This is recorded as an accepted gap, not a bug to fix.
The mitigation is procedural rather than technical: every
#[cfg]on platform-specific code is reasoned through for all targets before pushing, not after CI goes red. This is weaker than a local Linux build — it depends on discipline and will fail again eventually. Closing as wontfix rather than pretending a local Linux toolchain is coming; standing up a container or VM with the GTK and WebKit dependencies is possible, but the cost of maintaining a second toolchain currently exceeds the cost of learning the same thing from CI.Evidence
rustup target list --installedreportsaarch64-apple-darwinand nothing else.tauri::RunEvent::Reopendoes not exist off macOS — it is wired from AppKit'sapplicationShouldHandleReopen:. The match arm (grep -rn "RunEvent::Reopen" --include="*.rs" .→lumenator/src-tauri/src/lib.rs:526) failed to compile on Linux and reached CI red. It needed a#[cfg(target_os = "macos")]gate, which is now on line 525.node --versionreports v22.20.0; Angular requires v22.22.3+; nvm already had v26.5.0 installed. Those 298 tests had simply never been run locally. That one was self-inflicted tooling drift, not a platform limit.What would change this
How to re-measure