Per the (quite off-topic) discussion in #12772, the fact it's quite
broken on Windows, apparently not too maintained anymore and its syntax
clashes with gi-docgen syntax…
It is not in fact a fix for #12640, only an improvement to our build
script, wrapping our calls to GIMP executables and outputting a
backtrace on a crash. This way, when people report issues during one of
the relevant calls, we may be able to diagnose.
It won't be useful for other types of failures (when the process doesn't
crash, but e.g. the script is wrong or other non-fatal bugs in GIMP).
Partially reverts change described in paragraph 2 of 9ab48164
Despite GIMP being built targeting to be relocatable, our
bundling script is very SLOW and pretty hard to make it
portable since it makes many ASSUMPTIONS (e.g. that all
deps are pre-compiled etc) which not always holds up.
These limitations could be fixed but would take time.
This was disrupting MSYS2 and crossroads builds, so
let's revert it being called by default for now.
This issue has eluded us for a long time and it was recently fixed in
Pango (MR pango!745). We can't bump the minimum requirement because of
our bookworm baseline for GIMP 3.0.0, but we can at least warn when
building for macOS.
We still want the normal GIMP_RELEASE C macro to be set because the
whole development frame should have code behaving like release code, yet
only for the AppStream metadata testing, we want to allow a "TODO"
release date while in +git code.
This was a bug in the meson port which was not taking into account the
stable or release state of a build (unlike how it was in the old
autotools). The rules are:
* All unstable builds (release or not) have the console.
* Non-release builds in stable series have the console.
* Only release of stable series don't have the console.
* The RC of a stable release should behave as a stable release.
This finally makes our crossbuild scripts work like in all other platforms:
with GIMP_PREFIX separated from the system/MSYS2 prefix. Thanks, @Jehan.
For some reason this makes meson don't find only 'bzip2' headers provided by
the cross compiler so, in crossbuilds, let's use the ones provided by MSYS2.
Intermediate RC versions used to be suffixed "-git" but gi-docgen
doesn't like this (or to be more accurate the packaging.version module
used by gi-docgen considers this an invalid version).
But it allows with a '+' (it calls it the local version segment). So
let's go with this new formatting.
Pelican did not like a quoted date and produced an error. Not sure what
changed, because pretty sure this output used to work fine, but…
whatever, let's fix it.
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.
If execinfo.h was not found, do not try to compile gimpbacktrace-linux.c
because the backtrace() API is not optional there.
Also I'm further improving the meson summary, regarding "Dashboard
Backtraces". Rather than just yes/no to say if the traces are detailed,
let's go for finer-grained state, saying if the traces are completely
deactivated ("no", e.g. when execinfo.h is not found), or "rough" (when
libunwind and libbacktrace are not found) or "partially detailed" (one
of these is not found) and finally "detailed".
Also add info on missing dependency between parentheses to help
packagers find the proper dependencies to get to the "detailed" state.
This was mixing 2 features: the debug on crash and performance logs in
the Dashboard dockable.
1. DrMingw is for debug on crash on Windows and has already a report in
the meson summary. So I remove it from the test.
2. Linux specifically with libbacktrace and/or libunwind and Windows but
only x86 (32/64) only are supported. Test updated.
3. Summary field updated to "Detailed backtraces (Dashboard)" for more
clarity.
The lua.interp file is there. Lua plug-ins are not needed at build time,
except that when I had a non-supported interpreter as my system's `lua`
binary (see #11876), so calling in-build GIMP would startup the lua goat
exercise, get the error reported in #11876, and (this part is the real
problem), it would somehow freeze the in-build-gimp.sh script. I'm not
sure how exactly, the gimp-console would in fact end correctly (and
generate the image it is supposed to), but leaving around a lua process.
And somehow the script would not continue, it would not call any further
command line, nor would it even crash. So I just had a stuck build.
In my OS, lua 5.1 binary is called 'lua-5.1' (with hyphen), so I add
this in the list. Also I improve the summary output to display the found
lua binary, which is useful for debugging and for packagers to know
which lua binary is being used (especially now that we install a
lua.interp, even on Linux).
Though the output of `lua -v` is on stdout and was also on stdout by
default, even back with version 5.1, it turns out that lua's print
function was considered configurable back then. And this is very likely
why we now have this report of someone whose lua is on stderr.
So let's still look on stdout, then fallback to stderr it the format
doesn't match.
Main dev branch of GIMP always depends on the HEAD of babl and GEGL
anyway, but that's just so that we maybe have less people reporting GIMP
not building because they use a stable release version of GEGL (though
it won't take care of the case of people using an older 0.4.49 build
which also won't have the newer API).
As reported by pippin, when gimp-data submodule is not initialized,
meson configuration fails with:
> meson.build:1830:0: ERROR: Nonexistent build file 'gimp-data/meson.build'
This does not give a lot of info, and while the solution can also be
found in INSTALL.in (INSTALL in tarballs) and on developer website, it's
nicer if the build itself could give a clearer information.
Now it will say instead:
> ERROR: Problem encountered: gimp-data submodule not present. Run: git submodule update --init
… found at build-time.
It was working on a machine with default paths and system-installed
packages (e.g. a typical Linux distributions) but needs to be manually
set up e.g. on Windows.
I had the case on my machine where `lua` was version 5.4.4 and the
lua-lgi test succeeded fine, but then the demo plug-in would fail to run
with the error message from #11876.
Let's parse the output of `lua -v` to detect the version ourselves and
therefore be able to output proper error messages for packagers not to
assume that the Lua interpreter they are using will work fine.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/11876
For 3.0 we will support only Lua 5.1, since we need to figure out how
much of the Lua 5.1 API is compatible with newer versions (Lua minor
versions aren't like Python minor versions, there is API breakage so
plug-ins would be completely unreliable, this commit prevent this).
Also, change some files to not force luajit since it isn't mandatory.
Unlike the other bindings (Lua, JS, Vala) where we only have a demo
plug-in, we actually have a bunch of interesting and useful Python
plug-ins.
Furthermore, we are running several Python scripts through GIMP during
our build (to generate a few images), so pygobject becomes a build
dependency anyway, even if it may not be a run dependency with
-Dpython=disabled.
This all becomes a bit confusing and in fact handling this case (of not
installing Python plug-ins) seems like an annoyance while we lose good
core plug-ins. So let's just make Python plug-ins mandatory. It's not
like Python is very controversial these days, and AFAWK, it is available
on every platform out there.
Commit 81a68ae758 added usage of hb_blob_create_from_file_or_fail().
Since Debian bookworm has harfbuzz 6.0.0, this is not a big deal, but
the minimum requirement should still be bumped in our build scripts.
Without this, build-time GIMP cannot find the etc/ files unless GIMP is
installed. This becomes even more annoying now as I want to run tests
(for GimpUnit) depending on etc/unitrc contents.
This will also ensure that tests run properly in environments where the
etc/unitrc may have been modified.
lua-lgi now works with Lua 5.3 on Windows:
https://github.com/msys2/MINGW-packages/issues/21171
According to my tests, after installing lua53-lgi MSYS2 package,
lua5.3.exe tries to run the goat exercise (fails since the goat
uses different lua API). Anyway, lua5.1 isn't required per se.
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.
