5 Commits
Author SHA1 Message Date
yonluandClaude Opus 5 cad3d1339b fix(packaging): put the release recipes on v3's build
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
2026-08-14 23:09:24 -04:00
yonluandClaude Opus 5 453d5df0da fix(build): put wails3 on PATH for the Taskfile supervisors
`make sandbox`, `make dev`, `make build-dev` and `make build-prod` all
died with "/bin/sh: wails3: command not found". `wails3 dev` and
`wails3 task` are supervisors: they run the scaffold's Taskfile tree,
which invokes `wails3` by bare name in 54 places across four files. The
CLI is a vendored Go tool by design (plan 009, D3 — a global install
would be this build's first undeclared dependency), so that name did
not exist.

scripts/toolbin/wails3 execs `go tool wails3`, and the Makefile
prepends that directory only for the targets that start a supervisor.
Rewriting 54 scaffold call sites would be churn to redo on every
scaffold refresh; nothing global is installed either way.

The shim does not cd. The first version did, to be sure `go tool` found
the module — it does not need to — and that silently discarded the
`dir:` a task had set, so generate:icons failed with "open
appicon.png: no such file or directory" against a file that was there.

Three things the build path needed once it got that far:

- `frontend/package.json` gains `build:dev`, which build:frontend runs
  under DEV=true and which did not exist.
- Vite binds 127.0.0.1. It defaulted to `localhost`, which resolves to
  `[::1]` only here, while wails3 dev's asset proxy dials IPv4 — so the
  first request for the dev server was refused and the first paint
  raced a retry. Zero proxy errors after.
- The icons and the .desktop file are generated on every build.
  icons.icns/icon.ico are deterministic from our appicon.png (verified
  by regenerating), so the regenerated pair is committed and the churn
  ends; .task/ and the .desktop file are ignored.

Also corrects a claim: build-prod strips and trims but does **not**
UPX-compress — that was v2's `-upx` flag. Phase 1 recorded UPX as
still working, but neither build target had been run.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm
2026-08-14 22:49:16 -04:00
yonluandClaude Opus 5 e7873bded3 build(wails): add the v3 toolchain alongside v2
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
2026-08-14 13:39:20 -04:00
logan 5097a6472a removed build dir 2025-03-24 20:09:22 -05:00
logan abb60cb96a initial commit 2025-03-19 16:45:13 -05:00