dodox/FEnigma
dodox/FEnigma
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Confirm the Windows build pipeline works end to end: real .msi produced

Browse Source 
The -arch x64 fix (previous commit) is confirmed live: build_errorlevel=0,
BUILD_DONE, a real 958MB FEnigma-0.1.0.msi written to Z:\dist -- the
first ever fully successful build this pipeline has produced. Copied
to dist-windows/FEnigma-0.1.0.msi (gitignored).

Not yet installed/launched on a real Windows machine to confirm the
app actually runs -- packaging succeeding isn't the same claim as the
app working once installed, per this repo's own README note. Logged
as the next thing to check, along with light.exe's own ~15-18min
runtime now that there's a clean build to measure it against.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Dominik Moritz Roth 2026-08-13 23:21:55 +02:00
parent d66b881239
commit bc74d62774
1 changed files with 19 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
TODO.md
View File

@ -306,7 +306,7 @@ each confirmed live against the real VM, not just read off a diff:
(process was active, 343MB working set, not hung on a dialog), (process was active, 343MB working set, not hung on a dialog),
not a real bug: retried with a 40-minute budget and it finished not a real bug: retried with a 40-minute budget and it finished
`light.exe` itself in a few more minutes. `light.exe` itself in a few more minutes.
- [ ] ...and then failed for a REAL reason right at the very end: - [x] ...and then failed for a REAL reason right at the very end:
`light.exe`'s ICE80 validation rejected essentially every `light.exe`'s ICE80 validation rejected essentially every
harvested file -- "This 32BitComponent ... uses 64BitDirectory". harvested file -- "This 32BitComponent ... uses 64BitDirectory".
`product.wxs`'s own `INSTALLFOLDER` is correctly under `product.wxs`'s own `INSTALLFOLDER` is correctly under
@ -325,14 +325,24 @@ each confirmed live against the real VM, not just read off a diff:
(`product.wxs`) or harvested (`files.wxs`) alike, the standard (`product.wxs`) or harvested (`files.wxs`) alike, the standard
WiX v3 way to make a whole package consistently 64-bit. Kept the WiX v3 way to make a whole package consistently 64-bit. Kept the
harmless-but-insufficient `-platform x64` on `heat.exe` too. harmless-but-insufficient `-platform x64` on `heat.exe` too.
Applied, NOT YET re-verified live (this session's VM time is
long since past reasonable for one sitting -- next run should **CONFIRMED live**, third attempt: `build_errorlevel=0`,
confirm a real `.msi`, but treat that as still unconfirmed until `BUILD_DONE`, and a real 958MB `FEnigma-0.1.0.msi` written to
it actually happens). `Z:\dist` -- the first ever fully successful build this pipeline
Once confirmed, revisit the still-slow `light.exe` step itself has produced. Copied to `dist-windows/FEnigma-0.1.0.msi` in the
(the ~1GB+ bulk-copied mingw64 dist tree, see README's own "not repo root (gitignored, same as `build_windows.sh` itself would
lean" note) as a separate, real perf follow-up -- 40 minutes for do). NOT yet installed/launched on a real Windows machine to
one MSI link is a lot, even once it stops failing outright. confirm the app actually runs (see the "Not tested against a
real GTK4/libadwaita Windows install at all" line in this repo's
own `packaging/windows/README.md` -- still true, packaging
succeeding is not the same claim as the app working once
installed).
Follow-up, now that a clean build exists to measure against:
`light.exe` alone took ~15-18 minutes even with ICE80 fixed --
revisit the ~1GB+ bulk-copied mingw64 dist tree (README's own
"not lean" note) as a real perf issue, not just a packaging-
correctness one.
## OCR: new fire-support-request grammar gaps (from real user-pasted messages) ## OCR: new fire-support-request grammar gaps (from real user-pasted messages)