This fixes two separate issues, one is that benchmark warns about
depends and priority; The other is that we passed bad values like
is_parallel into the test and would actually run benchmarks in parallel,
which is bad.
In qemu, minikconf generates a depfile that meson could use to
automatically reconfigure on dependency change.
Note: someone clever can perhaps find a way to express this with a
ninja rule & depfile=. I didn't manage, so I wrote a simple depfile
parser.
Since commit 38a658214 ("configure_file: Support taking values from a
dict" #4236), configuration_data() and configure_file()'s
configuration kwarg can take a dict. Add missing version checks.
* backends/vs: Only set platform_toolset if it isn't already set
* interpreter: set backend up after the compiler
Otherwise we won't be able to check which VS toolchain to use.
* docs/using-visual-studio: wrap lines
* docs: recommend the py launcher instead of python3 for windows
* set backend.environment when building a dummy version
* backends/vs: Add support for clang-cl with vs2017 and vs2019 backends
* backends/vs: Add support for ICL (19.x) with vs2015 and vs2017 backends
When g-ir-scanner is overriden, we can't call it at configure time
but we know what options are avalaible (as it started using meson
after checked options where added) so do not try to call it to retrieve
the version as it will fail.
Also see https://github.com/mesonbuild/meson/issues/3442
It is often desirable to use ~ for home directory in -D compilation args.
Why the transform to pathlib.Path and back to str? Because this is one of many
places where the list(map(str,..))) will be eliminated upon Python 3.6 being
minimum Meson Python requirement.
Build and target info is confusing in that case. However still log that
information, as it is useful in case something slips out of sync and
needs to be debugged.
This further simplifies behavior to match the "build vs host" decision
we did with `c_args` vs `build_c_args`. The rules are now simply:
- `native: true` affects `native: true` targets
- `native: false` affects `native: false` targets
- No native flag is the same as `native: false`
I like this because you don't even have to know what "build" and "host"
mean to understand how it works, and it doesn't depend on whether the
overall build is cross or not.
Fixes#4933
In most cases instead pass `for_machine`, the name of the relevant
machines (what compilers target, what targets run on, etc). This allows
us to use the cross code path in the native case, deduplicating the
code.
As one can see, environment got bigger as more information is kept
structured there, while ninjabackend got a smaller. Overall a few amount
of lines were added, but the hope is what's added is a lot simpler than
what's removed.
It doesn't make much sense to have this and not also have
cross-compilers (so any use of this is already pretty suspect as
probably wrong when cross-compiling).
This information is accessible anyhow via environment.coredata.
Daniel Mensinger
Dylan Baker
Xavier Claessens
Marc-André Lureau
Peter Hutterer
Jussi Pakkanen
Rachel Mant
Thibault Saunier
Michael Hirsch, Ph.D
James Hilliard
John Ericson
John Ericson
Mathieu Duponchelle
Jon Turney