This is a significant speed-up on Windows because terminals are
slow to print things out.
Speed-up in gst-build on Windows:
```
meson install:
before: 5.1 seconds
after: 4.0 seconds
```
This improves the common case of a simple meson.build which doesn't
contain any 'native: true' targets to not require a native compiler when
cross-compiling, without needing any changes in the meson.build.
v2:
Do it the right way around!
Currently it's just like if all builtin/base/compiler options are
yielding. This patch makes possible to have non-yielding builtin
options. The value in is overriden in this order:
- Value from parent project
- Value from subproject's default_options if set
- Value from subproject() default_options if set
- Value from command line if set
The documentation of "order-only" dependencies is limited and their
various purposes are especially not clear. See issue #6391 for a recent
example, search the internet for many more. So mention the particular
purpose here while making the documentation barely longer.
This allows Meson native-file [properties] to be used.
This avoids the need to call meson from a script file or have a
long command line invocation of `meson setup`
The method meson.get_native_property('prop', 'fallback') is added.
The native file can contain properties like
```
[properties]
myprop1 = 'foo'
mydir2 = 'lib/custom'
```
Then from within `meson.build`
```meson
x1 = meson.get_native_property('myprop1')
thedir = meson.get_native_property('mydir2', 'libs')
```
fallback values are optional
The rust code is ugly, because rust is annoying. It doesn't invoke a
linker directly (unless that linker is link.exe or lld-link.exe),
instead it invokes the C compiler (gcc or clang usually) to do it's
linking. Meson doesn't have good abstractions for this, though we
probably should because some of the D compilers do the same thing.
Either that or we should just call the c compiler directly, like vala
does.
This changes the public interface for meson, which we don't do unless we
absolutely have to. In this case I think we need to do it. A fair number
of projects have already been using 'ld' in their cross/native files to
get the ld binary and call it directly in custom_targets or generators,
and we broke that. While we could hit this problem again names like
`c_ld` and `cpp_ld` are far less likely to cause collisions than `ld`.
Additionally this gives a way to set the linker on a per-compiler basis,
which is probably in itself very useful.
Fixes#6442
Niklas Hambüchen
Nirbheek Chauhan
Jon Turney
Jussi Pakkanen
Daniel Mensinger
Xavier Claessens
Michael Hirsch, Ph.D
Marc Herbert
Michael
Dylan Baker
Kyle Stone
Lisa White
Stéphane Cerveau
Marc-Andre Lureau
alex-tee
Amit D