This should give a nice name to distribution archives so that they are
not all called `artifacts.zip`. Names will better describe their
contents (target OS or source and short commit hash, because for CI
builds, it's important to know which commit is being tested).
Also replace CI_COMMIT_REF_NAME in other artifact names by
CI_COMMIT_REF_SLUG. Otherwise if a branch has a slash (quite common in
branch names), only the part after the last slash is used for archive
naming.
Finally immediately exits from dependency build with error code (!= 0)
if `crossroad install` command failed.
… the CI.
There are 2 finale steps before finale binary distribution on Windows.
We must compile the GSettings XML schema files and register GdkPixbuf
loaders (for file format support in the GUI).
I used to provide a wrapper to be run inside Windows before first GIMP
run. Never did I realize that I can compile the distributed GSettings
schemas with the native `glib-compile-schemas` (works fine in my tests).
As for the GdkPixbuf loaders, we inspect DLL libraries, hence we do
require the target `gdk-pixbuf-query-loaders` which is unfortunately a
Windows executable. Yet it seems to work fine with Wine, so let's be
done with it in the CI instead of requiring manual steps from testers of
the CI builds. Then a few `sed` calls are enough to make the path in the
produced text file relative instead of absolute (which works fine, again
in my tests at least).
This means that I don't have to distribute the 2 binaries and the DLLs
they depend on anymore. Moreover let's remove the wrapper (but still
generate one which just calls GIMP so that we call it from the tree
root, where it's much less messy).
Note: I failed to install wine32 (32-bit Wine) on the Gitlab runner.
After following all instructions, I encountered weird errors. So
instead, I just make the win32-nightly job depend on win64-nightly and
copy `loaders.cache` from one to another, as it is a
platform-independent text file (as long as we provide the same GdkPixbuf
loaders on both of course, which we do).
The main purpose of these jobs is to only package the strict necessary
for a working GIMP under Windows, i.e. getting rid of all unnecessary
executables, and inspecting binary dependencies recursively to only
package used DLLs.
The dll_link.py script is taken from Siril codebase (see commit a86e82a8
on Siril repository, by FlorianBen). This was a very nice idea, and
makes for much smaller test archive (Siril is also GPLv3 so licensing is
ok for the reuse, also anyway it's just a small independent build
script).
Moreover having it as a separate job allows to have artifacts with only
the finale distribution (artifacts on the build job also have the build
directory and the whole prefix, which we want to keep in order to debug
when needed).
Hopefully I am not missing anything. Siril seems to package more, like
various gdk-pixbuf-*.exe, gspawn-*.exe and gdbus.exe. I am wondering if
these are actually necessary. I could run GIMP fine without these in
quick tests, but I guess I'll have to investigate a bit more to figure
this out. That's what nightly builds are for, after all, so hopefully
people will report if we miss some runtime dependencies.
libopenexr was installed, but pkg-config was failing because of missing
dependency:
```
$ x86_64-w64-mingw32-pkg-config --modversion OpenEXR
Package IlmBase was not found in the pkg-config search path.
Perhaps you should add the directory containing `IlmBase.pc'
to the PKG_CONFIG_PATH environment variable
Package 'IlmBase', required by 'OpenEXR', not found
```
Looks like there may be a dependency bug in the openexr package in
Msys2. Anyway let's just add ilmbase and get this to be detected
correctly.
Our installer use Msys2 packages when possible. And Msys2 repository
provides version 0.3.9, released on March 2, which contains our patches.
No need for them here anymore, no need to make custom builds.
This is a new feature I implemented in the crossroad cross-compilation
tool. Msys2 repository has more packages and they are more up-to-date
compared to Fedora and Suse cross-built packages (the 2 other available
sources for pre-built Windows packages).
This allows to simplify a lot the dependency preparation for the Windows
CI, and speed things up.
json-c has 2 build systems (autotools and CMake) and it seems their
autotools broke with recent changes. I will report upstream. For the
time being, we may as well switch to CMake build.
Previous OpenBlas patch fixed the crash with Sophos (see reports #3633
and #4246) but created a huge slowdown of startup because of a timeout
change and most likely OpenBLAS being loaded at startup during the
various verifications.
A new patch has been merged upstream to lower this timeout to something
more reasonable. Reporters confirmed GIMP now runs fine (neither crashes
nor very long startups).
See: https://github.com/xianyi/OpenBLAS/pull/2339
Actual patch contributor wants confidentiality to avoid leaking
proprietary information or whatever (I am not sure either what to be
scared of as it's all good and harmless to me, but let's respect the
request). See also #4246 for more details.
A few commands need to be performed the first time for glib to work
properly, and gdk-pixbuf loaders to be found. I add them in a wrapper
script so that it's easy to ask people to test the dev builds (even
though it's not necessary to run these commands each time, but who
cares!).
Let's make sure they are not pulled in as dependency of other packages.
This fixes the Win32 CI build now that we fixed the Pango minimum
requirement in meson files.
Rather than having the whole Win32 cross-build into the 'gimp' stage,
break the dependencies and GIMP-only builds in 2 stages.
Since apparently we need to keep the same structure for the native and
cross build (otherwise we don't get parallel builds; in other words, I
didn't find the possibility to set separate pipelines up), I move babl
and GEGL into the same 'dependencies' stage.
Finally I remove the -base rules extended into actual jobs, except for
`.gimp-base` (this is the only which makes sense as it is actually
common to the meson and autotools build).
It looks like Arch does not have mingw64 cross-compilers in core package
repository. It does have some package in the user repository (AUR), but
I assume that such a repository cannot be deemed as safe.
Anyway I still tried, but apparently these AUR packages have to be built
and when I tried, I got this error:
> ERROR: Running makepkg as root is not allowed as it can cause
> permanent, catastrophic damage to your system.
Anyway it's all a big mess. Then I tried to move the cross-CI to Debian
testing, which is anyway our base compatibility system. Unfortunately I
encountered like what looked like some glibc++ macro problem on some
packages (most likely because the pre-built packages I use are Fedora
ones which likely uses a cross-compiler differently built from the
Debian one).
So in the end, for simplicity, I use a Fedora image, then I am sure to
get a good match between the system cross-compiler and the pre-built
dependencies.
Several of our own translations of the Windows installer are unused
because Inno Setup corresponding translations are marked "unofficial".
This mostly means that the language files for these are probably old and
unmaintained, hence outdated. And these files are not bundled together
with Inno Setup release (though still hosted in their repo).
Nevertheless it doesn't make sense that we would just waste the work of
our translators here. Maybe Inno Setup localization is not complete, so
what? At best it could even encourage translators to contribute upstream
to Inno Setup. Let's just enable all our current localizations of the
installer and see how it goes!
