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.
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.
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 always have to search again the InnoSetup repository for the language
file. Add the link in the failed test output so that we don't waste time
searching the next time.
Also when the new lang is "Unofficial", the installer script has to be
updated as well, because these lang files must be downloaded. Add a help
text saying this as well.
Translation files were added in commit cec3c3a159 but not to the
installer and build files, which is why "gimp-distcheck-debian" job was
failing in the CI.
For the installer, we must also manually pull all used official
language, so I am adding a test checking that the list of pulled file
matches the list from the installer script.
The MSYS2 package got recently bumped from 3.8 to 3.9.6.
At first I wanted to update our packaging and installer scripts to be
more generic using glob patterns (so that they should work now and
should continue to work even if bumping to a higher minor version in the
future). Unfortunately this would work for `package-gimp-msys2.sh` but
in `files.isi`, it would only work for `libpython3.*.dll`, not for the
python3.9/ folder. InnoSetup apparently doesn't support using a folder
as source (or maybe just a folder with glob like `python3.*`) as it
resulted in a "No files found matching" error.
So leave everything with the accurate version (because anyway it's much
better to get an early failure than only at the very last step).
We were only comparing the po list with the language list in the
gimp3264.iss. Nevertheless since we also generate the <code>.setup.isl
files, we should also verify generated files corresponds exactly to the
same list of languages.
This commit does it for meson and autotools build.
This is also how I fixed the meson list (cf. previous commit).
… conversion when some characters are not convertible.
Currently failed conversion ended up in incomplete .isl files (autotools
build) or would break the build (meson build). Ideally we should use a
target encoding which contains all source characters, but we use the
encoding as set upstream in the LanguageCodePage for the given language
file.
I'm not sure if maybe we can mix the encoding by adding our own
LanguageCodePage at the top of our generated <code>.setup.isl, then we
could just use UTF-8 for any language. It will have to be tested.
For now let's just discard non-convertible characters, assuming there
shouldn't be too many of these. It's the lesser evil in this situation.
Since we moved most of them to bin/, share/lua*/ and lib/lua/ files are
not necessary anymore (according to my tests so far at least). Let's not
include them.
Also exclude the lua DLL from the generic libraries. It is only for when
the lua option is set.
It looks like the DLL ends up searched into bin/lgi/ and other lua files
from bin/lua/. There might be better solutions for the issue, but for
the time being, it seems to work ok.
Note that ender used instead to rebuild lua with the following changes
(cf. IRC):
> src/luaconf.h:
> #define LUA_PATH_DEFAULT \
> "!\\..\\share\\lua\\5.1\\?.lua;" "!\\..\\share\\lua\\5.1\\?\\init.lua;" LUA_LDIR"?.lua;" LUA_LDIR"?\\init.lua;"
> #define LUA_CPATH_DEFAULT \
> LUA_CDIR"..\\lib\\lua\\5.1\\?.dll;" LUA_CDIR"?.dll;" LUA_CDIR"loadall.dll"
But moving files around in the installed tree is much simpler than
rebuilding the whole lua just for this.
Note that I must not install both lua51 with luajit because these are
conflicting. Let's go with luajit from feedback we had on the best
choice (though this topic itself seems a bit heated actually).
Also clean-out the unexpected file removal because now I had the
opposite case, i.e. a CI problem because of this. And from my latest
tests, it seems to work ok for the time being without, which is much
cleaner anyway. So let's go like this for the time being.
Otherwise the extension files from the 32-bit build override the ones
from the 64-build. This is wrong first because we get 32-bit executables
uselessly (even though Windows 64-bit can run them, we should install
the right ones) and also because we don't build Vala plug-ins on 32-bit
(doesn't work for some reason) and as we override the extension
manifest, the Vala goat exercise is not made available even though it's
installed.
This way, we will avoid in the future any discrepancies between
languages set in the Windows installer and available translations (po
files in po-windows-installer/) because `make check`/`ninja test` will
fail.
With compression level "ultra64" for LZMA, default value is 65536, which
is far enough (the installer file was only 100kib bigger, it doesn't
make that big of a difference in the end).
With the original value, the CI build would fail with "Out of memory"
error.
See also: https://jrsoftware.org/ishelp/index.php?topic=setup_lzmadictionarysize
Do not try to follow up on the installed ghostscript (otherwise we'll
always have to fix as MSYS2 packages get updated). Instead, just install
whatever is in the /share/ghostscript/ path (assuming there is data for
a single version, which should be the case, especially on a resetted CI
build) and excluding the /doc/ folder.
Based on available files in po-windows-installer/, here is the exact
corresponding list. Many <code>.setup.isl were not generated, even
though translations existed, and oppositely there was one (hr) which has
no translation file.
Jehan