I was thinking about windows installer build

[mattiasmaahl]

So I was thinking about the windows installer and that this installer need the vcredist package added to the installer to accommodate the "missing" dll's in older windows versions, i.e windows 7.

should we create a project/repository, much like the "debian-package", for the windows installer as well?
my thinking here is that it's not ideal that the vcredist.exe file is included in the main project because it does not provide any functionality to the application other than the installer for windows? so maybe move the windows installer specific stuff into it's own project/repository to separeate them from the source in a much cleaner way?

What is your opinion on the matter? let me know.

I volunteer to maintain and build the windows installer for releases if need be.

[matty0ung]

Would an alternative be to use something like https://installbuilder.com/qt-developers.html? It seems that app packaging ought to be a "solved problem" where we don't have to write too much boilerplate code. (They say they offer free licensing for open source projects: https://installbuilder.com/open-source-licenses.html But of course I'm sure there are lots of alternative products too that do a similar job. I don't know which one would be best for us. InstallBuilder just came up in my search because it mentions Qt.)

[mattiasmaahl]

I see your point and we do already have the NSIS installer, with all its quirks, running.

My initial thought was that the windows version of Brewtarget needs some DLLs that are present in Windows 10 and NOT present in Windows 7, this is amended by installing the vcredist-package from MSoft, version 14-something-something, this binary is now located in the main project tree and does not provide any functionality to the project other than being included in the NSIS installer when creating it.
So I was thinking that maybe this binary and other windows installer specific files could reside in its own repository instead of cluttering the main application.

I like the idea that we could have a "on installer generator to rule them all" kind of thing, but feel like this would turn the whole release/installer "generating"(<-is that a word?) thing up-side-down, bringing with it a ton of refactoring on the build process.

The NSIS installer is somewhat tedious to work with and not always that easy to understand how to manipulate to the developers will, and I agree that there must be an easier way to do this.

I will study the above installbuilder closer, but at first glance I did not see the c++ support, they wrote a bunch about Java, but I have not read through all the information yet though! 😊
EDIT: Nevermind, found the c++ support! 😂

[mattiasmaahl]

After reading through the Installbuilder mentioned above, I do believe it to be a real alternative, need testing though, I may be able to do some initial testing during the holidays but the relatives do poke for attention! 😂🎅

let's keep looking though to find what alternatives there are and I would like to have @mikfire thoughts on the matter as well.

[matty0ung]

Yes, +1 for @mikfire input. My main goals would be (a) minimise boilerplate work we have to do to create packages and (b) only have to configure packaging in one place for all platforms. The second one is so that things are less likely to get forgotten. Eg, for compilation, there's an advantage in having a single set of cross-platform cmake files, because when I do a modification for Linux it either works for free on Mac & Windows or there's a reminder in the file that I have to do something different for those platforms.

[mikfire]

NSIS was what we were already using when I started working on it. It is interesting, with some odd wrinkles and a few quirks. If there is something we can use (open source, or at least free) that is easier to configure, I see no issues trying it out.

I see we can get a free open source license, but I would like to understand things like who "owns" the license. Will it work for Windows 7 (see below)? Can we fix some problems with the current Windows install ( we really need to force users to select a data directory, or at least do a reasonable default that isn't "c:\program files (x86)" because my mind just cannot handle how Windows ghosts that) easier?

Assuming we stick with NSIS or our replacement has a similar configuration, I have no problem with making it a separate project and isolating all the NSIS config and support binaries in it. That makes more sense, and it will stop the other build projects from complaining.

With respect to Windows 7. Windows 7 went out of mainstream support in 2015, and it was officially terminated in January 2020. I do not want to spend a lot of time supporting a dead OS. However, I believe many of brewtarget's users are still running Windows 7 and I would hate to do that to them. In short, I am conflicted.

[mattiasmaahl]

I completely agree with you @mikfire, although maintaining a build for Windows 7 is not difficult as all you really need to do is install the vcredist_x64.exe package that contains the updated DLLs and off you go. But I would, as you say, like to keep that specific config and binary in a separate repository.
As the NSIS is already in-place it is maintainable, although I would prefer an easier way to make THE release for all platforms at once.

What I mean by that is that the installer-generator that @matty0ung suggests, does all the heavy lifting on all the fronts, and as I understand it, given I have not had the time to try it out yet, the program works on a Project file base that could potentially be kept in a separate repository as well for sharing between developer and release managers.

You do make a good point though, who will own the License? If you want I can inquire and try to figure out if it is the one person making the request or if it is the Brewtarget Organization on github?
Let me know your thoughts.

[mikfire]

I would suggest downloading the trial version first and make sure it does what we want in a way we like. If the tech works, then we can decide how to proceed.

[matty0ung]

Sounds sensible. Hopefully they don't tie the licence to one person / one email address.

If we didn't already, we should also look at https://doc.qt.io/qtinstallerframework/ifw-overview.html, though I don't know quite how much it does in comparison with InstallBuilder.

Re Windows 7, I agree we shouldn't spend a lot of time trying to build for an OS that's long out of mainstream support, but I take the point that perhaps there are still a bunch of people still using it. (I remember how long it took for people to stop using Windows XP!) Maybe the compromise is to have a wiki page that says "Here's how to compile and install from source but please consider moving to a supported OS"?

[mattiasmaahl]

You have good points, I'll start with essessing the software to see if it does what we expect to do, as @mikfire says. If it does, I'll look into the licensing and how they have solved it. I'll get back to you after christmas wih more info.

@matty0ung will look at your sugestion at that time as well.

[xzfantom]

I built BT in MXE cross compile toolkit (created docker image for it mxe-qt5-cmake). BT was built with almost no problem - one change for CMakeLists.txt (commit). Main problem is with NSIS installer - script uses some plugins, that are unavailable (Locate and Log). Second problem - get all required libs, but it can be solved using script from mxe.
After all I got fresh win7 x64 and installed BT there (just manualy added libs from copydlldeps script to install folder) and it is working, so there is no need to worry about specific windows libs.

Would it be usefull to dig this way? Maybe you decided to change installer, so I don't need to bother about NSIS plugins.
It would be great to make CI, so it will build binaries for supported systems (I have done some research work for GH Actions for deb package and win package).

[matty0ung]

I like the idea of cross-compiling if it can really work - ie if I could compile for Windows, Mac and Linux all from one build on, say, a Linux box, that would be really neat.

Is this a separate issue from installation though? It seems that build is one thing, but, we also want to ensure that someone who has not got the build environment can install from a single download and not discover that they are missing libraries/DLLs/other dependencies.

[xzfantom]

No, not really separate. Having linux box and docker I can prepare binaries for deb, rpm and win. It's already working and is not an issue.
The only trouble is building windows installer:

1. NSIS Script uses 2 plugins - Locate and NSISLog, they just don't work in cross-compile environment or in x64 environment. Locate solves some task finding old database during install (at least I think so). NSISLog is just logging for debug. Commenting this part in script makes installer build. Locate has it's sources in archive, probably with some adaptation I can make it work too.
2. Required dll's. In MXE is one script, that discovers what dll's are used and copy them in provided folder. So we can create installer with all required libraries and everything will work even in Win7 without vcredist. As I understand - vcredist is required if we are building project in Visual Studio? If so, is there instruction on building with VS, not MinGW?

Here is my point - if we stick with NSIS, I can try to solve this issues. If there is plan to change installer I'll not waste time on this issues and just build binaries without installer (for testing purposes it's enough). After desicion on installer is taken, I can continue.

My finall aim is to create devbuilds after every push to develop, so everybody can install latest version and test it, even if they don't know how to build it. Github Actions provide VM's with Ubuntu, Mac and Win, so it's not that hard, but needs some scripting.

[matty0ung]

Ah, OK, that's brilliant. Let's see what @mattiasmaahl thinks about installers. Originally I suggested to look at another tool to try to save work, and he was going to investigate.

However we get there, I'd love us to be in a position where it's a simple job to build Linux, Mac and Windows installers that end users can download. (It feels like we've been trying to get the 2.4 release out the door for a long time, so anything we can do to simplify and document the release process is all to the good in my book.)

[xzfantom]

So, here is my successful attempt to build win installer - Action. Only I had to remove part of installer with locating old database, but it doesn't affect clean install.

[matty0ung]

Sounds promising. Haven't done a deep-dive on your previous links, but am I right in understanding that the MXE shell script you mention would make it pretty easy to add other dependencies? (The stuff I'm working on needs the Xerces and Xalan libraries to give us access to standard XML features that are not available in Qt. Xerces and Xalan are mainstream multi-platform tools already "known" by CMake, so the CMakeLists changes to get things building for developers were very small. However, I didn't yet get as far as working out what was required for the various install packages for end users.)

[xzfantom]

No problems with xerces it is in packages for MXE. Xalan would require some additional work, but I think not much.

[matty0ung]

Cool. Let's get input too from @mattiasmaahl and @mikfire.

[mikfire]

Yes. Locate does try to solve the problem of finding a database when upgrading. I don't think it works very well, but Windows is very strange about how it presents the file system.

Personally, I would prefer to not use NSIS. It introduces a number of issues, and it hard to maintain. If we are going to replace it, the replacement has to work as well, has to not cause GPL problems and has to show at least enough advantage to justify the risk of swapping out something that works (however distastefully) for something new.

[mattiasmaahl]

Sorry for not responding sooner, I'm at home with ny newborn and the baby do poke for some attention! 😊
Regarding the QT installer I'm testing is only packaging the pre-built binaries, there is support for running all sorts of scripts and programs within the framework to build the program first and then generate the installer, I'm in tje process of figuring out how to build and generate the installer, but all my progress is on my work computer. I start work again on mo day and will continue to test then.

Above builders, using dockers or cross compiling is not an issue for the installer-generator I'm testing, all it needs is a script or command tonrun for generating/building tje binaries.

[mattiasmaahl]

I have been going through the InstallBuilder for Qt a bit, here are my thoughts.
It holds great potential and can potentially be the package builder for us but I have found a few dohs

• It can package all platforms, IF they are already compiled.
  -- It can run scripts before packaging, thus compiling on-the-go, BUT your system has to be able to compile for all platforms, which on Windows is tricky at best, Linux is easier on that point.
• There is that question regarding the License. I have not investigated that any further yet, but they do claim that there are free licenses for open source projects, but how that works I don't know yet, need more investigating.

Final thoughts, Yes, this could be used as the packaging tool for Brewtarget, It certainly holds the capability to do what we want. but I think there is an issue in that the packaging for all platforms, although it can be done on windows, is limited to Linux based desktops due to the fact of being able to cross-compile. Yes I know you "can" cross-compile on windows, but it is tricky to set up, and most likely needs a Linux box for the compiling anyway... But if all binaries are already compiled, there is no issue to package on Windows.

My recommendation is that we go with the Github actions to do all packaging for us, it relatively easy to setup and maintain and do not need any additional licensing or software to make everything happen.

One final note. I have been looking into replacing the NSIS installer with WiX instead based on a few things.

• It can create a better installer, i..e. .MSI or .EXE of our choosing, and can make upgrading and user-version-control a bit easier.
• The syntax for that installer is XML-based and closer to what humans can read and understand without bending over backwards while standing on your right hand whistling a tune. #NSIShasacomplicatedsyntax
• early research suggests that Github Actions can run WiX toolset as well to create the installer.

I'll get back to you on WiX at a later date.
Thoughts are ALWAYS welcome!

[xzfantom]

Do we need to bother about installer on non-Windows platforms? We don't build installer for other platforms now and as far as I know - it works OK, no problem.

[mattiasmaahl]

Earlier releases we have made a installer for windows and packages for the *nix systems.
I would think we would keep creating those for the end users, weather it be an installer or a package for *nix is of little interest for the end-user I think.

But I would like to, on windows at least, move away from NSIS as it requires a reset of brain after troubleshooting the install script.
@xzfantom, What do you think of the WiX installsystem? do you have any experience?

[xzfantom]

Nope, never worked with it. As far as it's supported by CPack, I hope most work it'll do by itself. I like the idea of easy updating. I don't want to mess with NSIS, too)

[mattiasmaahl]

Ok, I will look into WiX setup for Windows packaging.
Meanwhile I was testing removing the Locate-plugin from the NSIS installer.
The only reason it is there is that we automatically look in the APPDATA folder for a pre-existing installation of Brewtarget. Removing all references to that will not affect the installation in any big sense. I also looked into the nsislog plugin usage and that is not used in any meaningful way either, so can also be safely removed. That will at least make NSIS behave somewhat nicer and we wouldn't need to download and install plugins every time an Action springs into work.

Anyway, I'll stop tinkering with NSIS and start working on moving over to WiX Instead.

If Anyone has an opinion or suggestion, please let me know!

And before moving to far into this little project I would like to have @mikfire's and @matty0ung's input on making releases int .msi in the future?

[matty0ung]

When you say "making releases int .msi in the future", do you just mean shipping MSI files (aka https://en.wikipedia.org/wiki/Windows_Installer packages)? If that's what WiX produces and it's a/the recommended way to ship Windows software, then it sounds sensible.

[mattiasmaahl]

Yes, that's the one!
WiX is the easiest way I know to create and maintain installers on windows while being able to have control over installing different version, patch management and upgrade existing installations.

First attemt today was a minor success, nedd to tweak a few file locations and bild the versions config/datafile location update part of it. I may have something read in a few days.

[mikfire]

I have almost no input.

My only real requirements are:

• make it better for the end user;
• make it easier for us to work with;
• make it as robust as you can.
  We are failing on all three measures right now.

I worry about licensing. The main reason we used NSIS is that it is fully open sourced, not just a free license for open source projects. I would like to pretend that doesn't matter to me, but it kinda does.

I will grant, the locate plugin was a little painful. It was solving a real problem that I couldn't find any other way to solve. Please believe me when I say I did not include it just because I enjoyed NSIS. You may want to be aware of the problem and make sure the replacement at least does as much. I will explain more if you care.

[mattiasmaahl]

I know WiX is not GPL licensed, but it is free to use without any royalty.
The pros I found thus far is easier version management and upgrade procedures.
From what I have read there is also patch management if need be, although I have never done that my self. I have on the other hand made a few installers and find the toolset quite easy to use.
I'll put a PR togeather and we'll take it from there.

[matty0ung]

WiX is not just free to use, it is also open source. Not GPL licence, as @mattiasmaahl says, but better than a lot of the alternatives, and also used by Microsoft to build installers for several of its own products, so should be pretty reliable.