Note that profile support also affect AVIF but since AVIF support came
anyway after libheif 1.4.0 (which is when color profile support
appeared), there is no way to differentiate there.
Thanks to Darix for noting the miss.
See: https://gitlab.gnome.org/GNOME/gimp/-/issues/5787#note_938976
libheif pc files provides variables which are actually older than our
minimum libheif requirement (so it's usable generically) to determinate
if libheif was built for HEIC/AVIF support. This is quite useful as we
had our share of annoyance with missing support of some encoder/decoder
even when libheif requirement was alright.
Also adding image/avif (if relevant decoder is present) to list of
supported mimetypes.
For Python, Lua and Javascript, make the option boolean (with 'yes'
being the default). No need of a warning when not installing the
plug-ins as this would have been disabled explicitly anyway. When
installing the plug-ins, only make interpreter checks as precautionnary
verifications which don't actually change anything (except outputting
some warnings if interpreters are not found). Basically for these 3
bindings, the interpreters are only runtime dependencies anyway. So it
doesn't matter if they are not available at build time. In particular,
we get rid of the 'force' option.
Vala rules do not change as the vala compiler is indeed needed at build
time and current checks work correctly. I just add a "Vala plug-ins"
line in the summary message of the meson configuration, as it was
missing.
This is an extension containing a few demo plug-ins. This is good to
demonstrate the extension format. It will also allow to disable these
plug-ins (if at some point, one doesn't want to show these demo
plug-ins anymore).
And finally it deals with the fact that our plug-in code is stupid, as
it just tries to find the first executable with the same name (minus
extension) as the plug-in folder. This doesn't go well on Windows, where
the permission system is non-existent. So our code just ends up trying
to run the first file with a similar name in a plug-in folder. As the C
goat-exercise contains both an exe and the C source (and the system
probably returns files in alphabetic order), GIMP under Windows tries to
run the C source instead of the executable (this obviously doesn't go
well).
We could try to do more complex logics, like not aborting if the first
file run fails and try the next one in the plug-in folder. Or maybe just
rename the C file to another name. But any of these is just in the end
the proof that our plug-in discovery right now is just bogus. The
extension system is explicit, not based on randomly trying out files.
Plug-ins entry points are explicitly listed in the metadata manifest.
Current dev code of GEGL is necessary as it fixes its VAPI dependency
(see gegl!83). Without this, with a recent meson version, Vala plug-in
build fails.
See !334 for some more background.
Poppler has not been an optional dependency for years now, because it
was decided that PDF import was considered a granted feature by most
people. So removing the option in the meson build. This option should
not have existed in the first place.
This commit makes sure we can properly run the tests in a headless
environment, i.e. they don't mess with the user's X display or their
session bus. The latter is also needed for parallel tests as they fail
to simultaneously own the same name on the session bus.
Replaced the "xvfb-run" meson option with the "headless" option, which
is more intuitive (and also more correct, since we now also require
`dbus-run-session` to run the tests, not only `xvfb-run`).
Finally, note that we need a version of `xvfb-run` that supports the
`-d` (`--auto-display`) option. The problem with `--auto-servernum`
which is also regularly used, is that it doesn't shut down cleanly,
returning a non-zero exit code, wich makes the test fail.
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/5078
When we build GIMP with `-Dauto_features=enabled` to ensure we have
fully-featured GIMP and to have it warn us when we are missing some
optional dependency, Meson also enables relocatable bundle.
This is unexpected since being relocatable is a binary property rather
than a feature. This patch switches it option to a combo type to make
it ignore auto_features option.
Anyway meson is based itself on python3 so it has to be present. Just
using `python` may be any python (2 included).
Of course, it would be ok most of the time, but with the Fedora 31 CI,
apparently just `python` is not found.
8b5060349a fixes the issue of version headers
not being available when building out of VCS tarball (without .git directory)
but we were getting `unknown (unsupported)` version still. Turns out the version
silently fell back to `unknown` when git was not available.
Let's warn the user when this is the case.
Reported by Jan Tojnar as a comment to commit e4c7fc23 that builds from
simple archives of the repo contents (without the .git tree) are
currently broken. Well this is normal, as we only support builds from
release versions or from the repository where we can extract a git hash.
Any other kind of nightly build can be from any commit out of thousands
and is maintenance hell.
To be nice though, let's unbreak such builds, but they will be clearly
marked as unsupported (warning at configure time + the extract commit
hash will now be labelled "unknown (unsupported)", which will be a
visible string in About and on unstable version canvases).
Basically do so at your own risk.
Also generate INSTALL all the time (not sure why it was only generated
in non-git case).
The way we use CC_VERSION macro is to give information on the compiler
used during build. This information may be useful when debugging in
particular. So we can't just use `cc.version()` which only gives a
version number, not even the name of the compiler.
Restore the logics of autotools where we were using the result of `cc
-v` (for gcc and clang) and testing various CLI options for other
compilers.
Also this test may fail on meson because of various bugs, which I now
reported and provided patch for (hopefully soon merged). In particular,
when using ccache, the command run fails (also I have to change newlines
in C-style `\n` myself as meson's set_quoted() creates broken header
when newlines are present).
If it fails, let's at least store the compiler name + its version, still
more useful than version only.
Same as what I did for the configure script. Note that I break commits
in 2 to make the autotools commits easily backportable to gimp-2-10,
i.e. without any meson files.
It was typoed as HAVE_LIBHEIF_4_1_0 so profile support was never
working for HEIF format.
Also add warnings and better output, similar to configure script one.
Jehan