ci: add PKGBUILD scripts and GitHub Actions workflow

[umarcor]

As commented in #18, this is work in progress to provide nightly built packages of GtkWave (gtk2 and gtk3) for MSYS2 (MINGW32 and MINGW64). The scheme is as follows:

• Each time a commit (or set of commits) is pushed to this repo, four jobs are run in parallel. If successful, each job generates a package.
• If all jobs are successful, and if the event is not a PR, the four artifacts are published as assets of a named GitHub Release of type pre-release.
• The workflow is executed periodically through a CRON job, in case commits are not pushed in several days/weeks/months.

Pending tasks:

• Decide if the workflow is to be executed for testing PRs.
• Decide the frequency of the scheduled/CRON job.
• Choose a tag/pre-release name; create and push the tag; create the pre-release.
• Extract list of files to build a zipfile for users without MSYS2.
• Build packages for Ubuntu and macOS too?

Further notes:

• The second row of step Install dependencies in the workflow (L41) should NOT be required, since dependencies are explicitly defined in the PKGBUILD files. However, pacman seems to have issues with installing it during the call to makepkg-mingw (L47): https://github.com/umarcor/gtkwave/runs/748479855?check_suite_focus=true#step:5:140. @lazka, is this a legit bug or a PEBCAK? It was a PEBCAK, --noconfirm was missing.

• gtk3 builds are successful (both on MINGW32 and on MINGW64). However, gtk2 builds fail inconsistently. For example, in https://github.com/umarcor/gtkwave/actions/runs/128204639 the MINGW32 build failed, but the MINGW64 build was successful. However, in https://github.com/umarcor/gtkwave/actions/runs/128193194 both failed. In all cases, the failure is produced when compiling include/gtk-2.0/gtk/gtktypeutils.h:

2020-06-08T04:54:55.1795153Z D:/a/_temp/msys/msys64/mingw32/include/gtk-2.0/gtk/gtktypeutils.h:255:1: internal compiler error: Segmentation fault
2020-06-08T04:54:55.1795399Z   255 | GtkEnumValue* gtk_type_enum_find_value (GtkType  enum_type,
2020-06-08T04:54:55.1795620Z       | ^~~~~~~~~~~~
2020-06-08T04:54:55.1795780Z 
2020-06-08T04:54:55.1796025Z D:/a/_temp/msys/msys64/mingw32/include/gtk-2.0/gtk/gtktypeutils.h:255:1: internal compiler error: Aborted
2020-06-08T04:54:55.1796299Z i686-w64-mingw32-gcc.exe: internal compiler error: Aborted signal terminated program cc1
2020-06-08T04:54:55.1796530Z Please submit a full bug report,
2020-06-08T04:54:55.1796959Z with preprocessed source if appropriate.
2020-06-08T04:54:55.1798950Z See <https://sourceforge.net/projects/msys2> for instructions.

This is surprising because gtkwave with gtk2 is already an MSYS2 package, and pre-built binaries are available for both MINGW32 and MINGW64. However, those binaries were built in february (see https://packages.msys2.org/search?t=binpkg&q=gtkwave). gtk2 packages were built in july last year: https://packages.msys2.org/search?t=binpkg&q=gtk2. Since MSYS2 is a rolling release, this might be a regression in the compiler. @lazka, which is the recommended procedure?

• Installing cmake explicitly (as suggested in https://github.com/gtkwave/gtkwave/blob/master/gtkwave3-gtk3/README#L174) seems not to be required. Either it is a "light" dependency, or it is installed anyway as a dependency of some other package (base-devel? toolchain?). @gtkwave, is it optional?

• The current proposal replaces the "Steps to build gtkwave3-gtk3 with MSYS2 on Windows10" procedure from #18:640177835. However, "Steps to create gtkwave3-gtk3 distribution zip" is not implemented yet. I'd like to compare the "manual" procedure with https://github.com/achadwick/styrene (or some other reference from https://www.msys2.org/wiki/Distributing/) and/or https://www.msys2.org/wiki/Using-packages/#finding-dependencies-of-a-package.

/cc @e-tabrez

[lazka]

* @lazka, is this a legit bug or a PEBCAK?

Hm, I don't quite understand it either. Isn't there an "export" missing for MINGW_INSTALLS?

Since MSYS2 is a rolling release, this might be a regression in the compiler. @lazka, which is the recommended procedure?

Looks like it, but I don't know much about compilers. I can only say that 32 bit things are seeing less testing nowadays with decreased usage..

[tbzcode]

@umarcor, Good work. An automatic build will be great.

[umarcor]

Hm, I don't quite understand it either.

@lazka, in a new commit, I added a simpler MWE. So, it's a "regular" build of https://github.com/umarcor/gtkwave/blob/ci-msys2/MSYS2/gtk3/PKGBUILD with MINGW_INSTALLS=mingw64 makepkg-mingw -sCLfc.

Isn't there an "export" missing for MINGW_INSTALLS?

I don't think it is required. MINGW_INSTALLS seems to be properly detected by makepkg-mingw. Anyway, I tested it with an explicit export too: https://github.com/umarcor/gtkwave/runs/754090421?check_suite_focus=true#step:5:139

Looks like it, but I don't know much about compilers. I can only say that 32 bit things are seeing less testing nowadays with decreased usage..

This seems not to be an issue with 32 bit things, but with gtk2 and the latest GCC. In fact, in the latest runs, MINGW32 worked but MINGW64 failed: https://github.com/umarcor/gtkwave/runs/754002195?check_suite_focus=true. This is different from previous runs, where either both failed or MINGW32 failed but MINGW64 failed. That's why I think it might be some regression in the compiler, which is triggered inconsistently.

[tbzcode]

@umarcor, If you finished the nightly build script can you please give the path where output zip will be store. Eagerly looking for it.

[umarcor]

@tbzcode I've been really busy lately, but you can have a look at https://github.com/umarcor/gtkwave/releases/tag/nightly and https://github.com/umarcor/gtkwave/actions/runs/155017826. I will update this PR accordingly, as soon as I have some time to do it properly.

Note that .tgz files are generated based on the lists of files you provided in #18 (comment). I had to remove libgdk-win32-2.0-0.dll and libgtk-win32-2.0-0.dll, because those were not found.

[umarcor]

@gtkwave, I think this is ready to merge. Not perfect, but good enough. Let me be specific:

• The workflow is executed when you push to any branch, NOT for PRs. We can change it if you want.
• An scheduled/CRON job is executed once a day. We can change it if you want.
• Four independent jobs are executed MINGW32-gtk2, MINGW64-gtk2, MINGW32-gtk3 and MINGW64-gtk3.
  • gtk2 jobs fail randomly because of an internal compiler error. Sometimes is with include/gtk-2.0/gtk/gtktypeutils.h, others with include/gtk-2.0/gtk/gtktooltips.h, others it just works. Because of that, all four jobs are allowed to fail.
  • In each job where the build is successful, the package is uploaded as an artifact.
  • In gtk3 jobs, the lists of files provided by @tbzcode are used to generate an "standalone tarball". These are also uploaded as artifacts.
  • A last job (which is executed for branch master only) picks all the artifacts and publishes them in the pre-release as assets. If exist, they are overwritten. Hence, the pre-release will contain the latest succesfully built packages from each job. Since gtk2 builds fail randomly/inconsistenly, we will have packages for all four environments, although not all of them will be always up to date.
    • For this feature to work, you NEED to create a tag, push it to the repo and create a pre-release from it (NOT a release). I picked name 'nightly', but it can be changed.

@tbzcode, I tried gtkwave_gtk3_mingw64_standalone.tgz 45.7 MB on Windows 10 and it works nice.

• MINGW64-gtk2: mingw-w64-x86_64-gtkwave-ci-1-any.pkg.tar.zst 2.37 MB
• MINGW32-gtk3: mingw-w64-i686-gtkwave-gtk3-ci-1-any.pkg.tar.zst 2.38 MB
  • standalone: gtkwave_gtk3_mingw32_standalone.tgz 46.1 MB
• MINGW64-gtk3: mingw-w64-x86_64-gtkwave-gtk3-ci-1-any.pkg.tar.zst 2.38 MB
  • standalone: gtkwave_gtk3_mingw64_standalone.tgz 45.7 MB

[umarcor]

ping @gtkwave

In the last run, all jobs were successful: https://github.com/umarcor/gtkwave/runs/889604982?check_suite_focus=true

[umarcor]

Thanks @gtkwave! Note that, for the full procedure to work:

you NEED to create a tag, push it to the repo and create a pre-release from it (NOT a release). I picked name 'nightly', but it can be changed.

The tag can point to any commit initially, because it will be updated after each execution of the workflow. I suggest not to write any title or description in the pre-release, so that it shows the body of the latest commit.

EDIT

It seems that the run after merging this was stuck. You can either restart the workflow, or wait for it to be executed again when scheduled.

[gtkwave]

I just saw that things aren't quite working right (see below). I haven't used git outside of this project or messed with any of these workflows so if you can give me the right sequence of commands, that would help. Thanks, -Tony Run failed for master (e049b93) Repository: gtkwave/gtkwave Workflow: build Duration: 16 minutes and 50.0 seconds Finished: 2020-07-21 00:44:00 UTC View results Jobs: msys2 (MINGW32, i686, 2) failed (1 annotation) msys2 (MINGW32, i686, 3) succeeded (0 annotations) msys2 (MINGW64, x86_64, 2) failed (1 annotation) msys2 (MINGW64, x86_64, 3) succeeded (0 annotations) nightly failed (0 annotations) — You are receiving this because this workflow ran on your branch. Manage your GitHub Actions notifications here. On Monday, July 20, 2020, 04:42:19 PM EDT, umarcor <notifications@github.com> wrote: Thanks @gtkwave! Note that, for the full procedure to work: you NEED to create a tag, push it to the repo and create a pre-release from it (NOT a release). I picked name 'nightly', but it can be changed. The tag can point to any commit initially, because it will be updated after each execution of the workflow. I suggest not to write any title or description in the pre-release, so that it shows the body of the latest commit. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[umarcor]

I just saw that things aren't quite working right (see below).

They are working as expected; not perfect, but well enough:

• Yesterday (https://github.com/gtkwave/gtkwave/actions/runs/176128556) one of the jobs was stuck. That is expectional and I think it's a transitient issue with GitHub Actions (they are having some stability issues lately: https://www.githubstatus.com/).
• Today (https://github.com/gtkwave/gtkwave/actions/runs/176410626) all four jobs were executed. gtk3 builds were successful and gtk2 builds failed. This is unfortunate, but explained above: gtk2 builds fail randomly. In subsequent runs, they will surely build. Ideally, we would track this bug in MSYS2's GCC. In practice, I am not capable of fixing that.

The error in the last (fifth) job is the one we can fix. It takes all the artifacts (2, 3 or 4, depending on the number of successful jobs) and it tries to upload them as assets of an existing pre-release. It is currently failing because pre-release "nightly" does NOT exist: https://github.com/gtkwave/gtkwave/runs/892261733?check_suite_focus=true#step:4:22

I haven't used git outside of this project or messed with any of these workflows so if you can give me the right sequence of commands, that would help. Thanks, -Tony

Sure!

• First, on your host, tag any commit:

git tag nightly

• Then, push the tag to this repo (assuming that "origin" is the remote that points to https://github.com/gtkwave/gtkwave):

git push origin nightly

• It will be shown in: https://github.com/gtkwave/gtkwave/tags
  • There is a button with symbol ··· on the right. Click it and select "Create release".
    • Check the box that says This is a pre-release.
    • Push button Publish release.

The result will be similar to https://github.com/umarcor/gtkwave/releases

From there on, the fifth job will work and workflow runs will be successful, regardless of gtk2 builds failing randomly. Latest successful artifacts/assets will be gathered in https://github.com/gtkwave/gtkwave/releases/tag/nightly.

[tbzcode]

@umarcor , Great work. Thanks for your efforts.
I just want to add one important point.

After extracting the package gtkwave_gtk3_mingw64_standalone.tgz, the \share\man and \share\mime folders have lots of files.
They are 37MB together.

I am not Linux guy, so I don't know significance of these. But they are not required for Windows.
So you can completely skip both in final package or just include following GTKWave related files only. This will further reduce the final package size.
(These files will be generated freshly after each build in MSYS2)

share\man\man1\evcd2vcd.1
share\man\man1\fst2vcd.1
share\man\man1\fstminer.1
share\man\man1\ghwdump.1
share\man\man1\gtkwave.1
share\man\man1\lxt2miner.1
share\man\man1\lxt2vcd.1
share\man\man1\rtlbrowse.1
share\man\man1\shmidcat.1
share\man\man1\twinwave.1
share\man\man1\vcd2fst.1
share\man\man1\vcd2lxt.1
share\man\man1\vcd2lxt2.1
share\man\man1\vcd2vzt.1
share\man\man1\vzt2vcd.1
share\man\man1\vztminer.1
share\man\man1\xml2stems.1

share\man\man5\gtkwaverc.5

share\mime\packages\x-gtkwave-extension-ae2.xml
share\mime\packages\x-gtkwave-extension-aet.xml
share\mime\packages\x-gtkwave-extension-evcd.xml
share\mime\packages\x-gtkwave-extension-fst.xml
share\mime\packages\x-gtkwave-extension-ghw.xml
share\mime\packages\x-gtkwave-extension-gtkw.xml
share\mime\packages\x-gtkwave-extension-lx2.xml
share\mime\packages\x-gtkwave-extension-lxt.xml
share\mime\packages\x-gtkwave-extension-lxt2.xml
share\mime\packages\x-gtkwave-extension-vcd.xml
share\mime\packages\x-gtkwave-extension-vzt.xml

This is applicable to both gtk2 and gtk3 builds.
Tony (@gtkwave ) also include only above files in his gtk2 windows distribution (on sourceforge).

[umarcor]

After extracting the package gtkwave_gtk3_mingw64_standalone.tgz, the \share\man and \share\mime folders have lots of files.
They are 37MB together.

I am not Linux guy, so I don't know significance of these. But they are not required for Windows.

@tbzcode, those *.1 are the man(ual) files in Linux. Those allow to explore the documentation of each tool interactively. For example, try man vcd2vzt. Of course, if man is not available on your host, it won't work. However, I don't know if the solution should be to remove those files or to add man to the package. @gtkwave wdyt?

I don't know what are share\mime files used for...

This is applicable to both gtk2 and gtk3 builds.

Currently, there are no standalone packages for gtk2. Do you have the list of files for gtk2 builds?

[umarcor]

@gtkwave, you created the tag and the pre-release properly 🎉: https://github.com/gtkwave/gtkwave/releases

This time 3/4 jobs were successful: https://github.com/gtkwave/gtkwave/actions/runs/177661749

However, the fifth job was skipped. That is CORRECT. It is because the workflow was triggered by the tag. However, the last job is only executed when changes are pushed to branch master: https://github.com/gtkwave/gtkwave/blob/master/.github/workflows/build.yml#L60

Hence, the artifacts will be pushed to the pre-relase next time. Optionally, you can restart the run from yesterday: https://github.com/gtkwave/gtkwave/actions/runs/176410626

[tbzcode]

@umarcor

However, I don't know if the solution should be to remove those files or to add man to the package.

I think they will not be useful in windows binary distribution. So better to remove them in my opinion.

Currently, there are no standalone packages for gtk2. Do you have the list of files for gtk2 builds?

Yes. I have list of files for gtk2 also. I have added the gtk2 list in my 18# Comment

Also you can check windows distribution package in my Fork release for reference.