This flatpak is tested and working.
I have not yet verified though if it has the maximum options enabled
(guessing not), but only that we had at least the required dependencies
at least.
When we will merge, it will become the nightly flatpak and the current
nightly can be used to follow the 2.10 (future) branch.
This is the script I have been personally using for some time now to
build the devel and nightly flatpak on my server regularly through cron
files.
It is not the best script, arguably, and we can most likely do better.
But for now, it worked for me and is a first step toward maybe making
official nightly flatpak builds soon.
In particular a bunch of dependencies were moved to the BaseApp.
Dev flatpak is actually a bit useless now (since last dev release is
older than stable). But I keep the dev manifest around to make it easier
to update for the future when we'll have a new dev release.
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 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.
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
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.
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
In particular, I didn't have the correct metadata because I was missing
appstream-compose. This should be a dependency of flatpak. But for the
time being, let's just have a note in our howto.
