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.
lillolollo