Dominik Roth
23615a8c92
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>
71 lines
3.5 KiB
Markdown
71 lines
3.5 KiB
Markdown
# 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](https://github.com/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
|
|
|
|
```bash
|
|
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.
|