Neither packaging/arch/PKGBUILD nor the Homebrew formula had been run
since Phase 1, and both were still calling v2's CLI: `wails3 build`
takes -tags, -obfuscated and -garbleargs and nothing else, so
`-clean -trimpath -ldflags` fails at the flag parser. Both also
installed from build/bin/, which is v2's output path — v3 writes to
bin/, and build/ is tracked build assets now.
Three more things the tree needs that neither recipe had. The tasks
invoke `wails3` by bare name, so scripts/toolbin has to be on PATH or
the build dies at its first sub-task. `wails3 build` has no -ldflags at
all, and build:native computes BUILD_FLAGS in its own vars: so a CLI
variable cannot override it — LDFLAGS_EXTRA is appended inside the
production -ldflags string instead, on linux and darwin alike, empty by
default so make build-dev/build-prod are unchanged. And bundling is a
separate step from building: `task build` produces a bare binary on
both platforms, so the formula's macOS path runs `task package`.
The build assets were the scaffold's, not this app's. Info.plist named
CFBundleExecutable `yjref` and com.example.yjref, nfpm packaged
./bin/yjref, the .desktop template said "A yjref application" — an .app
built from that plist would not have launched. They generate from
build/config.yml, whose info block had never been filled from
wails.json either; `wails3 task common:update:build-assets` is the fix.
nfpm's homepage and license are not derived from it and are set by
hand, which is noted in place, and the refresh regenerates build/ios
and build/android, which this repo does not carry.
arch-package.yml's pacman list moves to webkitgtk-6.0/gtk4 to match the
PKGBUILD's depends(): makepkg installs nothing itself, so a mismatch
fails at link time rather than at check time.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm
Phase 1 of plan 009. The app still builds and runs on v2 — nothing in
main.go or backend/ has moved yet — but the v3 CLI, its pinned runtime
and its build-asset tree are now present, which is what Phase 2 needs.
- wails/v3 v3.0.0-beta.8 pinned per D5, and wails3 added to the `tool`
block beside the v2 CLI per D3. Both are vendored; neither is a
global install.
- build/ now holds the v3 build assets, copied wholesale from a
`wails3 init` scaffold rather than hand-written. That collides with
this repo's existing use of build/ as ignored build *output*, so
.gitignore narrows to build/bin/ and bin/ and the assets are tracked.
The mobile platforms are not carried: this is a desktop player
(MPRIS over D-Bus, beep, XDG paths) and cannot target them.
- build/config.yml's info block is filled from wails.json, which stays
for now because the v2 CLI still reads it.
- Taskfile.yml defaults PACKAGE_MANAGER to pnpm, since the scaffold
assumes npm and frontend/package.json.md5 is part of the dep-caching
scheme.
One deviation from the plan worth recording. webkitgtk-6.0 is not
installed on this machine, so the default GTK4 path is unavailable and
the gtk3 fallback is in use. That also means `go tool wails3` does not
work — the CLI itself fails to compile without webkitgtk-6.0 — while
`go run -tags gtk3 .../cmd/wails3` does. The Makefile rewrite in the
next commit has to account for that, and it goes away once the GTK4
dependency is installed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm
yonluandClaude Opus 5
logan