Allow using the links method to test that the C++ driver (e.g. g++) can be used to
link C objects. One usecase is that the C compiler's libsanitizer might not be
compatible with the one included by the C++ driver.
This is theoretically backwards-incompatible, but it should be treated as a
bugfix in my opinion. There is no way in Meson to compile a .c file with the
C++ driver as part of a build target, therefore there would be no reason to
do something like meson.get_compiler(meson.get_compiler('cpp').links(files('main.c')).
Fixes: #7703
It is a commonly needed information to help debugging build issues. We
already were printing options with non-default value at the end of the
configure but outside of the summary.
Keeping the list of user defined options in the interpreter will also in
the future be useful to use new default value on reconfigure.
This simplifies things for us, as we don't have to have threading
imported for no other reason, and we can remove the
`an_unpicklable_object` from the Interpreter and mesonlib, since there
was only one user of this.
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
Currently, EnvironmentVariablesObject is a strange
holder-that's-not-a-holder. This has implicaitons for things that expect
to get an EnvironmentVariables object, as we can't automatically
unholder it, and instead have to to manually do so. Now we can
automatically unholder it, which makes everything much nicer.
It should build the fallback subprject with default_library=static and
override the dependency for both static=True and static kwarg not given.
Fixes: #8050.
We recommend people use declare_dependency and access it via
dependency() in a parent project. But this requires a wrap file (or to
use override_dependency and an explicit subproject call).
Let's actually mention that.
Fixes#9146
In the case main->subp->subsubp, if subsubp succeed to configure but
subp subsequentially fails, subsubp is still being built but its summary
was missing.
Including not calling back into `Interpreter.func_*`, which is not a
good idea both from a type saftey and perforamance point of view.
Instead there's now a shared _impl method
Paolo Bonzini
Filipe Laíns
Xavier Claessens
Daniel Mensinger
Dylan Baker
Rihards Skuja
Tristan Partin
Eli Schwartz
Jussi Pakkanen
Felix Schwarz