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).
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`).
This is untested on my side, because the bug only happens on native
builds with meson (our CI has cross-builds with meson and native builds
with autotools and I only do cross-builds locally) but I think/hope it
will work.
Basically we were using .full_path() because these rc files were also
used as input of some configure_file() calls which doesn't like custom
target objects as input (it wants strings or file objects). Yet a bug
in meson didn't like the colon used in native Windows full paths ('C:'
and such) when used in windows.compile_resources(). This has been fixed
by Luca Bacci in: https://github.com/mesonbuild/meson/pull/9368
Yet we just cannot depend on very early meson (or worse dev meson code).
On the other hand, if the input is a custom_tgt object, it uses the
object ID which we give as first parameter of custom_target() so we know
it's appropriately named without colons (such as 'gimp_plugins_rc').
Thus we should not bump into this issue again.
For the few usage in configure_file(), I just add a .full_path() only
when needed at call time.
Last but not least, I replace the bogus `meson --version` call by a
`python3 -c 'exit()'` as advised by Eli Schwartz:
2afa019c70 (note_1284951)
The reason is that it is apparently possible (or will be when some
reimplementation of meson will be done) that the `meson` executable
itself does not exist. On the other hand, `python3` should always be
there, as a mandatory dependency of the build tool.
In order to use an appropriate `python3`, I made the
pythonmod.find_installation() check required in our build (which should
not be a problem since it's a meson requirement as well), even when the
-Dpython option is false (this one depends on other requirements too
anyway, such as version and pygobject). This way I can call this meson
variable of discovered python in my bogus call, instead of calling a
(potentially different) python from PATH environment.
All the os.EX_* constants are Unix-only (and possibly not even not on
all Unix/Linux-like platforms, according to docs) so we should not use
them, especially for a script which we may use on Windows (we also run
it when cross-compiling from Linux, but natively on Windows as well).
Fixes this exception (which would only happen when there is another
critical issue anyway, so it's not making a bigger problem; yet it's
better to cleanly exit with an error code rather than by an exception):
> File "C:\_r\_builds\k3_3muaB\0\GNOME\gimp\build\windows\gitlab-ci\dll_link.py", line 124, in copy_dlls
sys.exit(os.EX_DATAERR)
> AttributeError: module 'os' has no attribute 'EX_DATAERR'
Also use it to fix packaging of GIMP for the Windows installer (native
CI job). The CI was indeed failing to package libbrotlienc.dll,
dependency of libjxl.dll, for the simple reason that they were on
different prefixes. By calling dll_link.py on one prefix, then the
other, we were failing to grab the deeper dependency. Now with this new
ability to set several sources, the script is able to search everywhere
(with first prefix given on the CLI call as priority).
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.
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
by adding special filler custom_target() build rules.
Basically, these build rules do nothing (a mere meson --version call),
but they ensure that `git-version.h` is built first, before the dependant
rc files are used in respective resource compiler build targets.
This still a nasty trick (not a proper solution), but it do the job.
See #6257 for additional information.
