Skip to content

fix(release): add the cross-compile target to the pinned toolchain, not stable - #245

Merged
filipeforattini merged 1 commit into
mainfrom
worktree-fix+macos-intel-pinned-toolchain-target
Jul 31, 2026
Merged

filipeforattini merged 1 commit into
mainfrom
worktree-fix+macos-intel-pinned-toolchain-target

Conversation

@filipeforattini

@filipeforattini filipeforattini commented Jul 31, 2026

Copy link
Copy Markdown
Contributor

Follow-up to #244. The v0.65.0 release shipped Linux x86_64/aarch64, macOS aarch64 and Windows x86_64 — the optional + verify-assets design did its job — but the new macOS Intel leg failed, as flagged.

The failure

failed to build app: Target x86_64-apple-darwin is not installed
  (installed targets: aarch64-apple-darwin)

…even though dtolnay/rust-toolchain ran with targets: x86_64-apple-darwin and exited 0. The log confirms it executed:

rustup toolchain install stable --target x86_64-apple-darwin --profile minimal --no-self-update
  stable-aarch64-apple-darwin updated - rustc 1.97.1

apps/desktop/src-tauri/rust-toolchain.toml pins channel = "1.95.0", and rustup's directory override wins inside that directory. So the target landed on stable (1.97.1) while the build ran under 1.95.0 — and the error's "installed targets" list is 1.95.0's, not stable's.

Native legs never surfaced this, because a toolchain always has its own host target. Only a cross-compile can notice.

Reproduced locally:

$ rustup show active-toolchain            # repo root
stable-x86_64-unknown-linux-gnu (default)
$ cd apps/desktop/src-tauri && rustup show active-toolchain
1.95.0-x86_64-unknown-linux-gnu (overridden by '.../rust-toolchain.toml')

Fix: add the target by running rustup target add with working-directory: apps/desktop/src-tauri, so it lands on the toolchain that actually builds.

Also, from ../dit

Arch detection was wrong$env:PROCESSOR_ARCHITECTURE describes the process, not the machine. On Windows on ARM an emulated x64 PowerShell reports AMD64, so an arm64 host looked like a plain x64 one and never got the emulation note. Now uses RuntimeInformation::OSArchitecture, like dit's installer.

Worth noting: OSArchitecture spells it X64, not AMD64 — verified live in a pwsh container. A naive swap would have sent every x64 machine down the default branch and hard-failed the installer. The match accepts both spellings, and all branches are exercised.

Docs: dit's & ([scriptblock]::Create((irm ...))) -Version ... form passes parameters in one line. Replaces my "download the script first" instruction, since iex takes no parameters — verified the scriptblock actually binds -Version/-Force.

Verification

  • install.ps1 parses under pwsh 7.4; full flow re-run against the live v0.65.0 release: tag resolves, real .exe downloads, sha256 verifies, tampered file rejected
  • Arch branch table checked against the values OSArchitecture really emits (X64/Arm64/X86/ARM)
  • Prettier clean

The macOS Intel leg stays optional until it goes green once in a real release.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

…ot stable

The macOS Intel leg failed its first run with "Target x86_64-apple-darwin is
not installed (installed targets: aarch64-apple-darwin)" even though
dtolnay/rust-toolchain ran with `targets: x86_64-apple-darwin` and exited 0.

apps/desktop/src-tauri/rust-toolchain.toml pins channel 1.95.0, and rustup's
directory override wins inside that directory — so the target was added to
`stable` (1.97.1) while the build used 1.95.0, whose target list is exactly
what the error printed. Native legs never noticed: a toolchain always has its
own host target. Add the target by running rustup where the override applies.

Also, from ../dit:

- Detect the OS architecture via RuntimeInformation::OSArchitecture instead
  of $env:PROCESSOR_ARCHITECTURE, which describes the *process*. On Windows
  on ARM an emulated x64 PowerShell reports AMD64, so an arm64 host looked
  like plain x64 and never got the emulation note. Note OSArchitecture spells
  it "X64", not "AMD64" — the match accepts both spellings.
- Document the scriptblock form for passing options in one line, since `iex`
  takes no parameters. Beats telling people to download the script first.
@filipeforattini
filipeforattini merged commit 48a1a78 into main Jul 31, 2026
3 checks passed
@filipeforattini
filipeforattini deleted the worktree-fix+macos-intel-pinned-toolchain-target branch July 31, 2026 10:31
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