A store engine reads a WarpEngine catalog and writes some host's own game
library format. Only that last step is about the host: the catalog, the
release selection, the machine matching, the state and the HTTP were the
same code in every engine, and until now there was one engine, so they
lived inside it.
A second engine — RetroArch — made the seam visible, so the shared part
moves here as a single file both engines fetch at install time. An adapter
now supplies three things: a DEFAULT_CONFIG describing its host, an
accept() callback deciding which catalog entries that host can run, and
the code that writes the host's library format.
Two generalisations came out of having two hosts rather than one:
- `resolve_for_arch` becomes `resolve_for_host`. Batocera only ever
answered "linux", so architecture was the only variable; a RetroArch
host can be Windows, macOS or Android, and that decides such things as
what a libretro core file is called. Keys are now os-arch, arch, os, *.
- state records are keyed by `scope`, not by ES `system`. For Batocera the
two are the same string, so an installed box keeps working without a
migration — `record_scope()` falls back to `system` for records written
before this existed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
