ci: generate Windows installers

[Adrijaned]

Description
Added a CI job steps to generate windows NSIS installers from the built windows binaries. This serves mainly as a way to decrease entry barrier for learning to write VHDL on windows, but should be generally useful for everyone running windows.

🚨 This has not been thoroughly tested, as I don't have any windows machine currently on hand, and don't have enough free disk space for a 64-bit windows virtual machine. I did however at least test that the 32-bit installer installs and uninstalls correctly, and that the ghdl binary can be launched from cmd after installation, and there should not be anything too different in the 64 bit version to cause breakage.

Further comments
This is a fairly simple and primitive installer, currently serving as a proof of concept for me for another ghdl-related project, but should be mergeable nevertheless. If that other thing comes through and this gets merged, I will probably create another PR trying to simplify the .nsi scripts to reduce code duplication, and probably to include option to somehow also install gtkWave alongside ghdl as optional component.

[umarcor]

Overall, the idea is nice, since it allows users not to install MSYS2 explicitly. However, I'm afraid it is an incomplete approach. It seems that you are creating an installer from the content of the pkg directory created during the build on MINGW32/MINGW64. The content of that directory is only guaranteed to work on an MSYS2 environment. The build with an mcode backend might work by chance, because it's built statically. However, the same approach will fail for the LLVM backend. Please, see #1560 and #1599 for further info about the challenge.

I tried to find somewhere in the *.nsi files that the required DLLs are copied, but I couln't find it. Am I missing something?

[umarcor]

Please, create the NSIS installer in a separated job, after win-test. See https://github.com/ghdl/ghdl/actions/runs/868960417.

We want to first build GHDL, then test it, and generate the installer only if the tests are successful.

[umarcor]

and that the ghdl binary can be launched from cmd after installation

Launching the GHDL alone is not enough testing. You should run the testsuite, or some of the tests at least, for ensuring that no dependencies are missing.

there should not be anything too different in the 64 bit version to cause breakage.

The 64 bit version is very different because mcode backend is not supported on Windows x86-64. Therefore, a completely different backend is used. mcode is a in-memory statically built-in backend. LLVM is an external compiled solution, which is not built statically.

will probably create another PR trying to simplify the .nsi scripts to reduce code duplication, and probably to include option to somehow also install gtkWave alongside ghdl as optional component.

Note that GTKWave uses MSYS2 in CI and then generates standalone zipfiles by copying additional files from manually maintained lists. See https://github.com/gtkwave/gtkwave/tree/master/MSYS2, gtkwave/gtkwave#20 and gtkwave/gtkwave#18.

I did discuss with @Paebbels about using a similar solution for GHDL. So, copy the standalone_pkg.sh from GTKWave, and write *dll.inc, *lib.inc and *exe.inc, with the lists provided in #1560 (comment). However, that is something I cannot afford to maintain myself. I can help with CI, management of artifacts, assets, releases, etc. but I cannot take care of keeping those *.inc files up to date. Nonetheless, if you or anyone else wants to take care of it, that'd be awesome. It would allow to use the *.nsi files proposed in this PR. Furthermore, it might not be necessary to maintain the list manually. See "Existing tools for automatic discovery of MSYS2 package dependencies (files)" (#1560 (comment)).

With regard to combining multiple tools in one installer, see the comment about "something similar to Ninite" in #1599 (comment).

[Adrijaned]

Oof, that's a lot more complicated than I had hoped for. Now, 64-bit with llvm looks way more complicated than 32-bit mcode, and I don't even have a need for it nor do I expect a lot of people who might just want to try learning VHDL without too much obstacles on the way to have.

If we decreased the scope of this PR to just create installer for the mcode x86 binary, how should I go around testing that the install works on a fairly bare system? So far I've only succesfully manually run the installed binary on two very simple designs, both time utilizing only the -a, -e, -r, and --wave flags.

[umarcor]

Oof, that's a lot more complicated than I had hoped for.

Yeah, "(...) software is hard. It's harder than anything else I've ever had to do." (https://en.wikiquote.org/wiki/Donald_Knuth)

Now, 64-bit with llvm looks way more complicated than 32-bit mcode, and I don't even have a need for it nor do I expect a lot of people who might just want to try learning VHDL without too much obstacles on the way to have.

See #1785. That's a fair point. Still, mcode has dependencies which are not included in the tarball. See https://github.com/ghdl/ghdl/blob/master/scripts/msys2-mcode/PKGBUILD#L10-L14 and #1560. So, even if you want to install the 32 bit mcode version only, you need to at least include zlib, libgnat, gcc_s_seh and libwinpthread. Moreover, we cannot guarantee that those DLLs will not conflict with others in the system. Alternatively, you could enhance the build plumbing, for generating a completely static binary. Last, you could try using AdaCore's GNAT, instead of the MSYS2 recipes.

If we decreased the scope of this PR to just create installer for the mcode x86 binary, how should I go around testing that the install works on a fairly bare system? So far I've only succesfully manually run the installed binary on two very simple designs, both time utilizing only the -a, -e, -r, and --wave flags.

Create an additional windows-latest job in CI where you do nothing other than download the artifact, checkout the repo and run the testsuite. You run the testsuite with GHDL=path/to/ghdl ./testsuite/testsuite.sh.

That is currently done for MSYS2. There is a win-build job matrix (https://github.com/ghdl/ghdl/blob/master/.github/workflows/Test.yml#L200) and then a win-test job matrix (https://github.com/ghdl/ghdl/blob/master/.github/workflows/Test.yml#L262). In the test jobs, we install the testsuite dependencies only: diffutils, gcc, python-pip, python-setuptools and testsuite/requirements.txt (https://github.com/ghdl/ghdl/blob/master/.github/workflows/Test.yml#L287-L314). You would need to install those using some alternative solution, since the purpose is precisely not to use MSYS2. Alternatively, you can skip some of the testsuites (e.g. pyunit) for avoiding the dependency on Python.

[Paebbels]

Some long time ago, GHDL had NSIS support to create MSI installer files. The problem with NSIS is - and I think it's not solved yet or ever - it doesn't create correct installations. Mainly adding GHDL to PATH was completely broken. And if I remember correctly, it only GHDL wasn't added correctly, it fucked up the PATH variable for the whole system ...

Is this problem now solved with latest NSIS?

[Paebbels]

See this very very old ticket started in 2014: https://sourceforge.net/p/ghdl-updates/tickets/10/

[Paebbels]

While NSIS 2 is a dead end (latest version 2016).

Source: https://sourceforge.net/projects/nsis/files/NSIS%202/

There is a new NSIS 3 ...
https://nsis.sourceforge.io/Download

Looking at the list of bugs (quite long with 179 issues), the PATH bug is still listed:

• https://sourceforge.net/p/nsis/bugs/1247/

This might be also interesting to see:

• GitHub Actions and NSIS: https://github.com/NSIS-Dev/github-action-examples
• Old NSIS file: https://sourceforge.net/p/ghdl-updates/ghdl-updates.git/ci/master/tree/dist/mcode/windows/ghdl.nsi