We do not want anyone touching this entire directory tree, but due to
the way it was implemented, we only checked if its direct parent was a
subproject violation. This generally worked, unless people tried to add
`subprojects/` as an include directory.
Patch this hole. It now provides the same warning any sandbox violation
does (but is not currently an error, just a "will become an error in the
future").
Because we don't want to pass the Interpreter kwargs into the build
layer. This turned out to be a mega commit, as there's really on elegant
way to make this change in an incremental way. On the nice side, mypy
made this change super easy, as nearly all of the calls to
`CustomTarget` are fully type checked!
It also turns out that we're not handling install_tags in custom_target
correctly, since we're not converting the boolean values into Optional
values!
The utility function that processes this for both 'variables' and
'uninstalled_variables' accepts a kwarg for the name of the argument,
but then hardcodes 'variables' in the warning message. This is
misleading.
In commit 06481666f4 this warning got
moved from build.py to the interpreter. Unfortunately it got added to
the wrong function... it is supposed to be part of custom_target and
even mentions this as the feature_name.
Since then, build_always became a KwargInfo and has the deprecated-since
attribute baked into it. But it didn't have the additional message which
it really should have.
Add that message at the same time we remove it from vcs_tag.
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.
Fixes a bug where the subproject version was not validated
when the subproject had already been processed.
The bug would cause inconsistent build results if the subproject was
referenced more than once (diamond) with conflicting version requirements.
Currently there is a try/except around the function that detects and
rejects this, which instead of rejecting it, spawns a warning and
continue.
This warning exists because of 'test cases/vala/9 gir/' which passes a
vala generated output that isn't a return value (!!!) using string
joining with the meson.current_build_dir() function (also !!!) because
we officially document this (!!! for a third time) as the only way to
make a vala shared library generate a typelib with a custom_command from
the automatically generated gir:
https://mesonbuild.com/Vala.html#gobject-introspection-and-language-bindings
In #3061 we converted strings to Files, but only if none of them were
this vala hack. Due to the precise implementation, we also failed to
convert strings to Files if any other error occurred, but since we only
want to ignore errors for generated vala outputs, tighten that check and
specifically call out generated files in the warning.
Fixes#8635
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.
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.
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))
Xavier Claessens
Christian Wendt
Eli Schwartz
Jussi Pakkanen
Paolo Bonzini
Dylan Baker
Øyvind Aarrestad Aakre
Pablo Correa Gómez
Yasushi SHOJI