This is functionally equivalent to the logic used to locate the cross
exe_wrapper, but puts it below the "Compilers" heading rather than
"Other binaries".
Signed-off-by: Simon McVittie <smcv@debian.org>
Recent versions of the architecture-properties package provide a
cross-exe-wrapper package containing
${DEB_HOST_GNU_TYPE}-cross-exe-wrapper, which is currently a wrapper
around qemu-user but could use different emulators on each architecture
if it becomes necessary in the future.
Signed-off-by: Simon McVittie <smcv@debian.org>
In Debian testing/unstable, there are wrappers available for various
GObject-Introspection tools during cross-builds, using qemu internally.
Signed-off-by: Simon McVittie <smcv@debian.org>
Cross-tools on Debian generally follow the naming convention set by
Autotools AC_CHECK_TOOL, where the name is prefixed with the GNU
architecture tuple for the host architecture. env2mfile was already
using this for pkg-config, but there are many other tools that can
be detected in the same way.
Signed-off-by: Simon McVittie <smcv@debian.org>
`DEB_HOST_ARCH` encodes both the CPU family and the OS, so using it to
get the CPU type gives the wrong answer for non-Linux ports.
However, `DEB_HOST_GNU_CPU` gives less detailed information about the
CPU: it's `arm` for all 32-bit ARM CPUs, and doesn't distinguish between
the differing baselines of `armel` (ARMv5 softfloat) and `armhf`
(ARMv7 hardfloat).
When cross-compiling for x86_64 Linux, this changes the `cpu()` from
`amd64` to `x86_64`, which is consistent with the answer we get during
native builds on that architecture.
When cross-compiling for `ppc64el`, this changes the `cpu()` from
`ppc64el` to `ppc64`, which is a reasonable change but is still not
consistent with what we see during native builds (which is `ppc64le`):
see #13741 for that.
Resolves: https://github.com/mesonbuild/meson/issues/13742
Signed-off-by: Simon McVittie <smcv@debian.org>
All official Debian release architectures use the Linux kernel, but
unofficial ports like hurd-i386 and kfreebsd-amd64 use the Hurd and
FreeBSD kernel, respectively.
Map Linux to 'linux' and kFreeBSD ports to 'freebsd' as per the
reference tables in Meson's documentation. For now, use the Debian
system name such as 'hurd' for anything else (see #13740 for the
question of whether Hurd should identify its kernel differently).
Signed-off-by: Simon McVittie <smcv@debian.org>
As per <https://mesonbuild.com/Reference-tables.html>, and matching what
happens when running Meson for a native build on Debian GNU/Hurd.
Signed-off-by: Simon McVittie <smcv@debian.org>
This makes the frequent pattern of things like "CPU families are the
same as GNU CPUs, with a few known exceptions" less verbose.
Signed-off-by: Simon McVittie <smcv@debian.org>
Separating the part that runs dpkg-architecture from the part that
interprets its results will make it easier to unit-test the latter.
Signed-off-by: Simon McVittie <smcv@debian.org>
This will make it easier to unit-test functions that work with a
MachineInfo, by constructing the expected object in a single call.
Signed-off-by: Simon McVittie <smcv@debian.org>
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
We support this in a machine file:
```
[binaries]
pkgconfig = 'pkg-config'
pkg-config = 'pkg-config'
```
and you can use either one, because internally we look up both. If you
only set *one* of them, this plays awkwardly with setting $PKG_CONFIG,
since we don't know which one you set in the machine file and the
*other* one will be initialized from the environment instead.
In commit 22df45a319 we changed program
lookup of config-tool style dependencies to use the regular tool names
and only fall back on the strange internal names. This affected the
pkg-config class too.
The result is that instead of preferring `pkgconfig =` followed by
$PKG_CONFIG followed by `pkg-config =`, we inverted the lookup order.
This is a good idea anyway, because now it behaves consistently with
`find_program('pkg-config')`.
Unfortunately, we documented the wrong name in a bunch of places, and
also used the wrong name in various testsuite bits, which meant that if
you set $PKG_CONFIG and then ran the testsuite, it would fail.
Correct these references, because they are buggy.
One test case expected to find_program() a native copy for convenience
of testing against natively installed glib. Force it to resolve a native
copy.
Meson internally knows about many languages and tools, and *FLAGS
variables, and which languages to use them for. Instead of duplicating
this logic, import it from mesonbuild.*
This logic was originally standalone, but now that it is merged into the
Meson tree we can have a single source of truth.
This reverts commit e257a870fe.
The PR adding this command had infinitely hanging CI, and now that it is
merged to master we cannot get any CI on any PR to succeed.
Simon McVittie
Samuel Thibault
Ole André Vadla Ravnås
Dylan Baker
Luke Elliott
L. E. Segovia
Eli Schwartz
Jussi Pakkanen
Xavier Claessens