Previously, the documentation said that the CPU name might be amd64,
but in fact x86_64 (AMD64) machines are detected as x86_64 in both
cpu() and cpu_family() during native builds. Reference:
https://buildd.debian.org/status/fetch.php?pkg=libglvnd&arch=amd64&ver=1.7.0-1%2Bb1&stamp=1714222481&raw=0
Instead, mention the only common case for more-specific CPU names
other than 32-bit x86, namely 32-bit ARM. On Debian's autobuilders
(which are running 32-bit user-space on a 64-bit-capable CPU),
native builds genuinely do present as `armv8l`:
https://buildd.debian.org/status/fetch.php?pkg=libglvnd&arch=armhf&ver=1.7.0-1%2Bb1&stamp=1714223924&raw=0
On other machines, they might be some older CPU functionality level.
At the time of writing, cpu() *can* return amd64 when using
`meson env2mfile` on Debian systems, but I think that's a bug in
env2mfile (#13742).
Signed-off-by: Simon McVittie <smcv@debian.org>
This method allows meson.build to introspect on the changed options.
It works by merely exposing the same set of data that is logged by
MesonApp._generate.
Fixes#10898
Hook this up to installed dependency manifests. This is often needed
above and beyond just an SPDX string -- e.g. many licenses have custom
copyright lines.
This is based on searching for `@FeatureNew*` decorators.
There is also one correction to a version in a decorators;
`build_by_default` was added in #1303, which is 0.38.0, not 0.40.0.
They claimed that all of these functions accepted any posargs or varargs
that install scripts supported. This was inconsistent with both the
types that meson currently allowed, and the types that we documented in
refman 1.0 *should* be allowed.
Take the opportuninty to be clear as refman 1.0 never was, about the
difference between types supported in the first posarg, and the ypes
supported in succeeding varargs.
Dylan Baker
Simon McVittie
Jouke Witteveen
Sebastian Crane
HiPhish
L. E. Segovia
Charles Brunet
Eli Schwartz
Elliott Sales de Andrade
Daniel Mensinger
Xavier Claessens
Crend King