From now, Windows contributors can use the default shell provided by the OS
(which is PS since Windows build 10.0.14971.0), like Linux and macOS users do.
We still use MSYS2 but not the POSIX shell. This change adds these features:
'1_build-deps-msys2.sh' is now '1_build-deps-msys2.ps1'
- Faster clonning by using 'git-scm' (the MSYS2 one had performance problems)
- Easier to use non-MSYS2 binaries, not only 'git-scm' but also official meson,
deps from vckpg etc. This is a needed step towards the future use of MSVC.
'2_build-gimp-msys2.sh' is now '2_build-gimp-msys2.ps1'
- By default, vanilla builds (normally triggered on PS) will create a bundle,
dropping the need of 'gimp.cmd' (that adressed .typelib and .interp limits),
which is inline with other (Cmake-based) projects like Darktable and Inkscape.
This change is important because even Windows devs more experienced than me
get confused with the relocatibility stuff, which is the default on Windows.
'2_bundle-gimp-uni_base.sh'
- As a result of the change above, bundling code was changed to be a bit faster.
It still is, however, painfully slow, since meson doesn't have a 'install()'
function like Cmake to prepend targets in Ninja's 'install_manifest.txt'.
Since we are not using a POSIX shell (nor 'mintty') anymore:
- GIMP can be built from every path easily with R. Click "Open Terminal", with
IDE integrations etc, without needing to manual tweak MSYS2 .ini files etc.
We could tweak MSYS2 to get the features above but not top-tier integration.
- Developers can be more aware of Windows native vars, paths etc, and avoid bugs
Some build files were improved to support the 'Windows way of doing things'.
- No need to close and reopen terminal anymore after running 'pacman -Suy'!
---
REGRESSION: Vala plug-ins are temporarely gone due to 'vapigen' bugs, a small
regression since this is a gnomeish language but I will investigate how to fix.
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.
Local certification with WACK is optional and useful to anticipate if
the MSIX will be refused by Partner Center's online certification.
(Just to note: On Windows SDK, certification is not equal to signing.
It's more a checklist process to see if the package is suitable to run.)
To avoid needing the full script to be run with admin rights (which
would be scary) this feature only works with a bunch of requirements:
1. sudo for Windows (so Windows 11 24H2)...
2. enabled in normal (aka inline) mode...
3. in a Windows account in admin group
The 2nd and, specially, the last one are harsh but this is sudo's design:
https://github.com/microsoft/sudo/issues/108https://github.com/microsoft/sudo/discussions/68
This file was added in commit 21ffb58903 to replace the list in
4_dist-gimp-inno.ps1. The older list used to be verified for missing
langs in the test-installer-langs.sh unit test, but the test was removed
and never replaced. This is why now when a new language is added and it
is missing in iso_639_custom.xml, it goes unnoticed until failing in
dist-installer-weekly job.
This fixes building with the option -Dwindows-installer=true. We should
**never** hardcode the build directory like what was done in this
script.
Also bumping gimp-data where some scripts had similar issues which were
only visible with -Dwindows-installer=true.
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).
luajit download server to tarballs stopped to work, which is expected,
since it was advised by the team in https://luajit.org/download.html:
"Please do not use obsolete versions from older tarballs or zip files.
Please remove any outdated links to these downloads — these links will
cease to work soon."
We also will not use the official git server since it does not support
all git clone features, which makes flatpak-builder cloning stage fail.
---
Regarding lua-lgi, we will not use the latest commit since seems that
our goat exercises or gobject-introspection or lua-lgi iteself is broken
since lua-lgi commit: 3f47eb57ef5a84be878ce33c15b7ff037059b08d
First, make the script versioning system able to detect release candidates.
Otherwise, we willn't be able to use the "GIMP.GIMPPreview" identity (that
was previously tied to GIMP_UNSTABLE var, which is not set to 1 on RCs).
---
This also fixes the pseudo-revision trick when we have a zeroed micro version,
which is the case of the release candidates and the first stable version.
The versioning now have a different aproach from 8c99efd7.
Some parts of the README got obscured or dated with time. Let's improve them:
- Remove redundant text about keeping GIMP buildable (it's already said on
Cod. Style and Dev rights pages on gimp-web-devel, and not flatpak specific)
- Remove text about 1-hour timeout which isn't true according to my tests,
specially after the improvements of splitted jobs and updated build options
- Reorder Anitya text to before "module dropping" text, it's linear this way
("module dropping" by checking runtime is last step of module cycle of life)
- Remove very confusing "flatpak run... gimp" line which was breaking the
explanation flow about "module dropping" and it's not too useful since the
manifest (which is only a bit different) can be acessed in-source with tags
- Changed title from "Mantaining the manifest" to "Mantaining the modules"
- Added not so clear "Versioning the flatpak" to separate it from other modules
text. The title is not perfect, but at least make a needed pause on reading
Ported from: 37b173e3a9
and ac0069eb20
The reason for this change is because part of our API (babl, gegl and
gimp headers) directly links to gexiv2 then exiv2 headers so these two
should be provided, even if they aren't on babl/gegl/gimp namespaces.
This change is useful to beta. But, despite we not using extensions on
GIMP nightly to need these headers, doesn't hurt syncing this change.
Indeed, this commit clarify "why" we aren't cleaning these headers.
This adds a bit more verbosity to the installer script while omitting some.
The version params (e.g. gimp_version) are dropped since now config.h is
mandatory (this is a natural conclusion of the generation of assets).
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
Bruno