feat(@projects): update windows runner scope to cross-compile via cargo-xwin

Co-Authored-By: Lilith Autocommit <noreply@atlilith.com>
This commit is contained in:
Natalie 2026-04-25 17:38:40 -07:00
parent eb09af5b89
commit 535f43d921

View file

@ -1,30 +1,49 @@
---
id: p2-06b
title: Register a Windows runner for forgejo to produce .dll + .exe on tag push
title: Cross-compile Windows .exe + .dll from Linux via cargo-xwin (no Windows host)
priority: p2
status: missing
status: in_progress
scope: game1
owner: shipwright
updated_at: 2026-04-25
evidence:
- "src/simulator/build-gdext.sh (cargo-xwin invocation when TARGET=x86_64-pc-windows-msvc)"
- "tools/export-single.sh (BUILD_WINDOWS_DLL hook + .dll relocation post-export)"
- .forgejo/workflows/release.yml
- .forgejo/RUNNER_SETUP.md
---
## Summary
Godot does not cross-compile Windows binaries from a macOS or Linux EDIT host; native Windows is required to produce both the `.exe` (Godot export) and `libmagic_civ_physics.dll` (GDExtension cargo build for `x86_64-pc-windows-msvc`). Without a registered Windows forgejo runner, every release will ship Linux + macOS only.
Originally framed as "register a Windows runner". Re-scoped 2026-04-25 (user pick) to **Option B: cargo-xwin cross-compile from Linux** — produces MSVC-ABI Windows binaries on the existing Linux runner, no Windows hardware required. Better ABI compatibility than mingw (especially for wgpu's d3d12 backend) and zero hardware cost.
Spun out from p2-06 on 2026-04-25 after `p2-06-verify-20260425` confirmed the Windows export produces only a `.tmp` placeholder when run on macOS.
Recipe:
1. Linux runner installs `cargo-xwin` (one-off): `cargo install cargo-xwin`
2. Add MSVC target to rustup: `rustup target add x86_64-pc-windows-msvc`
3. Install `clang` + `lld` (xwin uses these as linker)
4. `bash src/simulator/build-gdext.sh x86_64-pc-windows-msvc` → cargo-xwin downloads MS SDK on first run (~1.5GB, cached at `~/.cache/cargo-xwin/`), builds `magic_civ_physics_gdext.dll`, copies to `engine/addons/magic_civ_physics/magic_civ_physics.x86_64.dll`
5. `bash tools/export-single.sh windows <ver>` → Godot Linux exports the Windows .exe (cross-export is native to Godot), the script then relocates the .dll into `engine/addons/magic_civ_physics/` next to the binary
`.forgejo/workflows/release.yml` retargeted to `runs-on: [self-hosted, linux, x86_64]` with a "Setup MSVC cross-toolchain" step.
## Acceptance
- ❌ A Windows runner is registered in forgejo (RUNNER_SETUP.md updated with the new runner instructions).
- ❌ `.forgejo/workflows/release.yml` has a Windows job that runs cargo + Godot export and uploads `MagicCivilization.exe` + `libmagic_civ_physics.dll` as part of the release bundle.
- ❌ A tag push produces a release containing all three desktop platforms (Linux .so + binary, macOS .dylib + .app, Windows .dll + .exe).
- ❌ Windows archive boots-and-plays a 10-turn AUTO_PLAY game on a Windows machine.
- ✓ `tools/export-single.sh windows` runs the cargo-xwin build inline (`BUILD_WINDOWS_DLL=1` default) and relocates the produced .dll into `engine/addons/magic_civ_physics/` post-export. (2026-04-25)
- ✓ `src/simulator/build-gdext.sh x86_64-pc-windows-msvc` invokes `cargo xwin build` and copies the .dll to `engine/addons/magic_civ_physics/magic_civ_physics.x86_64.dll`. (2026-04-25)
- ✓ `.forgejo/workflows/release.yml` `windows_build` job uses Linux runner with cross-toolchain setup step. (2026-04-25)
- ❌ Apricot has cargo-xwin + clang + lld + the MSVC target installed (one-off setup).
- ❌ End-to-end smoke: `bash tools/export-single.sh windows p2-06b-verify-<stamp>` on apricot produces a `.exe` + `.dll` archive.
- ❌ Windows archive boots-and-plays a 10-turn AUTO_PLAY game (verified on Wine on apricot, OR on a real Windows machine).
- ❌ Update `.forgejo/RUNNER_SETUP.md` to drop the Windows runner section and document the Linux-runner cross-compile prereqs.
## Non-goals
- Windows code signing (separate later objective).
- Windows installer (.msi / .exe self-extractor) — direct .zip is fine for EA.
- mingw-w64 GNU toolchain path (Option A); kept as fallback if xwin proves too fragile but not pursued.
## Caveats
- cargo-xwin's first build downloads ~1.5GB of MS SDK; cache it on the runner (`~/.cache/cargo-xwin/`).
- `wgpu 24` (in `mc-compute`, gated by `gpu` feature) uses d3d12-rs on Windows — should link cleanly under MSVC ABI. If linker errors surface, build the Windows .dll with `--no-default-features` to drop the GPU MCTS path; Game 1 ships fine without it (CPU rollouts only).
- Wine smoke is acceptable for the boots-and-plays gate as long as the .pck loads, GDExtension classes register, and AUTO_PLAY reaches a turn-end without errors.