| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
As of this commit, meson has three different
pathways to set an exe_wrapper field.
exe_wrapper set through `meson test --wrapper`
CLI arg or `add_test_setup()` meson function argument
are treated equally. Only one wrapper through either
of these routes may be set though.
The exe_wrapper field set in the cross file is handled
separately internally in mtest.py, and holds a little
more consequence over meson test behavior than the other
two fields.
Perhaps a future version of meson should treat these
fields equally and explicitly document how they are
combined.
For now, I think its a better first step to
document current behavior to generate discussion about
how exactly the future version should behave.
|
|
Fixes #14338
|
|
|
|
|
|
|
|
|
|
This is wrong, it should use "meson setup builddir".
|
|
Let people easily find the documentation for concepts we are trying to
teach.
|
|
|
|
|
|
|
|
It's a pure subset of `get_external_property`, and has odd behavior in
host == build configurations. `get_external_property` is clear, and uses
the standard `native : bool` syntax to control host vs build properties
|
|
|
|
|
|
Signed-off-by: Antonin Décimo <antonin.decimo@gmail.com>
|
|
- Exceptions raised during subproject setup were ignored.
- Allow c_stdlib in native file, was already half supported.
- Eliminate usage of subproject variable name by overriding
'<lang>_stdlib' dependency name.
|
|
|
|
The implementation of this function has changed enough that the name
doesn't really reflect what it actually does. It basically returns true
unless you're cross compiling, need and exe_wrapper, and don't have one.
The original function remains but is marked as deprecated.
This makes one small change the meson source language, which is that it
defines that can_run_host_binaries will return true in build == host
compilation, which was the behavior that already existed. Previously
this was undefined in build == host compilation.
|
|
Also note that meson doesn't use `el` on the end of the cpu_family to
mark endianness, that the endian field needs to be set appropriately.
|
|
Rather than having two separate sections with duplicated information
lets just have one for the common settings, and only document sections
specific to each file in separately
|
|
|
|
In order to unify the use of sysroot in the cross-file,
the pkg_config_libdir can now be passed directly in the file.
|
|
Add a way to select the dynamic linker meson uses
|
|
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 #3801
Fixes #4057
|
|
Just like the previous patch, but for cross files
Fixes #1433
|
|
|
|
The target platform of cross compiler is the host platform of the project being built.
|
|
Works on all non-Windows since cf98f5e3 (PR #3119)
|
|
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.
|
