They passed the arguments in the wrong order, so the version parsed as the
message and the message parsed as a version.
While we are at it, pass the location node in too.
We allow this for the command (the first parameter), but not later
parameters, which is just odd. This also allows us to give better error
messages for the case of overridden programs.
This also cleans up a couple of internal callers of the internal impl
version that don't set the `check` argument, and therefore trigger a
warning about not setting the check argument.
If the compiler check is updated as a string in meson.build, we force
rebuild, which is a good thing since the outcome of that check changes
the configuration context and can enable or disable parts of the build.
If the compiler check came from a files() object then we didn't add a
regen rule on those files.
Fixes#1656
This ensures that there is no warnings when running meson on
test cases/common/22 object extraction.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Calling interpreter implementation methods is just a bad idea, apart
from the extra type checking that goes into it, we need to pass more
arguments than we need to calling the impl method.
This also includes a few type annotation cleans for the Summary object.
Getting the positional arguments exactly right is impossible, as this is
really a function with two different signatures:
```
summary(value: dictionary): void
summary(key: string, value: any): void
```
We can get close enough in the typed_pos_args by enforcing that there
are two parameters, one required and one optional, and that the first
must be either a dictionary or a string.
This is only relevant on certain versions of meson, so do not print it
when meson_version is too low.
The message itself is not precisely a deprecation warning, since
ostensibly it may be an unlikely coding mistake. It is probably an
attempt to implement `copy: true`, but it might not be, hence "warning"
instead of "deprecation". So although we could switch this to a
FeatureDeprecated, that is not being done at this time.
Without this patch, the name of the RunTarget is passed to the
install script; for the enclosed test, meson setup (incorrectly)
succeeds, but installation fails.
Fixes the following error in the testcase:
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/ninjabackend.py", line 548, in generate
self.generate_tests()
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/ninjabackend.py", line 1093, in generate_tests
self.serialize_tests()
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 567, in serialize_tests
self.write_test_file(datafile)
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 943, in write_test_file
self.write_test_serialisation(self.build.get_tests(), datafile)
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 1017, in write_test_serialisation
pickle.dump(self.create_test_serialisation(tests), datafile)
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 1002, in create_test_serialisation
cmd_args.append(self.construct_target_rel_path(a, t.workdir))
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 1021, in construct_target_rel_path
return self.get_target_filename(a)
File "/usr/lib/python3.10/site-packages/mesonbuild/backend/backends.py", line 253, in get_target_filename
assert(isinstance(t, build.BuildTarget))
String formatting should validly assume that printing a list means
printing the list itself. Instead, something like this broke:
'one is: @0@ and two is: @1@'.format(['foo', 'bar'], ['baz'])
which would evaluate as:
'one is: foo and two is: bar'
or:
'the value of array option foobar is: @0@'.format(get_option('foobar'))
which should evaluate with '-Dfoobar=[]' as
'the value of array option foobar is: []'
But instead produced:
meson.build:7:0: ERROR: Format placeholder @0@ out of range.
Fixes#9530
install: false was only available since 0.50, so we should not warn
people who support older versions to use something they cannot.
Fortunately, we can do FeatureDeprecated for this -- and then it even
gets summarized. Unfortunately, it's not well used, and certainly isn't
here.
It has always been working even if not documented and there is no reason
to not accept it. However, change "True/False" to "true/false" to be
consistent with meson language.
Fixes: #9436
Now, warnings are unconditionally raised when parsing the wrap file,
whether they are used or not. That being said, these warnings literally
just check for a couple of keys used in the .wrap ini file.
Moving these checks from the time of use to the time of loading, means
that we no longer report warnings only when originally downloading or
extracting the file or VCS repo.
It also means we no longer report warnings in one subproject, when a
wrap file is picked up from a different subproject because the first
subproject actually does a dependency lookup. This caused issues for the
WrapDB tooling, which uses patch_directory everywhere and the
superproject requires a suitable minimum version of meson for this...
but individual wraps might use a much lower version, and would then
raise a warning (in strict mode, converted to an error) when it resolved
a dependency from another WrapDB project.
Fixes#9118
This reverts commit c0efa7ab22.
This was a nice idea, or a beautiful hack depending on your perspective.
Unfortunately, it turns out to be a lot harder than we originally
thought. By operating on bare nodes, we end up triggering a FeatureNew
on anything that isn't a string literal, rather than anything that
isn't a string.
Since no one else has come up with a better idea for implementing a
FeatureNew, let's just revert it. Better to not have a warning, than
have it trigger way too often.
Paolo Bonzini
Pablo Correa Gómez
Eli Schwartz
Dylan Baker
Benoit Pierre
Yasushi SHOJI
Volker Weißmann
rusty-snake
Xavier Claessens
Daniel Mensinger
Thomas Heijligen
Christian Clauss
Jussi Pakkanen