The Win32 build was not taking the new path of git-version.h into
account and was outputting these errors:
> ../build/windows/gimp.rc:2:10: fatal error: git-version.h: No such file or directory
> #include "git-version.h"
> ^~~~~~~~~~~~~~~
I completely forgot to rename the appstream file according to the new
ID. While doing so, I also make it a .in.in file, with initial
processing by the autotools. Indeed I need @GIMP_COMMAND@ to be replaced
by AC_CONFIG_FILES().
Finally I fix a badly closed XML tag (which reminds me I should always
test a commit, even when it's a simple non-C 1-liner change!).
...the installer component
The warning is actually not only about the installer, but also covers
the installed version of GIMP. The warning was resurrected from commit
6f0bb88e43 and slightly reworded.
In configure.ac, add --enable-windows-installer option (off by
default), which should be set to generate the necessary files for
the installer translations during the build. Using this option is
only supported when building from git, since the installer files
are not included in source tarballs.
Rename setup.isl.desktop.in to setup.isl.in, and instruct intltool
to treat it as an .ini file explicitly.
Delete generated message files during make clean.
Remove the installer graphics credits, since we use a different set
of graphics in master, and will probably use yet different set of
graphics for 2.10.
Add strings for the MyPaint brushes component. The setup script in
git doesn't use those yet, but this lets translators start
translating them.
Use intltool for managing the translations for the Windows
installer, instead of manually maintaining the translated message
files.
The message files are generated in the source directory, under
build/windows/installer/lang, as part of the build, and can be
subsequently used to build the installer, as before.
Though the bug was mostly fixed, it seems to still happen on Windows XP,
where apparently no content type had been registered for SVG.
GTK+ developers don't seem too keen to patch GTK+ 2.24 for a platform
which they don't support anymore.
Also if not mistaken, GIMP does not officially support Windows XP
anymore either. A patch though has already been provided by Edward E.
and it really doesn't look like it could break anything since it just
adds a last "else if" when everything else failed (and inside a #ifdef
affecting only WIN32 builds).
So let's just add it in our builds at least. We still don't have support
for it, but I see no reason to just refuse a minor patch which won't
break anything else.
The BaseApp json used for all 3 builds (stable, dev and nightly) is
common so just keep the one made available in the flathub upstream
repository. The patch also applies to the BaseApp only.
... interfere with GIMP UI events
Add a GTK+ patch to ignore top-level transparent windows when
looking for the top-level GDK window at a certain pointer location,
in the Win32 GDK backend.
The BaseApp manifest got a bunch of fixes, mostly to have all the
dependencies successfully build for aarch64. The current manifest should
therefore correctly build GIMP for i386, x86-64, arm and aarch64.
See: https://github.com/flathub/flathub/pull/124
The existing graphics are still from 2.8 (specifically, the have a
"2.8" caption, so we can't use them for 2.9); these are the
graphics used for the 2.9.6 installer.
... makes the list scroll down and select the next item
Adjust the file association list height to be a multiple of the
item height, to avoid this issue.
I had an error in the previous commit (2 args in 1). Also adding access
so that the file `bookmarks` is visible from the contained GIMP
(otherwise bookmarked folders are lost in flatpak and that's bad
experience).
For some reason, the "cleanup" tag won't delete the files produced by
the BaseApp inside the main GIMP manifest (I still need them for build,
but want to delete them for runtime).
This is a workaround to delete them with a few command lines for now.
See: https://github.com/flatpak/flatpak/issues/1082
Keeping all dependencies inside the main manifest is very annoying
because flatpak-builder will check them every time the package is
rebuilt. Worse, sometimes the cache won't be hit (even though it should
have), resulting into a rebuild of many dependencies. I create a BaseApp
build which is the recommended process (and not creating our own runtime
based on GNOME one's, as I first thought) which won't need to be built
as often as the main manifests. The other advantage is obviously that
this BaseApp can be shared between the dev and nightly (and likely even
the stable later) builds. I will only keep differences inside the main
manifests (for instance lcms2 which requires a higher version on master
than on the GNOME runtime and the last dev release).
I also move webkitgtk as the first dependencies since it takes too long
and flatpak uses a sequential dependency graph (so any change to a
previously listed dependency, even when actually unrelated, was
triggering a rebuild of webkitgtk!).
Only remaining issue is that I don't manage yet to run the cleanup of
the BaseApp at the end of the main manifests (for files needed for
building, but not at runtime).
So I discover today that there is an option --ccache to request
flatpak-builder to compile using ccache, which is obviously a great idea
when rebuilding the same deps too often. Update the howto with the info.
Not sure why, because flatpak-builder used to compile webkitgtk just
fine, but not anymore. I get now a "call of overloaded ‘abs(gdouble)’ is
ambiguous" error. It looks like some header may have been updated in the
flatpak environment and causing multiple abs definitions. Using fabs()
instead works around the issue.
This is a first try at creating a docker-based build environment for GIMP.
The file has grown alongside building babl, GEGL, libmypaint and GIMP on a RHEL host running Docker. The main purpose of this image will be to serve as a base for building packages like Flatpak, AppImage and others, and serving them from download.gimp.org
it is not optimized at all, pulls in some extra packages, misses some optional dependencies, builds as root, ...
build-export is actually a low-level tool used by flatpak-builder. When
using it directly, debug and locale extensions were not extracted as
separate extensions (unless tweaking complicated command lines), ending
up with a huge GIMP flatpak with the current procedure.
Since flatpak 0.9.5, the option --export-only has been added to
`flatpak-builder` so that the build and the export can be made in 2
separate steps while using the high level procedure.
See: https://github.com/flatpak/flatpak/issues/824
Ell