dtourolle
43f70c4765
The fourth leg of build-and-test.yml, in the shape of the Android one: an image workflow that builds docker/windows and pushes it tagged by the directory's tree id, and a job inside that image that lints the Windows target — the only place the cfg(windows) branches are ever compiled by CI — builds, runs the smoke tests docs/windows.md §6 specifies, packages, installs and uninstalls under Wine, and uploads the installer. Every step was run by hand in the same container first. The spec's open list closes with this: the four §3.2 items, the licence page, and the leg. What remains is what Wine cannot show, and §10 now lists it as the first real Windows run's checklist.
62 lines
2.9 KiB
Markdown
62 lines
2.9 KiB
Markdown
# Windows cross-build environment
|
|
|
|
Reproducible container for building the Windows executable and its installer from Linux. The
|
|
specification is [docs/windows.md](../../docs/windows.md); this directory is what it turned into,
|
|
and every departure from the spec's first draft is recorded in the Dockerfile's comments.
|
|
|
|
## Use
|
|
|
|
```bash
|
|
# Cross-compile the desktop application
|
|
./docker/windows/build.sh cargo build --release --target x86_64-pc-windows-gnu -p darkroom-desktop
|
|
|
|
# Lint the cfg(windows) branches, which the Linux job never sees
|
|
./docker/windows/build.sh cargo clippy --target x86_64-pc-windows-gnu -p darkroom-desktop -- -D warnings
|
|
|
|
# Build the installer from that binary
|
|
./docker/windows/build.sh docker/windows/package.sh
|
|
|
|
# Smoke-test under Wine (docs/windows.md §6)
|
|
./docker/windows/build.sh wine target-windows/x86_64-pc-windows-gnu/release/darkroom-desktop.exe --version
|
|
./docker/windows/build.sh wine target-windows/installer/DarkRoom-0.12.0-x86_64-setup.exe /S
|
|
|
|
# Interactive shell
|
|
./docker/windows/build.sh
|
|
|
|
# After editing the Dockerfile
|
|
./docker/windows/build.sh --rebuild
|
|
```
|
|
|
|
Prefers `podman`, falls back to `docker`. The cargo registry, the target directory and the Wine
|
|
prefix persist under `~/.cache/darkroom-windows/`, so a warm rebuild is minutes and the first
|
|
`wineboot` happens once.
|
|
|
|
## What is verified here, and what is not
|
|
|
|
Measured on the first build, 2026-09-12:
|
|
|
|
| Check | Result |
|
|
|---|---|
|
|
| `cargo build --target x86_64-pc-windows-gnu -p darkroom-desktop` | Links. 115 MB, `PE32+ … (GUI)` |
|
|
| DLL imports | 26 Windows system DLLs; **no** `libwinpthread-1.dll`, `libgcc_s`, `libstdc++` |
|
|
| `wine darkroom-desktop.exe --version` | `darkroom-desktop 0.12.0`, exit 0, 0.1 s |
|
|
| `makensis` | 105 MB `DarkRoom-<version>-x86_64-setup.exe`, 64-bit stub |
|
|
| `wine setup.exe /S` | Installs exe + 7 models to `AppData\Local\Programs\DarkRoom`, writes the `HKCU` uninstall key; the installed exe runs |
|
|
| `wine uninstall.exe /S` | Removes the directory and the key |
|
|
| Start Menu shortcut | **Not verifiable here.** `CreateShortcut` is `IShellLink` and does nothing under a headless Wine; the directory beside it is created. Check on Windows. |
|
|
|
|
Also checked by running the application itself under Wine: its log lands in
|
|
`AppData\Local\darkroom\state`, and nothing is written outside `AppData` (FR-PLAT-WIN-1).
|
|
|
|
None of this proves a Vulkan device opens, a render completes, fonts are found, the secret store
|
|
round-trips or the browser opens for sign-in. Those are a Windows machine, once per release.
|
|
|
|
## In CI
|
|
|
|
`.gitea/workflows/windows-image.yml` builds this image and pushes it to
|
|
`gitea.tourolle.paris/dtourolle/darkroom-windows`, exactly as the Android image is handled — tagged
|
|
by the tree hash of `docker/windows/`, rebuilt when and only when a file here changes. The
|
|
`windows` job in `build-and-test.yml` then runs, inside it, the same commands listed above plus
|
|
`cargo clippy --target x86_64-pc-windows-gnu -- -D warnings`, and uploads the installer as an
|
|
artefact.
|