Following 4cbb9360
Most of the distros provides the dictionary pre-installed but
some like Gentoo not. So, let's bundle "share/libthai" for
maximum portability.
It was changed to "GIMP-continuous-ARCH.AppImage" because
I had hope of linking GitLab artifacts on gimp-web (which failed)
so let's use "GIMP-GIMP_VERSION-ARCH.AppImage" again.
Also, uppercase AppId 'Continuous' suffix to be consistent with Flatpak.
Partially reverts e01973b9
This makes the AppImage .sh script multiarch aware and
make Debian pipeline a GL 'matrix' for easier maintenance.
As consequence, making an arm64 .appimage is pretty easy now,
so let's make one since this arch is not that rare in Linux.
This provides us fine-grained info on how much time each step take,
making easier to spot stuckness and to quickly understand the logs.
'gimp' jobs normally do not take advantage on this due to log limits
(they expand and crop the log), so I adapted them to only output errors.
---
Also, to reduce logs, all jobs were reviewed with proper GIT_* variables.
The "AppImage platform" don't have releases, every tool is blending edge.
Obviously, it is too prone to broke, and for the first time it got broken.
So, let's move it to a separate job and with less frequency to not broke CI.
The latest appimagetool inserts a runtime with static libfuse in the .appimage.
It also makes the .appimage run way faster and slightly better compressed.
Thanks for helping me with this, @samueru
This avoids calling host libs, fixing the last pendency on !1440 desc.
In other words, the AppImage now can be run, in thesis, in any distro.
Thanks for helping me with this, @samueru
The previous comment is wrong, because GIMP never had WMF export. Let's
clarify, however, that WMF support is still tricky because of some
options available at configure time regarding 'fontmap' and so on.
Following 78665ca372
Since our official builds tends to be vanilla (only using meson
standard options), there is no need to shipping these lua files.
This commit can be reverted in the future if Lua is stable again.
- Simplify three functions into 'bund_usr' (similar to 'bundle' in Win script)
- Add 'wipe_usr' function (similar to 'clean' in Win script)
- Verbose the steps of AppImage making
- Log (go)appimagetool bundling of deps (not only the the .appimage making)
- Change AppRun to be more clear about our .appimage compatibility
This refactoring is not perfect but is good enough to anyone understand
how our AppImage is made just reading the script.
This should be enough to not "annoy" developers with repetitive ninja and
not too relevant appimagetool output. This makes easier to devs to look at
the runner log without needing to revert 9653e50e (the revert/split would
make us lose .appimage in some custom Deb pipelines and 50% of ccache hits).
Note that we still need the iso_639.mo files at runtime. Only the XML
files don't need to be parsed anymore at runtime (they are parsed at
build-time now).
The ARTIFACTS_SUFFIX is being dropped on building scripts because:
1) This will make possible to further simplify Installer scripts in other commit
2) There is no script that uses multi-arch _build/_install at same time on CI
However, there are two use cases: to build Debian and flatpak; and, on Win,
to build on CLANGARM64 and CLANG64 (?). But probably they are pretty niche.
I suppose that people who build on Debian (or other dev-oriented distro)
willn't want to mantain deps in two sys prefixes (pkg and GNOME runtime)
+ two gimp prefixes (out of sandbox and sandbox) due to huge storage use.
Why someone would want to build with emulation on Win ARM64 I don't know.
Anyway, people that know how to do this stuff probably can change the .sh.
3) When building locally, the contributor doesn't need to know the arch at all.
Indeed, without this suffix, the scripts are inline with gimp-web-devel and
prevent some first-sight confusion when reading them that I've seen on IRC.
4) These arch suffixes can be understood as '_install-*' being distributable
which is not true. So, without this suffix we could make more clear
what is a package (when GitLab fix the glob bug in 'expose_as' someday).
---
Despite .gitlab-ci.yml not being a script, it needed to be touched too
because cross scripts depends on Debian jobs due to gimp-data MR.
The numbering is now inline with actual the order of jobs on CI
to make easier to understand what the numbers represent.
To understand why bundling is number 2 see: d09a2a6f and 2dc6f411
The storing of Windows scripts was changed to make easier to
call them, to better convey that they work outside CI and
to be consistent with other build/ subdirectories.
* Since the appimage is for testing purposes, let's use system 'libc'
* Hardcode python path since the wildcard wasn't expanding misteriously
* Improve system theme recognition making way simpler
They were generating a distracting output in CLANG* shells, as noted by
@lillolollo in a comment from MR: Infrastructure/gimp-web-devel!65
In the process, make AppImage and Windows (native) scripts use these
variables, without hardcoding the same variables from .yml anymore.
Creating a temporary config directory for the in-build GIMP (run as a tool or
for unit-testing) is not done as a build target anymore, but in the
in-build-gimp.sh script as a unique temp directory, then cleaned out on exit.
This has a few advantages:
- It is properly cleaned out once the build ends (instead of leaving a full
config dir as trash inside the build dir).
- It is not reused from one build to another (with risk of carrying bugs and
issues over).
- Every use of the in-build GIMP will have its own config directory, and in
particular when they are called in parallel.
As a side update, make sure that all `gimp_exe` runs depend on
`gimp_exe_depends`.
As hinted in d09a2a6f
We now use the word 'bundle' to signify "program files in the same prefix"
(e.g. .appimage, .zip, .app). This is in line with our source and dev-docs
(just take a search in the repo). So, appimage and windows scripts changed.
The word 'package' normally means "program files distributed for install in
the same prefix or not" (e.g. .deb, .msi, .dmg). This is in line with CMake
naming of some commands, but meson prefers to call 'dist', which we use more.
So, this partly reverts some things of GNOME/gimp!1171 and reinforce others
for even more "rationality" in the overall build structure of GIMP.
AppImage is pretty fast to make, like the win crossbuild; and portable,
being very appropriate to do quick tests on Linux when pushing to git.
The overall organization of Debian jobs was changed to take advantage
of this and make things less complicated (but less clear at first sight).
I reinforce that this was the most efficent way to make the AppImage.
