Improvements to the msi isntaller

[karlstav]

@amnweb, I don't think the new installer mentions the c++ runtime requirement. If not, windows people will keep coming in here and creating issues like "cava does not work", with no additional context what so ever.

It would be nice if it could include the text from here:

https://github.com/karlstav/cava/blob/master/cava_win/postsetupinfo.txt

like the old installer did. I tried to figure out how, but the docs for this seems to be mostly about other stuff than the installer.

Also, I do have icons, for the android app:

https://github.com/karlstav/cava/blob/master/cavandroid/app/src/main/res/mipmap-xxxhdpi/ic_launcher.webp

can one of those be used? It would be nice with a shortcut, I think the old installer created it and it was convenient. It launches itself in the terminal without issues.

also this will not fly in the future:

cava/.github/workflows/build-and-test.yml

Line 119 in 01bdbd5

$versionLine = Select-String -Path cava_win\setup.iss -Pattern '^AppVersion=' | Select-Object -First 1

it just grabs the old hard coded version from the iss file, I was going to delete that file now that we have the wxs installer. It would be best if it could get the version like linux does it:

cava/autogen.sh

Line 6 in 01bdbd5

git describe --always --tags --dirty >version # get version from git

if the tag is added after the commit is pushed the workflow might get the previous tag though, might be best to use the hard coded version from the autogen.sh file. We could change the autogen.sh script to make it easier to parse the version sting.

This is only if you have time for it! I could fix it myself at some point, but I am not using windows much these days.

[amnweb]

Yeah, we can include app icon, but we will need to convert them to .ico format. I can do that. About the C++ redistributable, this is almost always part of Windows installation, but I’m not sure about older Windows 10 versions. Yeah, we can get the version from Git. Give me a few days, I’ll get back to the workflow to do all this. I’m busy right now with some other stuff

[amnweb]

@karlstav I've addressed all the points from this issue. Here's what I did:

C++ runtime requirement.
Instead of just mentioning it in the installer, I eliminated the dependency entirely by switching to static linking (x64-windows-static vcpkg triplet + static CRT). All libraries (SDL2, FFTW3, GLEW, pthreads) are now baked into a single cava.exe. No DLLs at all, no VC++ Redistributable needed. The MSI now only installs cava.exe.

App Icon
Added app.ico to the resource file so cava.exe shows the icon in Explorer/taskbar, and also added it to the MSI so it shows in Add/Remove Programs.

Shortcuts
Desktop and Start Menu shortcuts are now created by the installer (with the cava icon), matching the old InnoSetup behavior.

Post-setup info
The installer exit dialog now shows: Config file for cava is created in "%USERPROFILE%\.config\cava" upon first launch. the VC++ Redist note is no longer needed since we're static linking.

Version from autogen.sh
The workflow now parses the version from autogen.sh (echo X.Y.Z >version line) instead of setup.iss, so that file can be safely deleted.

PR #760

[karlstav]

Interesting! I did tinker with static linking on windows in the beginning. Not sure why I abandoned it. Didn't get the required binaries through nuget maybe.

Statically linking the crt is discouraged by some (size and security), but I can't see a good reason why not in this case.

How large did the release exe become?

With a portable single exe I wouldn't be a stranger do just abandoning the installer all together and just hosting the exe.

[amnweb]

With a portable single exe I wouldn't be a stranger do just abandoning the installer all together and just hosting the exe.

That’s a bad idea. The installer automatically handles the PATH environment variable, which is required by some apps like YASB and Windows Terminal. How can I run the cava command in Windows Terminal if cava.exe is not added to the PATH?

Now everything is automatic. When the user installs Cava, the PATH is added and configured. When they update to a new version, we use the same GUID in the installer config file, which handles everything correctly and replaces the old Cava with the new one.

Edit: But of course, you can ship it as portable, but you will need to tell users that if they want to use it with other apps, they will need to configure environment variables

[karlstav]

That is true. I don't use windows that much. I would guess people would just add it to their environment themselves. But let's stick with the installer.

[nivx18818]

That is true. I don't use windows that much. I would guess people would just add it to their environment themselves. But let's stick with the installer.

I'm using Scoop as my package manager, it can handle PATH configuration. So, shipping a portable version is still a nice option, I can then stay up-to-date with Scoop.

[amnweb]

That is true. I don't use windows that much. I would guess people would just add it to their environment themselves. But let's stick with the installer.

I'm using Scoop as my package manager, it can handle PATH configuration. So, shipping a portable version is still a nice option, I can then stay up-to-date with Scoop.

Scoop allows MSI, so there is no problem at all.

[nivx18818]

Scoop allows MSI, so there is no problem at all.

Makes sense, but MSI installs aren’t really “portable” cuz they scatter files and modify PATH. Scoop feels cleaner with its shim-based approach. A portable version isn’t required, but it’d be a nice future addition.

[amnweb]

Scoop allows MSI, so there is no problem at all.

Makes sense, but MSI installs aren’t really “portable” cuz they scatter files and modify PATH. Scoop feels cleaner with its shim-based approach. A portable version isn’t required, but it’d be a nice future addition.

Scoop will extract the MSI, and you will get exactly the same as the portable version.