COCKATRICE_WIN_INSTALLER chooses which tool writes the Windows installer.
NSIS stays the default, so nothing on the existing path changes; InnoSetup
selects CPack's own INNOSETUP generator (CMake >= 3.27) and builds from the
same install() rules. Both can be built from one tree and the resulting
installers compared on an upgrade from 3.1.x.
What the Inno path does differently:
- Installs over the previous version instead of running the old uninstaller
first, which is what the backup/restore pair in the NSIS template exists
to survive.
- Closes and restarts a running application through Windows Restart Manager
(CloseApplications/RestartApplications) instead of the two PowerShell
process guards the template needed.
- Removes stale runtime with one [InstallDelete] of *.dll and Plugins,
instead of RetryDllPurge and its diagnostics.
- Writes a log on every run through SetupLogging, instead of CockLog.
- Resolves the install directory from the legacy NSIS registration, and
deletes that registration after a successful install so the old
uninstaller (whose blanket directory removal caused the 3.1.x data loss)
cannot be run after the upgrade.
- Keeps the portable mode the client detects, the C++ runtime bootstrap and
the /PORTABLE switch.
The in-app updater still passes the NSIS switches (/R, /PID=); the installer
logs them so the first Windows run settles whether Inno Setup accepts them or
the switch-over needs a client version gate.
The installer content check in .ci/compile.sh learns to strip Inno Setup's
{app} prefix from the paths 7-Zip lists, so the required-runtime comparison
works for either archive format.