Commit graph

1 commit

Author SHA1 Message Date
Lukas Brübach
2c8e47a0a4 [Installer] Add an Inno Setup generator next to NSIS.
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.
2026-10-26 07:52:44 +01:00