This will allow to use the official Windows installer directly in the
Windows Store, as per the new proposed workflow by Microsoft.
Nevertheless our GIMP for Windows has a built-in update check which
would check if a new version exist and warn people (advising them to go
on the website and download the new installer to update). We obviously
don't want this on the Windows Store which has its own update channel.
It would be confusing.
Therefore I added a feature to disable the built-in update check (not
even showing in Preferences) by tweaking a single package variable. The
installer now comes with new option /DISABLECHECKUPDATE=true which will
add said variable.
JSON does not support comments and their support in Flatpak is possible
through use of json-glib[0]. This is problematic in fully utilizing
flatpak-external-data-checker because its JSON writer does not respect
existing comments. To solve this, make use of Fltpak's specific
behaviour where a "//" key is explicitely ignored while parsing[1].
[0] flatpak/flatpak-builder#363 (comment)
[1] 0e98b7ae19/src/builder-utils.c (L1250)
OpenEXR and mypaint-brushes offer next major versions. GIMP is probably
not ready for the changes in OpenEXR and mypaint-brushes are not yet
finalized. Put their versions under constraints so that automatic PR
creation for dependency bumps can be enabled.
It looks like the gi-docgen build is broken on Windows (though the CI
does show neither stdout nor stderr output, just a failure without
message). This should be fixed, but it's not necessary for the installer
at least.
Note: on autotools, the gi-docgen step works fine on Windows.
We didn't need to do this on the autotools build, simply because the
configure step is much more elaborated there, and was checking for the
header file as well as well as a working mng_create() API. But since
libmng was broken, the test failed, so we didn't need to disable it.
By the way, we should check when the `.pc` file was added, because if it
was after the required version, then the meson test is very wrong. It
should not have been different from the autotools file.
The meson build still has a bunch of issues and build bugs compared to
the autotools build, nevertheless the last blocker issue was dealt with
a few days ago (PDB source generation).
Moreover since the meson build on Windows especially makes such dramatic
difference, in terms of build speed, this is a big improvement for
Windows contributor's comfort, and as such is one less barrier of entry.
Anyway I believe that most Windows developers build GIMP with meson now
so sticking on autotools on this platform is just counter-productive.
This is why it was decided to now make meson the recommended build
system on Windows, as a further step toward a move to meson. It is still
not the recommended build system on the other platforms yet.
The --debug option so far would only output debug info. I want both the
run to actually occur and the debug to be printed, at least in some
cases. So I make this a choice option with 3 variants (no debug, debug
only and run + debug).
Similar to the change I pushed to gimp-help repository:
intltool-extract does not consider the `;` isl-syntax comments because
we tell it it is in the ini format. So let's have our source in actual
ini format (POTFILES does not like to look for translated strings in
constructed files, only from source files), then create the .isl files
from it in 3 steps (first, transform the comments in isl format; then
merge all language in a single .isl file; last generate one .isl per
language).
There were already a bunch of comments in the setup.isl.in file (though
not showing in the po files until now). I checked if they seemed
relevant, fixed some, completed others, duplicated the ones which match
several strings, etc.
(This improvement to allow comments for translators in the installer po
files was requested by Piotr Drąg on the gnome-i18n mailing list)
Some tools have been moved. `aclocal` (and likely other tools, but this
was the first one making an error in the deps-win*-native CI jobs) is
now in `automake-wrapper` package, which itself is a dependency of
`autotools`.
Cf. https://github.com/msys2/MINGW-packages/issues/11114
Instead of replacing various needed macros with random hardcoded values,
just make them mandatory and exit with explicit error when a needed
macro is missing.
Since 2afa019c70,
the Meson configure step will fail when building from tarball (missing `.git` and `gitversion.h` is present)
because `gitversion_h` variable will contain a `list[file]` but `custom_target` does not like that in its `depends` kwarg.
We were already avoiding re-processing a same DLL within the same run
(this can happen when 2 dependencies have themselves a common
dependency). But the dll_link.py script was stateless regarding previous
runs so we might be checking again the same DLLs multiple times (even
though we were not copying them again).
Let's make the script stateful with a new parameter to give a file where
all the previously processed DLL names are stored. I am hoping it would
improve the efficiency of the packaging-win32-native which is suddenly
extra slow (it always times out, even after raising the max job time;
now we time out after 2h30! The 64-bit packaging job just takes 1h,
which is too much already, but still much more reasonable).
This includes:
- "copy-icon" set
- Permission and cleanup rules updated
- Exiv2 bumped to 0.27.5
- Adding an x-checker-data for OpenEXR
- Poppler bumped to 22.01.00
- OpenBlas bumped to 0.3.19
- graphviz bumped to 2.50.0
Also improving a bit the download script by specifying the .isl or .islu
file extension. It's nicer than trying to download randomly, and also it
allows to better compare the list of downloaded files with the list in
gimp3264.iss script.
My previous command was also adding a linefeed just after the BOM. While
I'm not sure it would really break anything for processing these, it's
anyway much more correct to only add the 3 BOM bytes. So here is the
improved command.
Also some language files are supposed to be UTF-8 yet they are missing
the BOM markup (only method to recognize them for InnoSetup). This is
the case for Chinese Traditional. See issue #7676.
Make sure that this lang file has a BOM.
One is a patch for a GExiv2 version below the one we now require, the
second is a patch for GIMP which is now committed and pushed.
Cf. commit 7ed68556c7.
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
Also when working on out-of-tree builds, it would not find the file
anyway and we get this output:
> chmod: cannot access 'test-installer-langs.sh': No such file or directory
Though this was not breaking the tests, it has clearly been useless
until we see this one today.
The patch we needed to test needs completion, so it's of no use to
continue building it until this happens.
Also for some reason, the x86_64 build of GTK3 takes forever and times
out (the same build for 32-bit x86 is done quickly as expected) on
repeated occasions. Since this is unneeded right now, rather than
wasting time on this, I just delete this dep build to use the pre-built
MSYS2 package.
Rewriting commit f8cdec1883 by Jernej Simončič for the development
code (which has a slightly different list of languages).
Also adding the meson version of this change.
Since now InnoSetup fully supports UTF-8 isl (as long as they have a
BOM), let's stop converting translations. Then we also avoid all
conversion errors and get a simpler/more robust build process.
I noticed in our build logs such output:
> Saving to: ‘Basque.isl.53’
Wget does not override same-named files and would append a number. The
thing is that we are not supposed to have other .isl files over there,
but I think current Windows runners on Gitlab are not properly wiped
out. That must be why we get remnant of old files.
Anyway this will make sure we override, hence use the last version of
translations (otherwise we are stuck to old versions as long as they are
not wiped out, since the downloaded file is not properly named).
This tool seems like a mess with various implementations (maybe
distributions patch it?). I'm trying to tweak the script so that it
works at least on the Debian testing/bookworm CI and on my Fedora 33
desktop (and hopefully on more, if not all distribs).
Note that I first thought to use the full option name (`--auto-display`)
but I just got the same error again. It seems xvfb-run from Debian
bookworm just doesn't have this option, and only the older option
--auto-servernum (which is said to be deprecated in favor of
--auto-display in Fedora's xvfb-run for instance, but apparently not on
Debian). At least this works on all distributions (or so it would seem).
Fixes:
> xvfb-run: invalid option -- 'd'
The [[ ]] is not POSIX, hence less portable.
I see our `ninja test` calls in Gitlab CI output a:
> /builds/GNOME/gimp/build/meson/run_test_env.sh: 7: [[: not found
(though it doesn't break the tests)
