The language files provided by the InnoSetup project (either the main
ones or the "Unofficial" ones, i.e. less maintained ones) at least
provides the name of the language, possibly in English, ideally
self-localized in its own language.
Unfortunately Kabyle didn't have any language file so we were using the
Default one, which ended up showing the lang as a duplicate (and very
wrong) "English".
With this commit, I add code to provide our own very basic base language
file, which would at least contain the language name. There is also a
concept of language ID to be verified in Windows-provided list.
Unfortunately it doesn't have any (actually it was id-ed 0x1000 like
many other languages, which looked therefore to be the code for an
unsupported lang). InnoSetup docs tells us to leave 0 then. We can add
the ability to set a specific code later in the template if we add other
un-provided languages and if they have their own lang id.
With this base infrastructure, we should be able to better support more
languages.
Unfortunately the weird encoding of a string to bytes to get the UTF-8
BOM worked on my local machine, but not on the Windows CI. I'm not going
to fight it and fallback to a shell script.
I am guessing it should work fine on all platform since we use basically
the same sed call in build/windows/gitlab-ci/installer-gimp-msys2.sh
already.
Inno-Setup absolutely requires it to recognize UTF-8 translation files.
This should hopefully be the final fix to #8338.
Note that this fix is full of workaround for meson bugs or limitations.
While it was a one-liner in autotools, added to the existing rule, here
I have to add an additional (non-relevant) target rule, then uglily work
around 2 bugs:
https://github.com/mesonbuild/meson/issues/1564https://github.com/mesonbuild/meson/issues/7696
I can't say I'm so happy about the resulting change, even though it
seems to work. If anyone can propose a nicer build rule, it would be
welcome.
Whenever we have an element without translation, we try to use the value
without a `xml:lang` attribute. That selector was wrong though, which
leads to https://gitlab.gnome.org/GNOME/gimp/-/issues/8338, which should
now be fixed.
Why:
1) users can install .scm scripts to plug-ins dir
2) Crashing scripts do not crash extension-script-fu
Scripts (.scm files) have a shebang and are executable
and in a same-named subdir of plugin dir.
Interpreter/scripts create PDB procs of type PLUGIN unlike extension-script-fu
which creates PDB procs of type TEMPORARY, owned by extension-script-fu.
Unlike other interpreters, the interpreter is-a plugin outright,
not by virtue of the script subclassing GimpPlugin and using GI.
More details in /plug-ins/script-fu/interpreter/README
(1) On recent meson versions, it fixes this error:
> extensions/goat-exercises/meson.build:108:0: ERROR: i18n.merge_file keyword argument 'output' was of type array[str] but should have been str
As docs explains, 'output' only accepts one item in i18n.merge_file().
This bug also happens on older meson (but there the reported error is a
lot less useful as it doesn't mention local meson build code).
(2) `setup.isl.xml` is a temporary intermediary file used to create the
Windows installer. It must not be installed.
(3) `gimp30-windows-installer.mo` itself is only used to create
`setup.isl.xml`. It must not be installed as well.
(4) gimp-tips.(its|loc) files (same for gimp-tags ones) should not be
installed. They are only temporary data.
(5) Fix environment variable: s/GETTEXT_DATA_DIRS/GETTEXTDATADIRS/
Fixes:
> /usr/bin/msgfmt: cannot locate ITS rules for ../../../data/tips/gimp-tips.xml.in
(6) Fix various bugs in the *.setup.isl files creation in autotools
build (typo, wrong files used, order of options in `xsltproc`
apparently meaningful, and so on. I guess the autotools build was
not as well tested as the meson one :P).
(7) Fixing the unit test verifying language lists consistency.
(8) `setup.isl.xml.in` must be added to the distribution.
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
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.
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).
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.
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).
Jehan