mirror of
https://github.com/Cockatrice/Cockatrice.git
synced 2026-11-05 09:33:25 -08:00
2c8e47a0a4
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.
23 lines
1.5 KiB
Text
23 lines
1.5 KiB
Text
; Sections added to the setup script CPack's Inno Setup generator writes.
|
|
;
|
|
; Included through CPACK_INNOSETUP_EXTRA_SCRIPTS, which prepends this file to the
|
|
; generated script. Only sections the generator never emits may appear here: it writes
|
|
; [Files], [Dirs], [Icons], [Run] and [Registry] from the install() rules, and a second
|
|
; section of one of those is a compile error. Behaviour belongs in InnoSetup.code.iss.
|
|
|
|
[InstallDelete]
|
|
; The previous version's runtime, whatever it was called. Replacing a DLL in place is not
|
|
; enough: a module the payload no longer carries (Qt6Multimedia.dll while it was still
|
|
; shared, Qt6QuickWidgets.dll) would survive the install and then be loaded next to the new
|
|
; executable, which is the "procedure entry point ... could not be located" failure after
|
|
; an update. Removing every DLL and letting the payload put its own back is what the NSIS
|
|
; RetryDllPurge did with 250 lines of retry and diagnostics; with CloseApplications on,
|
|
; Restart Manager has already released the handles, so one pass is enough.
|
|
Type: files; Name: "{app}\*.dll"
|
|
; Plugins are loaded by name from this directory, so a stale one is just as fatal and is
|
|
; not covered by the payload's own file list.
|
|
Type: filesandordirs; Name: "{app}\Plugins"
|
|
; The NSIS uninstaller. Its Add/Remove Programs registration is deleted after a successful
|
|
; install (RemoveLegacyNSISRegistration in InnoSetup.code.iss); the binary itself has no
|
|
; business staying next to the new one.
|
|
Type: files; Name: "{app}\Uninstall.exe"
|