WARNING: Running the setup command as `meson [options]` instead of
`meson setup [options]` is ambiguous and deprecated.
meson setup works since 0.42 and this deprecation warning was introduced
in 0.64
$make_check_pre can be used for wrapper commands like xvfb-run or
dbus-run-session which are common ways to make tests work. This way many
templates can avoid defining their own do_check function.
This reverts commit 2163ca2d03.
Removing `export AR=gcc-ar` was apparently done based on the assumption
that the linked issue (https://github.com/mesonbuild/meson/issues/1646)
had been solved completely on meson's side.
Instead, their solution, seen in
https://github.com/void-linux/void-packages/pull/2815, had been to force
gcc-ar for linking static libraries; by exporting `AR=ar`, we were
accidentally breaking static libraries when LTO is enabled. This was
noticed by leah while we were trying to build qemu-user-static using the
normal libglib-devel package (built with meson, which for us defaults to
enabling LTO).
Unfortunately, while correct, this change wasn't enough to fix the
static glib build, which had to resort to disabling LTO.
This allows the build system to detect itself whether it should use
certain features, instead of defaulting to (potentially bad) enabled
status.
Features that aren't detected properly, be it because false positives or
negatives, should be explicitly called out in the templates.
meson 0.54 now honors _FOR_BUILD env vars, and we don't have to set CC
and friends to the host system vars. Setting PKG_CONFIG_FOR_BUILD is
needed since otherwise it would pickup our cross wrapper
This adds the build profiles for ppc64 targets as well as
modifications in other parts of the infra.
These targets are supported:
- ppc64le (glibc little endian elfv2)
- ppc64le-musl (musl little endian)
- ppc64-musl (musl big endian)
ELFv1 targets are explicitly not supported at this point.
Big endian musl supports ppc 970 or newer, while little endian
targets are set to a generic powerpc64le which effectively means
POWER8 and newer. Tuning is always set for POWER9, which is the
most likely target hardware. We also make sure AltiVec is always
on, because it is supported on all hardware we target.
[ci skip]
PKG_CONFIG environment variable should point to the pkg-config executable
to be used to fetch dependencies that use 'native: true' (indicate to build
against host libraries not cross-compiled ones)
To meet those requirements we set an absolute path to the host
pkg-config since the relative path to pkg-config is taken by the
wrapper.
This currently requires a patch that is a milestone of meson-0.48 that
was generated by the issue:
https://github.com/mesonbuild/meson/issues/1736
meson when compiling something with 'native: true' (for building
executables that are meant to be run on the host system) uses CFLAGS
and CXXFLAGS environment variables, we "pollute" them with
TARGET system cflags/cxxflags, such as -march= for the cross-compiled
arch.
so to fix it we export CFLAGS and CXXFLAGS to be CFLAGS_host and
CXXFLAGS_host respectively, they are set by XBPS and correspond to
the XBPS_CFLAGS/XBPS_CXXFLAGS. This same set of changes is also done
with CC and CXX see L#61
this was found when cross-compiling lighttpd which created the
'lemon' executable to generate inputs
thanks to @Cogitri from Exherbo for helping me debug this
[ci skip]
following https://mesonbuild.com/Cross-compilation.html
- host_machine is our XBPS_TARGET_MACHINE
- build_machine is our XBPS_MACHINE, and meson can find out the details
on it's own
- also don't include -musl in the CPU because meson doesn't recognize it
and projects like Mesa (LibGL) don't enable optimizations for it
- cpu_family and cpu are different, they need to be set properly:
- armv* is arm
- mips* is mips
- i686 is x86
- x86_64 is x86_64
- aarch64 is aarch64