Skip to content

fix(tauri-build): honor CARGO_BUILD_TARGET when locating skill-daemon#79

Open
FourthWiz wants to merge 1 commit into
NeuroSkill-com:mainfrom
FourthWiz:fix/tauri-build-cargo-build-target
Open

fix(tauri-build): honor CARGO_BUILD_TARGET when locating skill-daemon#79
FourthWiz wants to merge 1 commit into
NeuroSkill-com:mainfrom
FourthWiz:fix/tauri-build-cargo-build-target

Conversation

@FourthWiz

Copy link
Copy Markdown

Summary

scripts/tauri-build.js locates the freshly built skill-daemon binary using only the explicit --target flag (explicitTarget, populated at :279-286); the CARGO_BUILD_TARGET environment variable has zero hits in the script. But cargo — invoked at :966 with the inherited env — does read CARGO_BUILD_TARGET and writes the binary under the target-triple directory. The repo's own .envrc:11-12 exports CARGO_BUILD_TARGET=aarch64-apple-darwin on macOS (and .envrc:2 says to direnv allow once after cloning), so on the documented dev setup the locator misses on every npm run tauri dev.

This PR falls back to process.env.CARGO_BUILD_TARGET before the empty triple:

const triple = explicitTarget || process.env.CARGO_BUILD_TARGET || "";

What actually breaks (and what doesn't)

Being upfront: the daemon still starts either way — resolve_daemon_bin_path() (src-tauri/src/daemon_cmds.rs:126-183) papers over the miss via its current_exe() sibling probe, and its relative candidate list even hardcodes the triple path. So this is not "the daemon is broken." What the miss does cause, on every direnv-enabled dev run:

  1. A spurious ⚠ skill-daemon binary not found after build — Tauri will attempt auto-launch warning — on the repo's own documented dev setup.
  2. killPortOwner(daemonPort) is skipped, so a stale dev daemon on the dev port is not reaped before the new run.
  3. The SKILL_DAEMON_BIN handoff is skipped (redundant in practice — see above — but skipped nonetheless).

Before/after (macOS, Apple Silicon; command: CARGO_BUILD_TARGET=aarch64-apple-darwin npm run tauri dev)

Before:

🔧 Building skill-daemon…
    Finished `dev` profile [unoptimized] target(s) in 1.42s
⚠ skill-daemon binary not found after build — Tauri will attempt auto-launch

(cargo had just written src-tauri/target/aarch64-apple-darwin/debug/skill-daemon; later in the same run the app auto-launched it anyway — the warning is spurious.)

After:

🔧 Building skill-daemon…
    Finished `dev` profile [unoptimized] target(s) in 1.51s
🚀 Starting daemon: …/src-tauri/target/aarch64-apple-darwin/debug/skill-daemon
INFO skill daemon listening addr=127.0.0.1:18445

Zero occurrences of the warning in the after-run log.

Scope note

The same explicitTarget || "" pattern occurs twice; this PR fixes both:

  • :970 — the skill-daemon locator (verified with the before/after transcript above);
  • :1091 — the macOS .app bundle lookup for widget embedding in the build subcommand (same pattern applied for consistency; the existing no-triple candidate remains as fallback, so behavior without CARGO_BUILD_TARGET is unchanged; not separately transcript-verified).

Testing

No vitest coverage exists for scripts/tauri-build.js, and a test harness for a dev script would exceed this fix's blast radius — the before/after transcripts above are the verification.

cargo reads CARGO_BUILD_TARGET from the environment and writes build
output under the target-triple directory, but tauri-build.js only
consulted the explicit --target flag when locating the freshly built
skill-daemon binary (and the macOS .app bundle for widget embedding).
With the repo's own .envrc exporting CARGO_BUILD_TARGET on macOS, every
direnv-enabled dev run hit the miss: a spurious 'skill-daemon binary
not found after build' warning, a skipped stale-daemon reap
(killPortOwner), and a skipped SKILL_DAEMON_BIN handoff.

Fall back to process.env.CARGO_BUILD_TARGET before the empty triple in
both locator sites. The daemon itself still started before and after
(resolve_daemon_bin_path papers over the miss) — the fix targets the
misleading warning and the skipped reap, not a broken daemon.
@FourthWiz
FourthWiz requested a review from eugenehp as a code owner July 16, 2026 20:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant