Meson's documentation about cross-compilation made me finally understand
why the typical confusion about machine names. Thanks, but let's make it
even better. Don't wait until the very end of the section to reveal the
most important information: that machine names are relative. For
suspense we already have TV shows; spill the beans much earlier.
Also fix the first, simplest cross-compilation example: target is
irrelevant.
In some cases it may be necessary to set PKG_CONFIG_SYSROOT_DIR, like
when you've mounted a host architecture system in an arbitrary path.
Meson will now check the cross files for a [properties]:sys_root
variable and set the PKG_CONFIG_SYSROOT_DIR environment variable based
on that variable.
Fixes#3801Fixes#4057
One thing that makes cross compiling with meson a pain is the need for
cross files. The problem is not with cross files themselves (they're
actually rather brilliant in that they allow for a much greater deal of
flexibility than autotools hardcoded paths approach) but that each user
needs to reimplement them themselves, when for most people what they
really want is a cross file that could be provided by their distro, all
they really want is the correct toolchain.
This patch is the first stop to making it easier for distros to ship
their own cross files (and for users to put their's somewhere safe so
they don't get `git clean`ed. It allows the cross files (on Linux and
*BSD) to be stored in home and system paths (~/.config/meson/cross,
/usr/share/meson/cross, and /usr/local/share/meson/cross), and to be
loaded by simply by specificying --cross-file.
With this patch meson will check the locations its always checked first,
(is cross file absolute, or is it relative to $PWD), then will check
~/.config/meson/cross, /usr/local/share/meson/cross,
/usr/share/meson/cross, (or $XDG_CONFIG_PATH and $XDG_DATA_DIRS) for the
files, raising an exception if it cannot find the specified cross file.
Fixes#2283
This is useful when build_machine appears to be compatible with
host_machine, but actually isn't. For example when:
- build_machine is macOS and host_machine is the iOS Simulator
- the build_machine's libc is glibc but the host_machine libc is uClibc
- code relies on kernel features not available on the build_machine
This allows us to more easily have the documentation in sync with
the source code as people will have to document new features etc
right at the time where they implement it.