I don't get how this could be failing because config.h is included on main.c,
but it it: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/2664#note_2699194
So, I noticed that that the macro prefix ISOCODES_ is "new", being introduced
with aba7316e. The pre-existing is ISOE_CODES. Let's unify trying to fix build.
Issue #15763 is again mostly false positive crashes of the unit tests
because the code is only partly GIMP code, arranged differently as what
a full GIMP process would actually do.
The new tests just runs on the real GIMP code. Now the difference is
that we don't test the UI by doing this, but this can be debated whether
the previous tests were actually running on the UI themselves (they were
mostly running some core code directly and sometimes activating some
actions or raising dialogs (gimp_test_utils_create_image_from_dialog()),
but again not by actually clicking or hitting keys as a human would do.
It's not proper UI testing (cf. #9339 of #13376 for further discussions
on this topic).
So in the meantime, let's go with this intermediate step. At least now,
such tests would run actual GIMP code and would catch issues which could
really happen in a GIMP process.
Let's force having the bash-completion dependency when we want to enable
the feature. Then clearly shows the feature state in the final setup
summary.
Otherwise the risk is that GIMP may not use the correct path on a given
system and a packager who wants this script to be installed may miss
that it is installed in the wrong directory.
(cherry picked from commit 88b4f29ce7)
This adds macOS support on our CI aiming to MacPorts + macOS SDK 11. But since
the GNOME runner have short timeout and no cache we fallback to Homebrew for
now (which inelegantly links to X11 and follows runner's very high macOS 14).
There is also still work to do: .dmg creation, multi-arch and notarization.
Even so, this is a huge improvement, because macOS devs can now easily test MRs
inhouse and non-macOS devs can contribute for macOS inhouse too. With the word
"inhouse" I mean from this official gimp repo, without needing gimp-macos-build.
For making that possible, I ported various concepts from gimp-macos-build:
- .typelib regeneration for relocatability
- LC_RPATH, LC_LOAD_DYLIB and LC_ID_DYLIB patching for relocatability
- LC_BUILD_VERSION (minos) check for compatibility
- GdkPixBuf loaders.cache patching
- NEW: immodules.cache patching
- Python.framework complex handling
- Ad-hoc code signing on binaries (do not confuse with notarization)
- .dSYM generation for babl, gegl and gimp
- etc
All these concepts into few scripts, without depending on gtk-mac-bundler.
Since it was designed to work with MacPorts, we could make use of it on
gimp-macos-build, but things are so endlessly complicated there into the
9999 scripts and CircleCI is very slow, so I'm not sure if gimp-macos-build
have any future. The ideal would be official macOS 11 builds on GIMP repo.
Seems this was the last .sh script pending to ported. Since I was experiencing
problems with the .sh one (not working locally nor on HomeBrew), I just ported.
Now, it is easier to read and fix if needed.
I also fixed the build order on libgimp meson.build to ensure the patched
.typelib being always present at the time GIMP generate splash screen etc.
This applies the same logic of *DATADIR, *PLUGINDIR and *SYSCONFDIR below.
That is because, on the same stable series, minor versions do not coexist.
I confirmed that on GIMP 2.8 and 2.10 .exe and .dmg installers from gimp.org.
Yet, we don'have anything automated in that regard on the meson.build nor
even documented on https://developer.gimp.org/core/maintainer/versioning/.
We were getting a few warnings for usage of functions which we
deprecated after our current minimum required version. Setting these
macros will ensure we get correct deprecation warnings.
Thanks to René de Hesselle for figuring out that the issue happens when
Harfbuzz is not built with libgraphite2.
As far as we know, this is a macOS-only issue.
The issue has already been fixed in our macOS packages, but just to make
sure this doesn't reappear, let's add a configure test.
Note: when we'll bump to using meson >= 1.5.0, we can use option
`required: platform_osx` of cc.run().
It is possible to have libgdk compiled just with X11 support on macOS,
which breaks our GDK_ macro checks on libgimpwidgets/gimppickbutton*.c.
That is exactly what happened when I first tried to compile with MacPorts,
since they default for X11 for the sake of old iMacs pre-OSX. Let's improve.
On other platforms, that is not a problem, since the specific backend is
necessarily compiled as per the gtk3 meson.build design. On Windows, it is
always win32; on other Unixes, it will be X11 at least, and Wayland.
This reverts 63f5ea9d regarding the file naming
Since the script is an utility pretty much one-task, it suits better on tools,
similarly to what we do on babl and meson (but on these we put on root).
And, along with 8c0f92b3, it makes build/windows less scary with less files.
It is suboptimal to see the test failure, check the meson-log.txt and
stderr part says nothing. This annoyed me when implementing both
Snap and MSVC support. So, let's boost that stderr on meson-log.txt.
Even clang-cl (the wrapper for MSVC) can't work with GNU C++.
So, let's use the ISO one.
As a result, we now set math.h/cmath defines on Windows builds.
This should be unnecessary since GExiv2 did the break properly by
renaming files (making it possible to install side-by-side an older
version of GExiv2 and a newer version). But some packagers are wrongly
renaming the .pc file, tricking our build system into accepting the
newer incompatible libgexiv2.
So let's add an additional test, explicitly forbidding newer GExiv2.
We'll move on to the new version when we'll be ready. For the time
being, there is a reason why files were renamed and packagers should not
force incompatible versions to fit.
I discover GLIB_VERSION_MIN_REQUIRED and GLIB_VERSION_MAX_ALLOWED. The
former will make so that we won't have deprecation warnings anymore if
ever we use a function which has been deprecated recently (as long as it
was not deprecated at the minimum required version). The latter will
make so that we get deprecation warnings for any function added after
the minimum required version.
Note that ideally both should be at the same version, but since we have
a bunch of GLIB_CHECK_VERSION() protected conditional code, we would get
compilation warnings even on correctly protected code. So just keep the
small discrepancy until we can finally bump our minimum requirement.
Also add the equivalent macros for GTK/GDK.
