I completely forgot that since the installer is built on a Windows
runner, I cannot expect a standard Linux shell syntax.
As a consequence, commit de9a171a19 broke the "win-installer-nightly"
job with the following error:
> The token '&&' is not a valid statement separator in this version.
Rather than trying to find the equivalent command to run on powershell
or whatever, let's just compute the checksum at the end of our installer
creation script.
Synced from the beta flatpak. The previous manifest rules were building
fine on Flathub build servers, but not on GNOME CI ones. It resulted in
a bunch of "ISO C++17" errors when building ilmbase.
Maybe just restricting to C++14 through build fine would have been fine,
but anyway let's also update the dependencies in the same time as we
were outdated.
As per state in the wip/release/2-99-8 branch of the beta flatpak.
In particular, we update some dependencies (poppler, ghostscript and
SuiteSparse).
It should also fix the master flatpak build which seemed to fail on
downloading SuiteSparse sources. Since their upstream moved their
tarballs to be downloaded from Github, it should take care of this issue
by side effect.
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).
Same as MSYS2, add a patch to fix keyboard input when using IMEs (which
should hopefully fix#1603). Note that this patch should be in the next
release.
Also remove the Windows Pointer Input Stack support as it is in 3.24.30.
Finally apply the patch from gtk!3661 for testing (instead of the patch
from gtk!3275), as it is supposed to fix#5475. This is the reason why
we still build our own GTK3.
We don't know when the next GTK3 release will be and this is cool enough
that we want to test it soonish, even more with MR !458 coming soon with
a Preferences option.
The dll_link script would overwrite the same dependencies over and over,
for instance when needed for several binaries, but worse when available
in several source directories. In our case, we look up 2 source
directories: our install prefix first, then the prefix for MSYS2
pre-built packages. So it turns out we would be overriding any
custom-built package also installed through MSYS2 (such as our patched
GLib, see my previous commits).
As a side effect, it should also make the packaging step faster as we
don't re-copy unecessarily the same DLLs over and over again. The first
one to go in stays in.
Since gio searches its modules based on the paths as advertized by the
pkg-config, let's just move the pre-compiled modules (by MSYS2
packages). We build the same version of glib2 with the same options, and
only one additional patch. So this should not be a problem to use the
pre-built modules rather than rebuilding glib-networking too.
The MSYS2 package for glib2 does not include the patch to reduce delays
of disconnected volumes (glib!2020).
Let's make our own build in our CI for our installer (hence also
experimenting overriding MSYS2 packages when necessary).
Except for this patch, this is the same build as MSYS2 and same option,
as described in:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-glib2
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.
- dri access needed (cf. commit de8be943 on our Flathub repo).
- GNOME runtime still only provides lcms 2.10 (even in its master build)
and we need version 2.12 to avoid some crashes (cf. commit ae60863e
from our flathub repo).
Trying to keep the differences to a minimum. There are still some, like
the extension point is absent from the nightly manifest, but I'm not
sure if it makes sense to have it there.
Also top "cleanup" list is different but we should probably take a
closer look at this. Maybe it's outdated on both sides anyway.
This reverts commit 61389adfa0.
I was initially hoping to debug why the GEGL `master` HEAD was
presumably failing to build (according to the reverted commit) but it
actually doesn't (as tested in a feature branch's CI) even though I
don't see any recent change looking like a build fix. So let's just do a
simple reverse. :-)
- Poppler 20.10.0 to 21.04.0
- poppler-data from 0.4.9 to 0.4.10
- OpenBLAS from 0.3.9 to 0.3.15
- libde265 from 1.0.7 to 1.0.8
- gexiv 0.12.1 to 0.12.2
Add patches and dependencies needed to build the development
version of GIMP. Also switches the in-tree manifest to using
the nightly branch of the GNOME SDK and meson
as the buildsystem.
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.
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.
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.
- libwmf patch for issue #4061 is applied upstream (libwmf). Even though
no new libwmf release happened, the MSYS2 package applied the patch to
libwmf 0.2.12. So it's in our installer. Thanks to lillolollo for
staying on top of things, as usual.
Cf. https://github.com/msys2/MINGW-packages/pull/6977
- glib permission issue (#4594 about GIMP preventing the third-party
software Spotify from starting) is included since glib 2.67.6/2.68.0.
Since MSYS2 uses glib 2.68.2, it's all good.
- patch for deprecated GTK+2.24 was kept in `master` repo mostly as a
reminder of having to deal with issue #1082 (former bug 780979) about
transparent windows from other software interfering with GIMP. This
was fixed as gtk!2767 which is available since GTK 3.24.27. MSYS2 uses
GTK 3.24.29 to this day.
Note that this patch is still relevant in the GIMP 2.10 series (hence
in gimp-2-10 branch), not in the current GIMP 2.99 series.
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.
Add GObject Introspection libs, python libs and various binaries. Not
sure why we need 3 python binaries. This would need to be investigated
and possibly cleaned up a bit. Similarly maybe it would be better to be
a bit more selective about what we take from lib/python3.8/ folder
(looking what's in there, I wondered if some of the stuff were not
pulled by some dependencies and/or should maybe be filtered out).
But for now, let's make the InnoSetup scripts happy.
In any case, the resulting installer was tested and now Python plug-ins
work successfully. Wouhou!
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.
I left the version I was using while testing, but this is obviously
wrong as we would always forget to update it (actually even now it was
wrong as it was producing an installer versionned 2.99.6 whereas it
should have been 2.99.7!). Instead let's grep the major/minor/micro from
the build system.
- Adding a patch sent to me by Sylvie Alexandre meant to help aalib
build on MSYS2 for Windows 32 and 64-bit.
- Additionally, add an additional patch from myself because it was still
not building properly.
- Also update the config.guess|sub files because the original ones (from
2001!) were just too old and not properly recognizing the host mingw
system (especially the 64-bit one apparently) in the MSYS2 CI jobs of
GIMP.
- Finally regenerate the whole aclocal/libtoolize/autoconf/automake
build system because these old files just don't play nice with recent
autotools though the source files still regenerate fine (despite with
some warnings, but nothing blocking).
- Add crt-git dependency because libws2_32 is in there.
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.
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.
These files I'm adding are currently being requested by the installer
script, even though I'm not sure at all how much needed they are,
especially for some of them (because I could successfully create an
installer by just commenting these out in the installer script).
