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).
Ported from: 3772514155
Just to note, ALL the previous "Sync with..." commits were tested in flathub
and gnome-nightly flatpaks, and this actual one (and future ones will be) too.
This is the pendant commit to the one I'm going to commit on the beta
branch for RC1. There in fact was a way to always use the
$XDG_CONFIG_HOME folder, unconditionally (and prevent the weird
inconsistencies of having config folder in .var for some flatpak
installations and in XDG folder for others).
See: https://github.com/flathub/org.gimp.GIMP/pull/287
This makes the bundling script an "extension" of the building script, similar
to what Cmake-based projects does on Windows. By the way, this is inline with
the recent changes which clarified that bundling is just a finalization of the
building process when a bundle is aimed. See: d09a2a6f, 2dc6f411 and 9d86492b
Despite the good intentions, 4f965557 makes Debian contributors who
follows gimp-web-devel instructions to download more deps than needed
and makes unclear what are the crossroad deps. Let's fix it.
This makes crossroad and msys2 scripts clone without the "_" prefix, which
will improve quality of life of most contributors that just clone them.
Just for consistency, also remove the "_" prefix from other pices of code.
The original script required a specific WinSDK version. Now, it autodetects.
This is useful if we need to move to another runner and welcome locally too.
Also, downloading the arm64 artifact was mandatory to get a x64 msix, which
is silly. Now, packagers are free to package to either arm64 or x64 alone.
This is useful locally but could be useful on CI too when some arch fail(?).
It's perfectly reasonable that someone can misunderstand the scripts info in
gimp-web-devel and try to run them not from git root but from their dirs. So,
let's add that possibility as a fallback (a pretty natural one by the way).
Also, change the error message to direct contributors to gimp-web-devel.
Ported from ca5688bf6d
Just to note, we are already not using Assembly code
in 10bit and 12bit libraries. So, no feature dropped.
---
Also, little fixes to some dev docs regarding Clang.
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.
- Dependencies not present in GNOME runtime are now built in deps stage
This makes easier to follow the progress of the overall pipeline and
to know how much time was spent on each stage
(like crossbuilds, the artifact size is brutal but only lasts 2 hours)
- babl and GEGL build now have output in GitLab runner, unlike others deps
This makes clearer to spot if something goes wrong in these crucial deps
- GIMP is still built in its stage but now alone, like Debian and Windows
This makes possible to retrigger only this job when runner errors occours,
without needing to start monolithically the deps+gimp build from scratch
Also:
- babl, GEGL and GIMP now have meson-log.txt artifact like other builds
- dist job now have all commands self-contained on its script (needs to
be merged to be tested according to my tests)
See: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/1670#note_2152565
This makes the NIGHTLY flatpak use the local GIMP source. This reduces the
internet usage and makes possible to generate .flatpak from every branch out
there, which turns the flatpak finally really useful to code development.
Of course, this makes impossible to run 'flatpak-builder NIGHTLY_manifest.json'
without cloning or downloading GIMP code, but this is not a regression since:
1) the NIGHTLY manifest is in-source to begin with, so same thing as our other
building methods (except macOS), which runs over the code they are stored
2) the chances of someone downloading partial source code (the NIGHTLY manifest
alone) so being unable to build are low since this file isn't too easy to find
3) even if someone do this and don't like, we are not violating flatpak building
pratices since this option exists to be used (and will be in NIGHTLY only)
Despite we not building gimp nightly on aarch64 we need to sync with beta.
So, this updates to LLVM/Clang 18, which fixes 'gexiv2' and 'poppler'
problems with deps on that arch. 'json-c' and 'luajit' were adjusted too
with the use of proper build options to fix errors.
As decided in #10922, 32-bit will be tolerated in 3.0 series because of TWAIN.
So, let's package only the bare minimum files to the 32-bit TWAIN plug-in work.
This reduces the final installation size by approximately 215MB.
It's a common pratice to tell the user what version is being installed
even if this is somewhat obvious (the user opened the installer, he
should know it). Many installers do this and Win MSIX installer too.
However, there is no sign in our Installer about what version is
being installed (the reused splash/intro image doesn't count because
it isn't always different at each micro or revision, and text is small).
---
To accomplish that feature, the Inno langs needed to be patched since
Inno actually forbidden to use that feature when we have a Welcome page.
https://groups.google.com/g/innosetup/c/w0sebw5YAeg
But 'UninstallAppFullTitle' from the following langs couldn't be patched:
- Japanese
- Lativian
There are two approaches regarding the icon for Windows installers .exe:
1) same icon as the app: this give more identity, but creates confusion if
you saved the installer in the same dir of the installed app shortcut.
This approach is also confusing in the task bar (e.g.: running GIMP
stable while installing GIMP unstable);
2) generic icon (e.g. a box, a cd) provided by the tool: more generic if
you downloaded two installers generated by the same tool (ours is Inno)
I choose a middle ground and created a icon with: the app icon and an
"installer" symbol (a package box), which conveys the best of two words.
This also fixes the Inno inborn bug of the unninstaller with install icon.
After running almost all the py plug-ins, I noticed that few py modules and
pkgs are used to justify the need of a slightly faster build time with .pyc.
In the actual bloated status (with all .pyc), lib/python* is about 260 MB big.
With the bare minimum .pyc after the tests above, python*/ is less than 90.
So, let's purge the .pyc at bundling time (I'm not reinventing the wheel,
Krita do this too), which reduces the .zip bundles (so the Inno and MSIX
installs) in 170MB, the Installer .exe in 45MB and MSIX download in 60MB.
---
Let's also disable any .pyc generation, since GIMP installed with Inno in the
system-wide (aka admin) mode or installed with MSIX both doesn't handle well:
py plug-ins work but have CLI errors, unlike Inno user-mode and .zip bundle.
Jehan