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.
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
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.
In commit c239ce31f5 support was added to
these functions to accept various non-string types.
Despite the commit/PR documenting that only add_install_script is
permitted to accept built files, the actual check parameter was set, for
all three, to "True" (so the function was never invoked with False at
all). This meant that actually attempting to use the allowed types would
fail at postconf or dist, with python tracebacks in the former case and
"Failed to run dist script" in the latter case.
This was partially ameliorated in commit
6c5bfd4c24 which added typed_pos_args, but
unfortunately those typed_pos_args were all over the place.
For postconf:
- They banned external programs as additional args (which should be allowed)
- They banned built executables (good)
- They allowed custom targets as additional args (bad)
For dist:
- they allowed external programs (good)
- they allowed built executables, but only as the first argument (bad, also ???)
- they allowed custom targets, but only as additional arguments (bad, also ???)
Fix this all to only allow the same argument types for both the script
argument and the script-args arguments. That type is known at configure
time and restricted to source files, configured files, and found
programs.
In commit 2c0eaf5c4f support was added for
install scripts to accept found programs, built executables, or custom targets.
In commit c239ce31f5, this was extended to
dist and postconf scripts too (although it was documented that those
should not accept targets that are built by ninja).
Despite the commit/PR claiming that all of these should always accept
files and configured files, this was only true for arguments other than
the first, until commit f808c955ea.
In amongst all this, FeatureNew checks were never registered for the
first argument, only for additional arguments, until late in the game
with the addition of FeatureNew checks for File objects.
Fix this in part by moving the 3 different File checks into one, inside the
function that processes the first script, and make that function check
for FeatureNew on anything else too.
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
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.
Eli Schwartz
Dylan Baker
Øyvind Aarrestad Aakre
Daniel Mensinger
Paolo Bonzini
Pablo Correa Gómez
Benoit Pierre