Due to the support for specifying version as files('VERSION'), we need
to internally accept an array, since that is what files() returns.
Before that, we didn't accept arrays, and after that, we don't intend to
accept generic arrays, only arrays as a side effect of files(). So
tighten the typechecking to ensure that that is what we actually get.
If the found python returns None from sysconfig.get_config_var('LIBPC')
then we cannot (and don't) set PKG_CONFIG_LIBDIR from it. In fact, we
can virtually guarantee we won't find a PkgConfigDependency either,
because any python that doesn't have a LIBPC is presumably not installed
to the system pkg-config directory (maybe it's an isolated relocatable
install, maybe it just doesn't have pkg-config support for who knows
what reason).
Trying to find one anyway using pkg-config's builtin search paths can
unexpectedly succeed, though, by finding a completely unrelated python
installation installed to a system location, which isn't the one we are
actually building for.
Instead, return early so that we use the system dependency class
fallback.
While we are at it, add back the debug messages from #3989 which got
removed.
There is the problem of the annotations themselves, then there is
the problem with depends being mutated. The mutation side effect is a
problem in itself, but there's also the problem that we really want to
use Sequence, which isn't mutable.
This is currently allowed, and is used in at least a few projects. It
was not intended to work or documented, but it does and since it is in
use a full deprecation period must be used. A warning has also been
added for values < 0, which have surprising behavior.
This removes the ability to use ConfigurationData as a dict, but
restricting the inputs to `str | int | bool`. This may be a little too
soon for this, and we may want to wait on that part, it's only bee 8
months since we started warning about this.
This is a layering violation, we're relying on the way the interpreter
handles keyword arguments. Instead, pass them as free variables,
destructuring in the interpreter
This code path is only called on initial download of a subproject, but
if we raise an error and abort while downloading/applying a patch
overlay we still have the upstream sources extracted... which appears to
be a subproject, then turns out to be broken due to missing meson.build
Partially implements #9688
The tests and the unittests both unconditionally call setup_vsenv()
because all tests are run using the backend commands directly: ninja,
msbuild, etc.
There's no way to undo this vs env setup, so the only way to test that
--vsenv works is by:
1. Removing all paths in PATH that provide ninja
2. Changing setup_vsenv(force=True) to forcibly set-up a new vsenv
when MESON_FORCE_VSENV_FOR_UNITTEST is set
3. Mock-patching build_command, test_command, install_command to use
`meson` instead of `ninja`
4. Asserting that 'Activating VS' is in the output for all commands
5. Ensure that compilation works because ninja is picked up from the
vs env.
I manually checked that this test actually does fail when the previous
commit is reverted.
Otherwise we might not find a ninja that was picked up from the Visual
Studio installation.
```
$ meson setup _build
...
Activating VS 15.9.40
...
Found ninja-1.8.2 at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja\ninja.EXE"
$ meson compile -C _build
Activating VS 15.9.40
...
$ meson install -C _build
Can't find ninja, can't rebuild test.
```
Fixes https://github.com/mesonbuild/meson/issues/9774
It used to support:
- a single string
- an array of anything
And as long as CustomTarget supported it too, everything worked fine.
So, a `files('foo')` worked but a `files('foo')[0]` did not, which is
silly... and it's not exactly terrible to use files() here, the input is
literally a list of source files.
Fixes building gnome-terminal
Fixes#9827
Test updated by Nirbheek Chauhan <nirbheek@centricular.com>
The original attempted fix only allowed configuration to succeed, but
not building. It was modeled based on the gdbus-codegen documentation,
which states:
--annotate WHAT KEY VALUE WHAT KEY VALUE WHAT KEY VALUE
Add annotation (may be used several times)
which clearly indicates that gdbus-codegen accepts an --annotate flag
that is followed by a multiple of 3 values, despite this not actually
working.
The manpage actually contradicts the --help text:
--annotate ELEMENT KEY VALUE
Used to inject D-Bus annotations into the given XML files. []
... and gives examples that use multiple --annotate flags each with 3
arguments.
To better understand what meson is supposed to do here, we should look
at ef52e60936, which ported to
typed_kwargs. There is actually a big chunk of code to handle
annotations that got completely dropped, leading with a comment (that
did not get dropped): "they are a list of lists of strings..."
Reimplement this logic inside a validator/converter for the annotations
kwarg container:
- do not listify, we don't accept `annotations: ''` and listify is
supposed to be for when either x or list[x] is valid
- go back to checking for a list of exactly 3 values
- allow a list of the aforementioned, in the traditionally expected
form:
[
['foo1', 'foo2', 'foo3'],
['bar1', 'bar2', 'bar3'],
]
- pass one --annotate flag per 3-value-list
And add some better error reporting for the cause of errors when
processing lists of lists.
Eli Schwartz
Dylan Baker
Daniel Mensinger
Matthias Klumpp
Nirbheek Chauhan
Gatgat