Following e93e0f49
This defaults 'Segoe UI' for Installer texts and for license's body. This
font is still used as the default in Windows 11 and even in online docs.
We are also bumping to 9 pt as outlined in the final Win32 guidelines:
https://learn.microsoft.com/en-us/windows/win32/uxguide/vis-fonts
I've done microscopic pixel checks and confirmed that this produces a Win32
compliant design, which renders kerning and spacing equal as 'Win + R' and
UWP Notepad (please note that some "legacier" Win32 apps renders different)
---
Also, change from Lucida Console to 'Consolas' (default console font since
at least Win8). Today it is Cascadia Mono but not included with Win 10.
This makes the output more complete but at the same time less
polluted regarding the bundling scripts (base, deps and sym).
---
Also, packaging scripts (inno and msix) were touched as consequence
of experiments about drop bundling, for saving space (~20MB), of:
- etc/gtk (MSYS2 don't build immodules)
- share/ghostscript (macOS .dmg don't package it)
- share/libthai (macOS .dmg don't package it)
- share/locale (???, decided to kept only gtk and iso-codes to test)
- share/man (installer don't package it, maybe because Windows can't open)
- share/poppler (macOS .dmg don't package it)
- bin/bzip2.exe (???)
- bin/gdk-pixbuf-query-loaders.exe (loaders.cache already bundled)
- bin/gspawn*.exe. (???)
- share/gir-1.0 (installer don't package it)
- share/lua (???)
- share/vala (installer don't package it)
The "???" ones seems to not be used according to my local tests. If
they are, a bug will appear so we will be able to know, comment in
the script (for maximum clarity towards the future) then revert.
In the process, make the Installer localization process less 'masochist'
(in other words: less manual). The custom '.xml' was the only way since
the iso-codes, Dammed Lies and Inno namings don't match.
This reverts commit 085d8a02b5.
For some reason, Windows doesn't allow us to use that feature
(confirmed this after using the version from the Store itself,
not the .msixbundle)
The installer is probably the most complex packaging format so one of the
biggest examples of packaging love over the years into it in our repo.
But the readability of installer scripts... leave a lot to be desired.
Now, the main script is organized following the order of installer pages
with some comments. This will make easier to future contributors work
(but this commit probably isn't perfect since it's a big change to read)
We have counter measures to avoid installing while gimp opened at 'prep time',
but until now none for the installer itself. Let's fix it with SetupMutex.
The final UX is just less worse (than today): the user needs first to select a
language, then only after this the dialog about two installer will be prompt.
Seems that Inno devs willn't fix: https://github.com/jrsoftware/issrc/pull/461
Following 0199faac
We use arm64 runners for the installer job to avoid queues, but...
llvm-objcopy is well know to lack parity and one sympthom is the
'invalid SymbolTableIndex' warning when handling x86 debug symbols.
This commit just makes the installer display a (unchecked) checkbox, like Win
pkg manager (WinGet) so it's doesn't change the actual behavior. It also don't
break string freeze since the .isl string already exists and have translations.
The benefit to some users is having one less click to launch GIMP: [checkbox] >
[close]; instead of: [close] > [start menu icon] > [gimp in 'recommendations'].
This style mimics the color scheme used by Win32 applications since Vista (and
still used in Win11). The all grey scheme ended in XP. Let's move on.
But we will keep the actual window size and without being able to resize since
these two Inno features (WizardSizePercent and WizardResizable) are broken.
(The progress bar was changed too to conform with the defaults and uninstaller)
Now, the installer files match the meson config.h naming:
'gimp_version', 'gimp_app_version' and 'gimp_api_version'.
"devel" was replaced by meson 'gimp_unstable' too.
util_version was dropped since it lost its utility.
1) Right now, MS Partner Center doesn't tell us if the .pdb bunbled as .appxsym
are fine and we only have "Unknow" dumps in the Health page from MS Par. Cen.
My theory, according to my tests with 'SymChk', 'PDBCopy' and 'llvm-pdbutil',
is that this is happening because .pdb from clang or gcc are not "perfect", but
I really have no proof to afirm this, since Partner Center tell us nothing
about them, and we don't even know if the .appxsym were uploaded to begin with.
---
2) The compiler can't generate DWARF (.debug*) symbols when generating .pdb,
which breaks debugging in DrMingw and even lldb according to my tests.
(This is not a fault of the .pdb format but a circumstance: our debuggers
only support DWARF, which is the format already used by MSYS2 packages)
---
So, the .pdb will return probably only in the potential vcpkg transition.
Previous changes broken local building courtesy and probably DirectInput too.
Noticed that the universal variables can not work in some contexts, fixed.
Also, done some little cleanups.
This make them easier to understand and to run local, as we do with native ones
(They can't be run local yet, further changes will try to acomplish this a bit)
Port all plug-ins to retrieve the layers
directly from the image rather than
having them passed in. This resolves some
issues with introspection and sets the
foundation for future API work.
The wrapper, like in native artifact, exists just for avoid searching the exe.
But, if the user wanted, wasn't possible to execute gimp-*.exe directly since
the wrapper was needed to generate loaders.cache. Now, loaders.cache are built.
This improves the gimp.cmd wrapper wording a bit to not need the README
anymore. Our dev site was improved some time ago to clarify this:
the Windows builds aren't not incomplete if run correctly (under MSYS2)
Also, add cleanup commands to make the .typelib wizardy less invasive.
Without this, Partner Center refuses the .MSIX by not matching the
entry Identity and DisplayName (which isn't the same as the stable).
Also, rework the naming of the .msix's to be more Microsoft-ish
This commit is mostly a little cleanup:
- Reduce redundancy in Local compatibility layer regarding build commands,
which partily reverts !1171 regarding buggy "ninja && ninja install"
- Reduce redundancy of some variables (MSYS_PREFIX and GIMP_DISTRIB)
- Remove manual QOI install since MSYS2 granted a exception in the win32 drop
This commit also reverts 7cca69cd, a fix from the autotools era that isn't
actually needed according to my tests in CI.
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.
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.
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.
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".
This list is referenced in the gimp-web-devel site, and my initial
implementation, in terms of ease to use, was a throwback.
Also, make the CI code more simple without changing the list file.
The rest of the time, we want to use HEAD of their main branches.
The last ctx update seem to have broken the CI build on Windows. While we'll
have to fix this, let's do this after we release GIMP.
Anyway we obviously don't want to use unstable code for actual point releases,
so it's a good thing that this made me think of adding such rules.
Aaaargh! I think this was the main issue which would explain why the problem was
mostly happening on the packaging job. In this job, we were still consistently
calling `pacman --noconfirm -Suy` (i.e.g "Synchronizing package databases")
which we had stopped to do for the CI builds as that was highly increasing
chances of locking pacman's process.
Fixing a case where the script continued after a failed `ninja`. After further
testing on how `set -e` works, it looks like a toplevel `false && true` command
will fail the script (which is what we want), but it won't when inside an `if`
block!
Breaking it down into 2 separate calls fail the script correctly though. So
let's do this.
MSYS2 pacman gets randomly stuck on Windows/Aarch64. The actual issue is still
being investigated by upstream projects, though anyway it's bad for us right
now, to the point that there are discussions to remove Aarch64 support from the
Windows installer (whereas it just got added recently!) in #10729.
This is an attempt to a workaround. Instead of getting stuck forever and waiting
until the whole job times out (per Gitlab CI settings), I time-out (after 3
minutes) the pacman command within our script and try again, up to 2 more times.
Hopefully one of the calls would succeed.
I also send a SIGKILL through the timeout (though I have no idea how signals
translate to Windows processes) and run again taskkill after this, which may
seem overkill. Interestingly I get output for both, which seems to indicate that
the kill succeeds in both cases (because of several processes?).
Anyway clearly it's a bit of random code not completely understood, but the
inability to test this all locally clearly doesn't help so it's good enough for
the time being.
See: https://github.com/msys2/MSYS2-packages/issues/4340
While this is the job of `set -e`, putting parts of the script in shell
functions hid error returns in the build-deps-msys2 script.
Cf. #10729.
For the build-gimp-crossroad script, let's just add `set -e`.
Cf. #10725.
Bruno