dodox/FEnigma
dodox/FEnigma
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
bd69b183ad
FEnigma/packaging/windows/README.md
Dominik Roth 23615a8c92 Fix id-namespace regression, add StrikeRequest type, kill full-panel 
rerender on assign/alive/shell, add Windows build tooling

- Board.add_target/add_ally's id auto-assignment used a bare
  next(c for c in string.ascii_uppercase if c not in used), which
  raises StopIteration once 26 entities of a group exist -- a real
  crash confirmed via a live traceback, and a direct regression from
  moving that sequence from per-type to per-group. This was the actual
  cause of "Accept as"/"Accept all" silently doing nothing. Fixed with
  _next_free_id(), which rolls over to two-letter ids instead of
  raising.
- New TargetType.STRIKE_REQUEST: the bearing/distance-offset "taking
  fire" fire-support request (see the earlier two-entity split) now
  creates this instead of reusing STRIKE, so a radioed-in request is
  never confused with a strike the player placed themselves. Same
  crosshair icon, excluded from type pickers/dedupe like STRIKE.
- The "Accept as..." popover on a detected map marker now uses the
  same icon grid the entity-edit "Change type" popover does (was a
  plain unfiltered text list of every TargetType, which also wrongly
  offered STRIKE/STRIKE_REQUEST as pickable).
- Firing panel: _cycle_assignment/_toggle_alive/_pick_shell no longer
  route through app.py's full solver+dedupe+canvas+panel refresh --
  none of the three can affect the solver or dedupe, and none change
  which cards exist or their order (except _toggle_alive in
  hide/sort_later mode). New FiringPanel._rebuild_one() rebuilds just
  the one changed card; on_visual_change is a new, lighter callback
  (just a map redraw) for the two of these three that actually affect
  it. This was a real, confirmed lag source with many units on the
  board: every click on any of these was previously rebuilding every
  card of every target.
- Map right-click entity menu: added "Mark destroyed"/"Mark alive",
  reusing the same cheap-refresh path (new
  FiringPanel.refresh_after_alive_change).
- packaging/windows/: a from-scratch (untested against a real boot)
  MSYS2 + WiX .msi build pipeline for Windows, driven from Linux via
  dockur/windows (KVM-in-container), no Windows machine or GitHub
  required. See its own README for status/caveats.
- New/updated tests: id-namespace sharing + the 26-entity overflow
  regression (tests/test_models.py), StrikeRequest split
  (tests/test_ocr.py), warp_to_map's img_scale param
  (tests/test_map_vision_warp.py). 44/44 passing.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-11 20:48:57 +02:00

3.5 KiB
Raw Blame History

Windows .msi build (via dockur/windows)

Builds a Windows installer for FEnigma on a Linux host with no Windows machine and no GitHub, by booting a real Windows VM inside a container (dockur/windows, QEMU+KVM under the hood, no license key needed for the eval install it fetches automatically) and driving the whole build over a shared folder.

Status: written, not yet run against a real boot. Everything here follows dockur/windows's and WiX's documented mechanics, but there's no KVM/Windows available in the environment this was authored in to actually exercise it end to end. Treat the first run as a debugging session, not a push-button success — watch it happen at http://localhost:8006 (dockur's noVNC viewer) so you can see where it's stuck if it stalls.

How it fits together

  • docker-compose.yml — boots the VM. Needs /dev/kvm on the host.
  • oem/install.bat — one-time provisioning, auto-run by Windows's own unattended setup on first boot (dockur/windows's /oem mechanism): installs MSYS2, then GTK4/libadwaita/PyGObject/numpy/Pillow/OpenCV/ Tesseract through it, plus the WiX v3 toolset, and registers a boot-time watcher task. This is the slow part (Windows install itself, then package downloads) and only ever happens once — it lives on the VM's persistent disk (./storage, gitignored) from then on.
  • oem/watch_build.bat — runs at every boot from here on, polls the shared Z:\ drive for a build request.
  • oem/build.bat — the actual per-build packaging: assembles a dist tree (bundled MSYS2 mingw64 runtime + the fenigma package), harvests it into WiX components with heat.exe, and links it into an .msi with candle.exe/light.exe.
  • oem/product.wxs — the hand-authored shell around that harvested file list: install directory, Start Menu shortcut, and the PYTHONPATH environment variable the shortcut needs (mirrors run.sh's PYTHONPATH=src python -m fenigma.app).
  • build_windows.sh — run this. Starts the VM, copies ../../src onto the shared folder, drops a request file, waits for the .msi to come back, copies it to ../../dist-windows/.

Running it

cd packaging/windows
./build_windows.sh [version]

First run: full unattended Windows install + provisioning, likely 30-90 minutes, unattended (no interaction needed, but it needs to actually finish — don't kill it early). Every run after that: just boot the already-provisioned VM and build, a few minutes.

Requires /dev/kvm (virtualization enabled, your user in the kvm group) and Docker with Compose.

Known rough edges / likely follow-up work

  • The dist tree is fat, not lean. build.bat bulk-copies the entire mingw64/ runtime rather than tracing the actual DLL/typelib/icon- theme/schema dependency closure of the app — reliable, but probably 1GB+. Trimming it (e.g. by walking pythonw.exe's and the compiled extension modules' actual dependencies) is a real but separate project.
  • heat.exe's default harvest options are a starting guess for a tree this large and this GTK-specific (icon caches, gschemas, typelibs); it may need -t transforms or manual exclusions to produce a working component set.
  • Not tested against a real GTK4/libadwaita Windows install at all — MSYS2 ships these, but this is the first time this specific app has been pointed at them; expect a missing-DLL or schema error on first actual launch, not just a packaging error.
  • No code signing — Windows will show an "unknown publisher" warning.