It was only used for the gimp-win-a64 job and was coming from MSYS2 repository
which already dropped it:
a98352b2ba
The first patch is still needed as the upstream fix is meant to appear in clang
18 according to bug report, yet our CI still uses clang 17.0.6. See:
https://github.com/llvm/llvm-project/issues/51286
This is similar code to what I added for the Windows builds, except that here
it's because deps-debian-x64 will also end up feeding dev-docs job too.
Right now our tagged build of GIMP produces docs for unstable versions of babl
and GEGL.
Aaaargh! I think this was the main issue which would explain why the problem was
mostly happening on the packaging job. In this job, we were still consistently
calling `pacman --noconfirm -Suy` (i.e.g "Synchronizing package databases")
which we had stopped to do for the CI builds as that was highly increasing
chances of locking pacman's process.
This is the command suggest by MSYS2 developers here:
https://github.com/msys2/MSYS2-packages/issues/4340#issuecomment-1887695290
They also say to run it outside the MSYS2 environment, which is why it's in the
CI rules, not in the shell script.
Honestly at this point, it feels like we are just stacking weird workaround to
get it to fail not too often. ;-(
Two shell commands got merged as one line. This seems to work fine on
hmartinez82's runner, unlike on our new runners. Anyway it is likely good
practice to clearly separate the commands.
Fixing:
$ if ($stuck -eq "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck" Write-Output "Cleaned previous stuck pacman" }
Remove-Item : A positional parameter cannot be found that accepts argument 'Write-Output'.
At line:279 char:26
+ ... q "True") { Remove-Item -Force -Path "C:\msys64\var\lib\pacman\db.lck ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Remove-Item], ParameterBindingException
+ FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
As suggested by Jehan, the manifest will be configured by meson.
Of course, for CI compliance, this pushes the job to a further stage:
'packaging', which is what Flatpak is about, after all.
The distribution job name has also been changed, because when Store job
is merged, this will be the new nomenclature of the distribution jobs,
which was not changed since !1171 by lack of time.
Now, the script reads the major.minor version automatically from the main
meson.build file, reducing maintenance work, which is already especially
high regarding flatpak because of the natural hashes updates etc.
Also, a small organization made to make the code more humanly readable.
* Fixes an ARM .patch that stop to working after !1171, causing job fail
* Changes the logic of system upgrade (pacman -Syyuu) to be less redundant
This also improves consistency with the Debian jobs
The CI crossbuild job now use the same main script (and the same
sub-scripts of linking and debug generation) of the native CI for
packaging. These unified scripts greatly facilitates maintenance.
The crossbuild deps script is now more consistent in relation to the
native one. As this is polished, the cross one is now polished too.
A crossroad gimp build script was created with a more clear code.
Also, finally make the script for packaging only, removing build step
stuff that shoudn't be here (glib-schemas generation) since this causes
disparity with the Local native build; and adding some packaging
decisions that shoudn't be in the installer scripts (eg. specific
folders of ghostscript, glib; no share/themes), which also facillitates
INNO (and future MSIX) maintenance.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
The local builds now can use the same script of CI for sake of time.
The compatibility layer is very simple and makes the script more
used/tested, therefore more reliable.
Also, remove some redundacy on the code for better maintenance.
Debian changes:
- Since autotools has gone, we don't need to specify 'meson' in the
debian job and others.
- The "INSTALL_PREFIX" was renamed for the more usual "GIMP_PREFIX" and
the meson sintax of Debian jobs was also updated.
Windows changes:
- Then, clarify that the win64-nightly and win32-nightly jobs are, in
fact, in the 'packaging' step, since we don't really "distribute" GIMP
in .zip and the commands are almost the same of the packaging .SH
script, without scripted optimizations for Inno Installer (or future
.MSIX), crucial for distribution.
- We don't need to specify "native" sufix in any build since they are
the rule and cross builds are the exception.
General changes:
- The job names was changed to be more consistent and in accordance
with the folders present in the artifacts.
- The 'nightly' sufix was removed from the Inno Windows Installer job
and others, since this doesn't reflect the real build frequency.
- The scripts filenames are altered to stay "in order". This is not
essential but ultra convenient since it is easy to view and search.
(The -uni suffix is explained in a further commit)
- All artifacts names now have the commit to avoid apparently duplicate
files when downloading same step artifacts from different projects.
- Finally, rearrange the order of jobs rationally: first the OSes and
archs (from the most free and modern to the most closed and legacy),
then the stages (from 'prepare' to 'analysis'), ending with the
frequency of jobs (from the most frequent, called at each push, to
the least/weekly).
Overall, this changes, although difficult to review at the first
sight, will avoid in the future quite "dumb" issues like:
GNOME/gimp#10195
This is in part a port of commit 6f921b27bb from gimp-2-10 branch, except that I
could not easily cherry-pick because too much had changed already in the master
branch.
There are also a bunch of additional changes in some other glue scripts.
Also some rules which were in the 2.10 branch don't apply to the main one, such
as Python being copied from the x86 binaries, since clang-aarch64 has Python3
(unlike Python2).
See discussion in #9170 and !1091. It looks like this soon won't be a problem
with a recent llvm-windres (which is now patched). But until then, let's patch
upstream GIMP but only for this build.
Note: the additional `rm` call was done for this error:
> + mv _install-arm64 /home/SYSTEM
> mv: cannot move '_install-arm64' to '/home/SYSTEM/_install-arm64': Directory not empty
I guess the home directory is not properly wiped-out between runs, which is not
a huge problem as long as the runner is private to our project. Let's clean
things ourselves.
Crossroad repo was finally moved to Freedesktop.
See: https://gitlab.freedesktop.org/freedesktop/freedesktop/-/issues/477
This should avoid the too many failures we have lately on TuxFamily
infrastructure (and also gives a proper bug tracker for Crossroad). I am very
thankful to TuxFamily for all these years! :-)
Let's not be said that I moved the repo because I don't like this friendly FLOSS
host anymore. I just needed something different for Crossroad project now.
The creation of the BMP welcome images for the Windows installer (part of
-Dwindows-installer=true build option) fails in the Windows job. After much
debugging, I could run GIMP, yet it was not enough. One of my hypothesis so far
is that the environment variables for DLLs won't work, since all the DLLs must
be in the same directory as the main binary (though with the WSL thing, I am
unsure, maybe it is still supposed to work), which only happens once GIMP is
installed. So GIMP runs successfully but not plug-ins.
Anyway I wasted too much time working on this and without a local Windows, it
just takes too long (mostly testing thanks to the CI) and is frustrating. Let's
just move to building both the localization files and the images on the main
Debian job (gimp-meson-debian), then use these as dependencies of the
win-installer-nightly job, i.e. when building the installer.
After discussion with Jernej, InnoSetup should now work better with rescaling
a big image properly to the window size, yet the ratio should still matter.
Apparently the welcome image is a hack and this is why it requires specific
ratio images. We don't use the big size yet, but since Jernej told me which
dimensions are expected, I already added the code for it to make it easier
later.
So anyway this code would allow us not to have to commit welcome images each
time, which are basically resized copy in BMP of the splash screen, slowly yet
surely filling up our repository with image duplicates.
After all, we develop a scriptable image editor! We should use it to edit images
and export in expected formats!
I only use this script for the devel installer for now, for testing and see how
it goes.
While Debian testing is the sensible choice for dependency requirements while we
are in full-dev mode, now we are getting closer to 3.0 release, and Debian 12
"bookworm" barely got out.
If we continue to develop at current pace, GIMP 3.0 should be released before
the next stable Debian, so we should not use dependencies unavailable on the
latest stable (otherwise GIMP 3.0 won't be distributable soon enough on Debian,
nor on Debian derivatives such as Ubuntu, Mint, etc.).
This is why we are now basing GIMP dependency requirement on Debian bookworm.
We'll likely get back to the next "testing" after GIMP 3.0 release.
This commit makes no real changes but style.
As discussed, this makes it much easier to compare commit diffs, rather
than an overlong line where you have to search which package may have
been added/removed/changed.
Switch to NASA-maintained cfitsio library for loading/exporting FITS images.
This allows us to import compressed FITS files (GZIP, HCOMP, PLIO, RICE) in
8/16/32 bit and float/double precision. It also simplifies export code using
the built-in cfitsio APIs.
The flatpak_ci_initiative.yml template we include got changed 2 days ago,
replacing the "only" by a "rules", which broke our CI file.
Cf. commit 193f63c20f87d38868c05beee6446b387b73e140 in repository citemplates.
The present commit should (hopefully) fix this error:
> Unable to create pipeline
> jobs:flatpak-nightly config key may not be used with `rules`: only
(even though the error is a bit cryptic, the problem is apparently that both
rules: and only: keys cannot be used together)
Python 3.10 introduced sysconfig.get_default_scheme() and somehow Debian decided
it was a good idea to move from the 'posix_prefix' to the 'posix_local' scheme.
See: https://lists.debian.org/debian-python/2022/03/msg00039.html
The main issue with this scheme is that it adds a local/ subdirectory to the set
--prefix. As a consequence, with --prefix=~/.local/, scripts are installed in
~/.local/local/bin/ (instead of proper ~/.local/bin/), data are now in
~/.local/local/share/ and so on.
As expected, this broke a lot of CIs for a lot of projects, as well as a lot of
custom scripts, usage of Python in virtualenv (this later case seems like it is
fixed by special-casing it in Python 3.11), flatpak, etc.
Setting DEB_PYTHON_INSTALL_LAYOUT environment variable to "deb" solves this by
changing the default scheme.
This URL is also useful to understand the issue:
https://askubuntu.com/questions/1406304/virtualenv-installs-envs-into-local-bin-instead-of-bin
As a side note, Debian is not the only one which made the mistake. Fedora also
did the same thing (and they have also their own different environment variable
to handle this): https://bugzilla.redhat.com/show_bug.cgi?id=2026979
In the last few days, our deps-win64 job started to fail with:
> $ update-alternatives --set x86_64-w64-mingw32-g++ /usr/bin/x86_64-w64-mingw32-g++-posix
> update-alternatives: error: no alternatives for x86_64-w64-mingw32-g++
The reason lies in this change in Debian testing 10 days ago:
----
gcc-mingw-w64 (25) unstable; urgency=medium
* Upgrade to GCC 12. Closes: #1023679. It is no longer possible to tweak
the installation directory for different thread models, so the -posix
and -win32 packages are no longer co-installable.
* Drop “Built-Using” from “Architecture: all” packages.
* Since the POSIX and Win32 packages are no longer co-installable,
drop support for alternatives and use symlinks to provide the full
set of command names.
* Standards-Version 4.6.1, no change required.
-- Stephen Kitt <skitt@debian.org> Mon, 12 Dec 2022 09:00:34 +0100
----
So from now on, we'll only install the posix variant of the cross-compiler.
Hopefully it will work for all packages we build.
I added this option in commit 38d6783299. It makes the script stateful, able to
remember all previously processed DLL, hence making the whole job much faster
and efficient.
- Use a relative path for GIMP_LOGO_PATH inside the gi-docgen generated
HTML, and not an absolute path taken from build dir (otherwise this
would break, for installed docs, but also for the tarball and the
developer website!).
- Also use either gimp-logo.png or gimp-devel-logo.png depending on
whether we are on a stable or unstable branch.
- Install these in images/ inside the GIMP docs folder, which
corresponds to the relative path given to GIMP_LOGO_PATH.
- The installed root dir will be $datadir/doc/gimp-2.99/, e.g.
/usr/share/doc/gimp-2.99/
- Inside this folder, the library references will be in libgimp-3.0/ and
libgimpui-3.0/ (instead of weird Gimp-3.0/ and GimpUi-3.0/). Note that
the root dir uses the application version (2.99) whereas the library
folder use the API versions. These are different in development phase.
- Archive the gi-docgen installed files, not taken from the build dir,
to avoid packaging temp files, such as the .toml files. Note that
`g-ir-docs` files are still taken from the build dir, as we don't
install them yet.
- Finally package all this in a directory before archiving in a tar.xz,
named the same as the directory (e.g. gimp-api-docs-2.99.13/ inside
gimp-api-docs-2.99.13.tar.xz).
If we want to encourage packagers to test the meson tarball (better to
do this now with development releases than later on stable releases!),
we should name it prominently. Therefore I will rename the autotools
tarball as gimp-*-autotools.tar.bz2 whereas the meson tarball will be
named gimp-*.tar.xz.
Also renaming `sources` CI job to `sources-autotools`.
The `ninja dist` step fails with:
> ERROR: Repository has uncommitted changes that will not be included in the dist tarball
> Use --allow-dirty to ignore the warning and proceed anyway
> FAILED: meson-dist
> /usr/bin/meson dist
Astonishingly if I run a `git diff` (or git status) in the CI, I saw no
changes and the dist suddenly succeeded. When I remove it, it fails
again. And of course, locally it's alright. No way to diagnose!
Anyway it's not a bad idea to leave some diagnostic logs in the CI so
here we go, properly outputting the diff and exiting the job with an
error when there is a diff. Because anyway, there should be none. It
would mean that there is likely some issue in versionned generated
files.
Maybe let's try to distribute the meson tarball next to the autotools
tarball for our next dev release, and announce that packagers are
invited to test the meson build from tarball and report back.
These were originally to distribute cross-built binaries. Nowadays, we
just use the native-made installer, which is also closer to what people
will really get for release versions.
So let's just remove these. I keep the crossroad builds as these are
still useful to detect Windows build bugs quickly, but we don't need
these distribution steps.
This also takes care of failures in the job, but since it's mostly a
useless job nowadays, rather than wasting my time investigating this, I
simplify the CI.
The gnome-runtime-images have been recently migrated to Quay. This is already reflected in the template.
Please note this MR has been created semi-automatically. If it doesn't make sense, feel free to close it.
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
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).
Since this is probably much less tested than the default vector icon
case, any bug there might go unseen for some time. So let's add a new
pipeline to check this. I make so this pipeline is not actually run on
every commit (i.e. manually only), then I'll just add a scheduled
pipeline to check the non-vector icon case at regular intervals.
This pipeline also test the icon-list.mk files are not outdated.
Fixes#950
`.gitlab/search-common-ancestor.sh`'s original authors are
Philip Withnall and Frederic Martinsons.
(Jehan/reviewer's note: script further improved by Asalle)
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
This workaround was placed to mitigate race condition.
It was useful for the time being, but not anymore.
Better solution will be introduced in following commit.
Reverting changes introduced in 9c6776fb.
Commit-triggered pipelines on `master` branch are apparently canceling
flatpak pipelines even though the flatpak jobs are not even in the
triggered ones.
In any case, these flatpak pipelines are not triggered often (only
through weekly schedule or manually triggered) so there is no need to
have such a flag.
See: https://gitlab.com/gitlab-org/gitlab/-/issues/340147
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.
Somehow the test part of the flatpak job stopped working. The last
instance which worked was 3 weeks ago, but after a lot of debugging I
realized that it is not because of any code change on our side. The
exact same commit which worked 3 weeks ago won't anymore!
The standalone bundle is actually built and works fine when tested
independently. What fails is the `meson test` inside the flatpak
environment. Somehow when GIMP is rebuilt inside the test flatpak
environment, it doesn't build the plug-ins yet one of our tests
(save-and-export) requires plug-ins to open some file formats. Note that
I double-checked, the plug-ins were well built and loading any format
works fine in the standalone flatpak, just not in this specific step.
I am completely unsure what broke, yet it is apparently outside GIMP
code. So for now, I just copy-paste the whole flatpak job which we were
including from another repository and remove the `meson test` part.
Since GIMP looks for its icons at runtime and would output warnings if
it doesn't find them, it's better to install first. Not really sure it's
ideal though, but it will do for now. Maybe I should just g_printerr()
instead of g_warning().
… based on set labels.
If the label "5. Windows Installer" is set, the MR pipeline should
trigger the Windows installer pipeline as well.
If the label "5. Flatpak package" is set, it should generate the flatpak
(not publish it obviously, yet it can be downloaded and installed
manually).
This will allow us to easily test MRs and allow people to test our code
before we merge it to the main branches.
Currently we run the job on a weekly schedule. If we keep a retention
period of 2 days, it means that people will not have access to a nightly
Windows installer 5 days out of 7, which is not useful.
Gitlab has a retention policy not to delete artifacts for last jobs, but
it apparently actually bases this check on being the last pipeline, not
being actually the last job of a given name. Since we have pipelines
running all the time, this retention policy just won't apply to our
installer job which will get deleted.
Cf. https://gitlab.com/gitlab-org/gitlab/-/issues/332142
Without this, the flatpak build is just too long and Gitlab CI just
stops logging it. So we end up with a log saying the quite useless (at
the end):
> Job's log exceeded limit of 16777216 bytes.
> Job execution will continue but no more output will be collected.
We don't even reach babl/GEGL/GIMP builds, which are the most important.
With this little trick, I am redirecting output to a log file and simply
including said log into the artifacts, hence allowing to debug the full
build.
Argh! So it turns out that .publish_nightly template uses already an
only: key so we cannot use rules: (on the other hand I guess using only:
ourselves is alright and concatenate ours and the one in the template).
Fixes:
> jobs:flatpak-nightly config key may not be used with `rules`: only
This clashes with the usage of "rules:" and is even more useless as it
is about checking success of earlier stages (yet this job doesn't need
to wait for any other job).
Fixes CI error:
> jobs:flatpak config key may not be used with `rules`: when
To get a nightly flatpak, GNOME project offers a CI template[0] that can
be extended instead of having to define everything from scratch.
At the core is the "flatpak" job that tries to build the flatpak. If the
build finishes succesfully, the result should be available as a CI
artifact as a flatpak bundle. The app id is the same as on Flathub.
Another part is the "flatpak-nightly" job that publishes the flatpak if
the build succeeded. Without this job, the bundle stays only temporarily.
This job can and should only be run on the "master" branch. This jobs is
started only when the "flatpak" job finishes successfully.
Both jobs can be triggered only thorugh schedules[1]. To finish the
flatpak nightlies setup, a schedule needs to be set.
[0] https://gitlab.gnome.org/GNOME/Initiatives/-/wikis/DevOps-with-Flatpak
[1] https://docs.gitlab.com/ee/ci/pipelines/schedules.html
The logs are just too long for gitlab and ends with:
> Job's log exceeded limit of 4194304 bytes.
This doesn't prevent the job from actually finish successfully. Yet the
day when we will have a build issue, we won't have a way to debug if it
happens close to the end of the installer creation. So let's redirect
both stderr and stdout to a log file and include it in the artifacts.
Unlike what I said in my previous commit, it still just takes too long
to build the installer, whether I move some of the substeps around or
whether I increase the max duration. So rather than increasing max
duration a lot more, let's just add an intermediate stage.
The last stage (installer creation) takes just too much time, and it
exceeded the max execution time (80 min) in my last test build. Instead
of increasing this max execution time, let's move the run of
package-gimp-msys2.sh script in the same step as the build one. Maybe
adding an intermediate stage would have been better conceptually, but
every stage also takes some preparation and finalization time (setting
up the runner, loading, cleaning the uploading the cache, etc.) and our
installer pipeline is already long enough.
So let's just go like this for now.
As a side effect, the last job's log limit was exceeded too since I
added the Python option, which should hopefully also be fixed by moving
steps out of the installer job.
Argh! My previous commit logics was right, but should have been applied
to the Windows builds (where the issue happens). That's what happens
when I hack too late at night!
This is not a fix, only a workaround for the CI to at least not fail
randomly, for the time being.
Basically since meson is running parallel jobs, even when the build
fails because git-version.h doesn't exist yet, while a depending file is
being built, it will still be built immediately after, despite the
failure. As a consequence, re-running `ninja` immediately after (i.e.
running `ninja || ninja`) will make the second build work. If it doesn't
then it's another issue which has to be fixed. But at least we work
around this known race condition in the meson build for the time being.
It's very ugly, but better than current situation. :-/
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.
The goal is to make it easier to understand which pipeline is run when,
for future maintenance, and also to make it easy to trigger a specific
pipeline through Gitlab pipeline interface.
- 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.
We had an autotools build stopping at `make check` and a separate one
for `make distcheck`. This just seems very redundant hence a waste of
resources.
So let's drop the job gimp-autotools-debian then add a `make check` step
to gimp-distcheck-debian.
Also as a side change, I move the cppcheck to being a scheduled job.
It's not such resource intensive job, nor did it take much time, yet
it's not like we use this information constantly. Moreover it never
fails anyway (so it's not like it gives much information on a per-commit
basis, unless we explicitly look into the resulting files) and with the
ability to run custom jobs whenever we want, this is far enough if
sometimes we need to generate the cppcheck analysis more frequently.
The rest of the time, having 2 jobs of this a week (our current
schedule) is far enough.
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.
Having them at each commit is counter-productive, first because these
builds take so long and second because there seems to be quite few
Windows runners. So we end up constantly waiting for CI jobs from
previous commits (so we are just constantly waiting).
This is resource over-usage. So instead, I'll just set this in scheduled
jobs. For release preparation though, we'll have to set up a workflow
later to trigger these jobs off-schedule/on-demand (I can see there is a
Gitlab interface to do this), but this can wait for when the installer
is fully generated by the CI anyway.
Bruno Lopes