This new job resulted in a package which allows to run GIMP on Windows
(as tested in a VM; at least it starts, I can create a new canvas and
paint). Of course I think this will need to be tweaked a little bit
more, as I'm sure we miss things here and there.
At the very least, even though I add the Python and Luajit binaries,
GIMP on Windows didn't find them. This will need to be investigated.
Also it looks like opening from a remote location may not work. Not sure
if this about a missing GIO module or maybe something which works
differently on Windows (I was not even able to drag'n drop from the
browser!). Anyway this needs to be looked at as well.
Note that gdk-pixbuf-query-loaders is apparently unneeded when GIMP is
built this way (unlike with our crossroad build).
All this to say that this is still an early attempt to full CI build for
Windows.
It doesn't invalidate the crossroad build, because cross-compilation
builds from Linux will always stay very important for Linux developers
to be able to easily fix Windows bugs too; yet the crossroad build has 2
major issues:
1. We haven't figured out yet how to run GObject Introspection tools for
cross-builds, so the crossroad builds are not full-featured (and this
is quite a major feature we are missing!).
2. Also I will want to run the installer in the CI at some point and the
one we use can only run on Windows itself AFAIK. We could try to run
it through Wine, but still anyway the point 1. is already quite a
blocker, let's do the simple thing.
Note that we will likely want to move to meson for this build, because
autotools is very slow on Windows. But as long as the few blocker meson
bugs are not fixed, let's stick to the slow yet good build.
Without this, the native Windows GIMP build fails in CI with:
> make[2]: *** No rule to make target '_install\include\gegl-0.4\gegl.h', needed by '../libgimpcolor/gimpadaptivesupersample.lo'. Stop.
Even though `gegl.h` is present (as checked through artifacts). It's
just so weird.
The build rules were highly inspired by other projects on GNOME's
Gitlab. All of them used to build with ccache. It worked fine for the
main build, but completely broke GObject Introspection build on both
babl and GEGL. And the worse thing is that meson was absolutely not
displaying the error, just saying it failed (even in verbose mode). A
lot of time wasted trying to debug.
Therefore let's get rid of ccache, but only for babl and GEGL. Keep it
for GIMP itself as it works fine there.
Other minor changes:
* Build from the build dir, rather than source. The other way around
works too, but I actually find commands simpler this way.
* Adding artifacts.
Ok so this is horrible, but this is the only way I found to get past
some errors. The build would break randomly (sometimes it would,
sometimes not, with the same gitlab-ci rules) because of existing files.
The errors would be the following when trying to install dependency
packages with pacman:
> mingw-w64-x86_64-glib2: /mingw64/bin/libglib-2.0-0.dll exists in filesystem
At first I thought it was a bug in Pacman or MSYS2, but on some runners,
I had such warnings at the very start of the runner (note: on some
runners, the warnings would not be displayed even though the final
conflicting files error would still happen at the end of the logs):
> warning: failed to remove mingw64/bin/libglib-2.0-0.dll: Invalid argument
It looks like it might be related to this Gitlab bug where a runner
would fail to clean its environment:
https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1839
In any case, the only way I found so far is to manually remove the
conflicting files before installing the packages supposed to install
these. This is completely horrible (and I sure hope it won't come up
again with different files each time) but really the only workaround I
found so far (I think a real solution will have to come from Gitlab code
or from the GNOME admins, not sure what is the exact source of the
problem).
Just an initial test to get a hang of the thing, mostly inspired from
GTK gitlab-ci rules adapted to our build.
All in one job (deps, babl, GEGL, GIMP itself) for now, for simplicity
of debugging. We'll see later to break this into CI sub-jobs.
This is a patch for issue #913, the infamous "non-existent floppy drive"
or other unreachable network or unmounted drives. Well at least it
*should* fix the issue, but GLib developers are hoping we could test. So
let's add this in there for our next Windows package.
Nowadays .rs is the extension for the Rust programming language files,
and it's confusing that GIMP is trying to associate with them.
A simple rename of existing .rs images to .ras will allow them to be
opened again.
Note by reviewer: ideally file association should not rely on filename
extension, and should be detected properly (i.e. file "magic"). This way
even extension clash would not be a problem (format would be detected
whatever the extension used). Unfortunately it's apparently not the case
on Windows.
Anyway since nowadays chances to see a Rust code file are likely much
higher than seeing a Sun Raster image file, let's just accept this patch
and drop association of `.rs` on Windows.
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!
Fix the registry path where uninstaller information is searched for
during installation, so that old GIMP versions are properly
uninstalled before installing a new version.
This fix has already been included in the 2.10.0 installer.
In order to bundle the MyPaint brushes, GIMP needs to be configured
with --enable-bundled-mypaint-brushes, and the brushes need to be
present at $GIMP_DIR32\share\mypaint-data.
The Win32 build was not taking the new path of git-version.h into
account and was outputting these errors:
> ../build/windows/gimp.rc:2:10: fatal error: git-version.h: No such file or directory
> #include "git-version.h"
> ^~~~~~~~~~~~~~~
...the installer component
The warning is actually not only about the installer, but also covers
the installed version of GIMP. The warning was resurrected from commit
6f0bb88e43 and slightly reworded.
In configure.ac, add --enable-windows-installer option (off by
default), which should be set to generate the necessary files for
the installer translations during the build. Using this option is
only supported when building from git, since the installer files
are not included in source tarballs.
Rename setup.isl.desktop.in to setup.isl.in, and instruct intltool
to treat it as an .ini file explicitly.
Delete generated message files during make clean.
Remove the installer graphics credits, since we use a different set
of graphics in master, and will probably use yet different set of
graphics for 2.10.
Add strings for the MyPaint brushes component. The setup script in
git doesn't use those yet, but this lets translators start
translating them.
Use intltool for managing the translations for the Windows
installer, instead of manually maintaining the translated message
files.
The message files are generated in the source directory, under
build/windows/installer/lang, as part of the build, and can be
subsequently used to build the installer, as before.
Though the bug was mostly fixed, it seems to still happen on Windows XP,
where apparently no content type had been registered for SVG.
GTK+ developers don't seem too keen to patch GTK+ 2.24 for a platform
which they don't support anymore.
Also if not mistaken, GIMP does not officially support Windows XP
anymore either. A patch though has already been provided by Edward E.
and it really doesn't look like it could break anything since it just
adds a last "else if" when everything else failed (and inside a #ifdef
affecting only WIN32 builds).
So let's just add it in our builds at least. We still don't have support
for it, but I see no reason to just refuse a minor patch which won't
break anything else.
... interfere with GIMP UI events
Add a GTK+ patch to ignore top-level transparent windows when
looking for the top-level GDK window at a certain pointer location,
in the Win32 GDK backend.
The existing graphics are still from 2.8 (specifically, the have a
"2.8" caption, so we can't use them for 2.9); these are the
graphics used for the 2.9.6 installer.
... makes the list scroll down and select the next item
Adjust the file association list height to be a multiple of the
item height, to avoid this issue.
Jernej Simončič