Similar to the --enable-g-ir-doc option I just added on autotools. Also
separate this option from gtk-doc as it is unrelated (not everything
under devel-docs is related to gtk-doc!).
Based on the proposed process proposed by Akkana Peck. Thanks Akk!
For now, it's only in the meson build, which is fairly terrible to use
as soon as we do custom build rules. Here are the list of issues:
- meson does not allow building in subdir (issue 2320 on meson tracker).
Sure I could make several subdirs with meson in them. But here the
future goal would be to be able to generate docs for other
introspected languages, and maybe also other output formats (epub or
whatnot). For this, since these are basically the same commands which
are used, the best practice would be to have loops generating one
target per language/format combination, reusing code rather than ugly
copy-pasting in subdirectories' meson files).
- custom_target() requires the output parameter to be the complete list
of generated files. But we have more than a thousand of them. It's not
practical. Maybe we could try to find a way to generate the list from
the contents of the .def files which are already exhaustive and exact.
- Install also requires the output list to be complete.
- I temporarily have these docs not generated by default (because the
gtk-doc option is already crazy slow as it is, making meson near
unusable for development if it's enabled). If you want to generate the
docs, the commands are as following (yeah I don't understand what the
target names are for since meson does not actually create targets with
these names, so we have to use fake output names instead):
> ninja devel-docs/g-ir-docs/Gimp-python-html
> ninja devel-docs/g-ir-docs/GimpUi-python-html
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.
This fixes the following warning during GIR generation:
> cc1: warning: -Wformat-security ignored without -Wformat [-Wformat-security]
And anyway it is useless to set -Wformat-security if -Wformat is not set
as well, so if we want one, let's have both.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
Noticed by Massimo.
gimp_type_set_translation_domain() calls were missing.
Also make so that the output is exactly similar (even whitespaces) as
the autotools one, making it easier to diff, hence maintain.
It should be clear that the autotools build is still the officially
mandated one for all finale builds (i.e. packaging). Our meson builds
still have bugs (some we know of and are trying to fix, others that we
will probably discover soon) so packagers should be well aware that they
should not use meson (though we highly encourage it for developers so
that bugs can be found).
Adding this warning as someone was asking on a bug report whether
autotools were still being supported (while it's the opposite: meson is
still not officially stable and autotools is still our main build
system).
We want to be able to install icons only in a quick command when
testing/developing.
Also I realize that Legacy icons are not even installed with meson
build, which is bad! Even though legacy, we want to keep them (at least
for the time being), just as we do with autotools.
It must not be a boolean but a `feature` option, with `auto` by default.
`auto` value mean enabled for macOS and Win32, and disabled for other
cases. This default logics disappeared in the meson build.
Also the mypaint-brushes package is a mandatory dependency, which must
always be checked. Absence is fatale.
Finally properly set the MYPAINT_BRUSHES_DIR macro depending on the
proper relocatable case.
For pango and libbacktrace, we only need a compilation/link test. No run
is needed.
As for the exchndl (Windows only), this is an optional feature, hence
should not be a fatale check.
3 cases are possible:
- in native build, the test must succeed and is a fatale error.
- in cross-compilation, if no `exe_wrapper` binaries were set in the
toolchain file, we just bypass the check, yet still output a warning
so that packagers won't forget to add the dependency.
- in cross-compilation with an `exe_wrapper` (for instance `wine` for a
win32 target), we run the check. Even if it fails, we don't make it a
fatale error then simply output a warning as cross-platform execution
are not always reliable anyway.
Jehan