Replaced by full_path:
https://mesonbuild.com/Reference-manual_returned_external_program.html#external_programpath
ExternalProgram.full_path was added in meson 0.55 but we support meson
>= 0.51. Because of that, use path or full_path conditionally depending
on the meson version.
This gets rid of the following deprecation warning:
NOTICE: Future-deprecated features used:
* 0.48.0: {'module python3'}
* 0.55.0: {'ExternalProgram.path'}
Instead, meson.current_source_root or meson.project_source_root should
be used:
https://mesonbuild.com/Reference-manual_builtin_meson.html#mesonsource_root
Also, the documentation referenced above suggest to use `files()` as a
better alternative to refer to files, so do that at the same time.
This gets rid of the deprecation warning:
NOTICE: Future-deprecated features used:
* 0.56.0: {'meson.source_root'}
Replaced by 'python' module:
https://mesonbuild.com/Python-3-module.html.
This get rids of the following deprecation warning:
NOTICE: Future-deprecated features used:
* 0.48.0: {'module python3'}
We were already using some features from 0.49:
WARNING: Project specifies a minimum meson_version '>= 0.47.2' but uses features which were added in newer versions:
* 0.48.0: {'meson.add_dist_script'}
* 0.49.0: {'Calling "add_dist_script" with multiple arguments'}
Debian 10 uses meson 0.49.2, but it will get out of support in 2 months
so we can start considering it as a too old version. Next oldest meson
version used by the distros that we follow is Ubuntu 20.04 with meson
0.53.2.
Raise to 0.51 as it is supported by all the distros that we test (except
Debian 10) and it contains all the features that we need for the next
commits.
Configuring the build directory with meson often fails if you don't have
the right Qt dependencies. As they are used only to build some examples,
it is better to autodetect them and, if present, then build the
examples but skip them otherwise.
Still accept forcing qt=true or qt=false as before.
Note that there is a option type called "feature" whose purpose is to
support exactly this: features with enable/disable/auto possible values:
https://mesonbuild.com/Build-options.html#features. However, they don't
accept true/false values so scripts using qt=true/false would start
failing. Since meson 0.60 the "deprecated" argument can be used for
options (https://mesonbuild.com/Build-options.html#deprecated-options),
but that's a too new version of meson.
Also, this fixes some Gitlab-CI failures that happen when generating the
tarball with make distcheck or meson dist. This is because it tries to
check that the tarball content can be configured and built, but it uses
the default configurations so it was using qt=yes. Now it will use
qt=auto, avoiding the failure.
Fixes: 61f0531509 ('gitlab-ci: test re-buildability of distribution tarballs')
Fixes the following deprecation warning:
meson.build:585: DEPRECATION: configuration_data.set10
with number. the `set10` method should only be used with booleans
"check" argument will change its default value to "true" in the future
versions. Hence, set it explicitly to "false", to preserve current
semantics.
Fixes the following warning:
WARNING: You should add the boolean check kwarg to the run_command call.
It currently defaults to false,
but it will default to true in future releases of meson.
See also: https://github.com/mesonbuild/meson/issues/9300
Use warning_level instead of defining -Wall and -Wextra explicitly.
Fixes the following warning:
meson.build:235: WARNING: Consider using the built-in warning_level
option instead of using "-Wall".
Previously, the tarball generated by `meson dist` did not contain the
autogenerated documentation due to the way meson works (packaging the
latest revision control commit). This introduces a dist script which
builds & copies the generated documentation into the distribution
tarball.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1811
Previously, the ppp version was only detected (and used) at one place,
in "nm-pppd-compat.c", after including the ppp headers. That was nice
and easy.
However, with that way, we could only detect it after including ppp
headers, and given the ugliness of ppp headers, we only want to include
them in "nm-pppd-compat.c" (and nowhere else).
In particular, 'nm-pppd-compat.c" uses symbols from the ppp daemon, it
thus can only be linked into a ppp plugin, not in NetworkManager core
itself. But at some places we will need to know the ppp version, outside
of the ppp plugin and "nm-pppd-compat.c".
Additionally, detect it at configure time and place it in "config.h".
There is a static assert that we are in agreement with the two ways of
detection.
