Partially reverts af79bbe0 (regarding .debug "extraction" in cross builds)
Now, we call the split debug script from the main bundling script, which makes
similar to our macOS .app bundling script. This cleans a bit of code in .yml
and make things clearer to the mere mortals in the scripts.
Native arm64 and x64 TWAIN binaries are not built anymore. No need to
discard at dist time what doesn't exist. (32-bit TWAIN not affected)
Also, start to using our own ARM64 runners to do the dist. This is more
reliable since the shared x64 runners can (and indeed) cause long queue.
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`.
This is recommended by Microsoft for "*nix apps" and adding it to the
.exe manifest will avoid disparity between MSIX and other versions
(e.g. CI crossbuilds and CI native builds/installer/local builds).
Bruno note: This commit was repurposed after ad132ad0.
---
For some reason, on the Windows/Aarch64 runners only, submodule updates fails
with:
> + git submodule update --init
> From https://gitlab.gnome.org/GNOME/gimp-data
> * branch d1041a4d97871c85538938872d0ace69d2fc44c2 -> FETCH_HEAD
> error: Your local changes to the following files would be overwritten by checkout:
> images/README.md
> images/logo/meson.build
> images/meson.build
The big question was: why are there edits to begin with? This is supposed to be
a brand new clone!
After a bit of investigation, it turns out that the whole files have incorrect
EOL endings (a `git diff` returns every possible lines in the whole
repositories, but `git diff --ignore-cr-at-eol` returns nothing). It looks like
this breaks the submodule update.
Attribute uap4:ShellNewFileName is meant as a template file to be copied when
someone initiate the Shell "New" command (via the Explorer context menu).
Most of the work in this commit is by @Jehan.
These icons are used only by the .msix (MS Store) distribution of GIMP.
Some legacy icons are used only by Windows 10 and need to have smaller logo
than full image dimensions, so let's not use colorsvg2png. We just pass the
dimensions to use by configuring variants of the same base script.
The new dist job can produce two artifacts: a *.msixupload file
ready for submission and/or a *.msixbundle only for testing.
See the commit about the script for more details.
This makes possible to debug with DIA SDK, if wanted by the developer.
Also, this is needed to create .appxsym files for MS Store debugging.
Ideally meson should be able to install for us, but apparently it doesn't.
See https://github.com/mesonbuild/meson/issues/12977
Adds PowerShell script and proper manifest for making .msixupload
(only for releases) and/or .msixbundle (always, for testing).
As authorized by Jehan, 32-bit willn't be supported. The reasons are:
1. 32-bit is going to die when WIA plug-in is done. This can hurt reviews
2. 32-bit is being restricted in ARM64 version. This causes disparity
3. 32-bit is generating a big footprint. "This is bad for the environment"
To be clear: we are discarding most of 32-bit artifact (see point 1)
and what could not (TWAIN for x64 only, point 2) almost doubles .msix.
There is one small circumstantial reason too:
4. 32-bit wouldn't have .pdb even after GCC 14 because bins have same name
as x64, and MS don't allow multiarch debug symbols in the same .appxsym
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.
This stage was introduced in 076e4d68 and it fulfilled well its purpose. But
the side effects were: more (sometimes slow) uploading and downloading of
packages and artifacts. Even if we have caching, this is far from ideal.
Now, the so-called "packaging" jobs were moved inside in the "build" jobs.
The advantages are: just one pacman install (ideally cached from deps job);
direct packaging without waiting for upload/download; and less confusion,
since "packaging" naming was implying that the .zips are somewhat official,
which isn't totally true, and sometimes overlaps the dist/deploy concept.
---
Also, the flatpak job now uses config.h instead of triggering a GIMP build.
In other words, I'm reverting part of my work in some old commits.
This isn't directly related with #10922 and does NOT affect 32-bit support.
After talk with @Jehan, author of 'crossroad' and main dev of crossbuilds,
we decided that the x86 crossroad builds can be dropped by these reasons:
1) 32-bit crossbuilds weren't being built. They are used since c8ec0ae7 but
after the native 32-bit builds they ended in a state that they are the only
pipeline that isn't automatically triggered in any way, a complete limbo.
2) 32-bit crossbuilds weren't being autonomous. They are not working fine
with wine32 so the win-x64-cross artifact is a 'need' and now debian-x64,
so we were spending way more time fixing than using the 32-bit cross jobs
(sometimes the 32-bit cross jobs are just broken and we even noticed).
We have other jobs not autonomous but they don't have additional bugs
like not being able to build with .mng and .wmf (32-bit cross only bugs).
---
The x64 crossbuilds will continue to be supported. They are very useful to
develop on Linux, and test MRs on Windows. I'm an assiduous user of them :)
This commit uses definitions and references to reduce repetition of CI code.
Some people (like the GitLab devs?) prefer (almost imposes) this to be done in
multiple .yml's using 'worfklow:' but this makes the CI way more complicated
and very slow to read. So, let's just keep simple in one human readable file.
---
Other changes are:
- The custom native arch pipelines now they always generate a .zip package.
This helps to ensure that everything is in place and facilitate testing;
- The pacman update (-Syyuu) was removed since it is auto done by runners;
- The ccache config was moved to .yml. This does NOT affect local builds
since meson saves ccache by default for user in '%LocalAppData%/ccache'.
These commits introduced sensible drawbacks in our CI file organization.
Some of them I already commented in the MR but was "ignored" back then
probably due to the complexity of the MR. So, the let's revert:
- Unecessary repetition of libomp installation (4 times, now 1)
- Unecessary repetition of submodule initialization (6 times, now 4)
- Creation of new variables in the hope of more clarity. But,
they aren't consistent with the gimp-web-devel instructions
nor with other systems variables. This is terrible to undestand.
Please, let's not reinvent the wheel since this is a bad example to
packagers, since they tends to isolation and overly-engineering.
Also, made some little adjustments that I should have done in previous MR.
---
This MR was splitted. Even more simplification will be done in the future.
- With last commit, the Windows installer pipeline doesn't depend on
"gimp-debian-x64" job anymore since a native Windows build is now able to run
GIMP (or gimp-console) as a build-time tool as well. It makes the Windows
installer pipeline (and full custom native builds) self-sufficient.
- On the other hand, "gimp-win-x64-cross" and "gimp-win-x86-cross" now require
"gimp-debian-x64" since cross-compiling GIMP now requires a native GIMP in
order to generate some image data (such as the splash image, and probably soon
logo or icons, etc.). See gimp-data@5a03c71.
- Getting rid of "image-win-x64-cross" and "image-win-x86-cross" in favor of
"image-debian-x64" for all Debian as well as the cross-compilation jobs. They
are all based on the same Debian image (it was debian:bookworm for native
Linux jobs and debian:testing for cross-builds; now it will be debian:bookwork
for all) and it's just a few more packages (cross-compilation C and C++
toolchains) for the cross-builds. Moreover now the cross-builds also need the
native GIMP binary around, therefore native dependencies are needed as well.
It makes sense to factorize all 3 images into 1.
- Make sure we don't build bindings when cross-compiling since these won't work
in this case.
- Splash images will now be stored from gimp-data.
- The installer BMP image scripts also move in the same time.
- We don't need devel and non-devel variants of the BMP images in InnoSetup
scripts since the images are generated from the actual splash.
Meson subprojects just have too many problems and limitations and I can foresee
the maintenance headache and the future incoming false-positive bug reports if
we start using meson subprojects.
Comparing to the simplicity of git submodule which also has much better
notifications to help people understand when the submodule is not in sync and
how to remedy to it.
See commit gimp-data@c364adb explaining the main reasons in detail.
In our efforts to use Clang, now the nightly (in fact weekly) flatpak
is built with Clang too, not only GIMP but also the dependencies.
* However, not aalib. We welcome fixes regarding this cursed lib.
Additionally, updated some build options from some deps.
This commit unites two scripts (.sh + .bat) in one .ps1. PS was choosed, since:
1) We don't need MSYS2 to distribute with Inno at first. Now, who wants to
just distribute GIMP can do it easier natively without a separate environ.
2) PS is actually pretty solid and have a good number of cmdlets, unlike the
ancient CMD, which barely supported more than 9 parameters in .bat files.
Consequently, some redundant variable checks have been removed from the .ISS.
Also, changes the name of the job and script for better consistency with the
upcoming MS Store job.
The 'Docker' draft of GIMP was introduced in 09/04/2017 and then died ONE day
after, mostly because of "bad" timing (few years later we moved to GitLab CI).
Similar (in fact, even worse) than 'jhbuild' folder, update it to keep the
current development status is so hard that it is equal to do it from scratch.
So it is reasonable to delete it anyway.
These files are not deleted when the Unstable (GIMP 2.99) or Stable (GIMP 3)
version are installed because the root is different. So, they can be removed.
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
Since !1171 we can use the CI scripts locally, but the initial implementation,
after some commits, revealed to be troublesome. So, now reworked to be simple.
As noted by Jehan, the way of defining the (many) GIMP versions can change.
So, let's take the GIMP version directly from the generated config.h file.
Also, changes the declaration of some variables to conform with "best pratices".
Bruno Lopes