intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
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.
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
I forgot to do this so GIMP 2.99.8 official release is marked as
"unknown" instead of our official build. It's alright for this one
(especially for a dev release), just setting this straight for further
builds.
Anyway we disabled use of ccache in an earlier commit 2da70b3fb7 because
of a bug in MSYS2's CPython. So there is no need to call these commands
either. Also it seems to be breaking the 32-bit native Windows build
(from CI log, I am unsure this is because of ccache, but the break
happens just after running `ccache --zero-stats`).
After some recent patch added to Python on MSYS2, in the same time as
they bumped from Python 3.9.6 to 3.9.7, our native Windows build started
breaking.
This patch modified `cygwinccompiler.py` to use CC environment variable
as being necessarily a single executable whereas if it were made of 2
commands (such as "ccache gcc"), the call was failing because the code
now tries to find a single command with this name (as though the space
belongs to the file name).
Therefore the line:
> File "C:/msys64/mingw64/lib/python3.9/distutils/cygwinccompiler.py", line 451, in is_cygwincc
> out_string = check_output([cc, '-dumpmachine'])
Resulted in the error:
> FileNotFoundError: [WinError 2] The system cannot find the file specified
For now, let's just not set ccache this way, even though this method is
normally meant to work and is one of the 2 officially proposed methods
(the other being to use symlinks named as compilers in priority in
PATH).
Also I'm not even sure ccache is useful at all right now (is cache
finally stored/reused between CI runs? I remember we tried to make it
happen, but I can't remember if we really had this properly in the end).
See: https://github.com/msys2/MINGW-packages/issues/9677
No need to have GIMP trying to run the Javascript goat-exercise at
startup. All it does is make annoying error message on console output.
We know it won't run because no interpreter is available. No need for
trying.
By enabling this option on Linux, not only will the installer language
file be generated, but the `make check` will also now validate that the
lang list is consistent with existing gettext files (see commit
8a42c6ccc2). So it's useful information to know this for instance as
soon as some translators add a new localization.
Also oppositely remove the option on the MSYS2 native Windows 32-bit
build. For Windows, we only need this option once, as we use the
language files generated by the 64-bit build.
Run InnoSetup in the Windows CI to build the installer from both the 32
and 64-bit builds.
Current limitations:
- No installer signature yet.
- Dependencies will have to be checked more thoroughly.
- Apart from babl and GEGL, we may want to make custom builds of any
package which has a patch in build/windows/patches/ (Windows-specific
patches) and build/patches/ (all platform patches).
- Plug-in interpreters (Python, Lua…) don't work. This will need to be
looked at in detail.
Globally this first automated installer build works fine though, as I
could install it in a Windows 10 VM and GIMP ran fine! So it's a first
step towards fully automated releases for Windows.
Note: Vala API doesn't build well on the 32-bit build. Not sure why (the
meson logs for GObject Introspection build are just as empty as ever),
but it won't generate the VAPI. So I disabled the option on 32-bit.
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.
