* 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.
Meson itself *almost* only cares about the build and host platforms. The
exception is it takes a `target_machine` in the cross file and exposes
it to the user; but it doesn't do anything else with it. It's therefore
overkill to put target in `PerMachine` and `MachineChoice`. Instead, we
make a `PerThreeMachine` only for the machine infos.
Additionally fix a few other things that were bugging me in the process:
- Get rid of `MachineInfos` class. Since `envconfig.py` was created, it
has no methods that couldn't just got on `PerMachine`
- Make `default_missing` and `miss_defaulting` work functionally. That
means we can just locally bind rather than bind as class vars the
"unfrozen" configuration. This helps prevent bugs where one forgets
to freeze a configuration.
This avoids the duplication where the option is stored in a dict at its
name, and also contains its own name. In general, the maxim in
programming is things shouldn't know their own name, so removed the name
field just leaving the option's position in the dictionary as its name.
This function is currently setup with keyword arguments defaulting to
None. However, it is never called without passing all of it's arguments
explicitly, and only one of it's arguments would actually be valid as
None. So just drop that, and make them all positional. And annotate
them.
Daniel Mensinger