| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In case of python and especially in the case of pyInstaller
where the python command is meson.exe runpython, it should
not be full path to be used but cmd_array.
Fixing #13834
|
|
No need to focus on the "value" part of the name.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This allows us to avoid making `feature` a union, therefore if we write
code like:
```python
disabled, required, feature = extract_required_kwarg(...)
if disabled:
...
```
and now mypy knows that feature is a `str` inside the `if disabled`
block
|
|
The cleanup this allows lower down points out that we don't properly
validate the value passed to `as_system()`. I have no idea what happens
if you pass a non-valid value, but it's a bug and I've simply made it a
hard error. We can re-assess if necessary.
|
|
Fixes: #12519
|
|
This allows us to do a lot less proxy checking for vala, and lot more
"If this thing says it's going to output vala, it's going to output
vala. By only setting them when they use vala, we can also be sure that
the fields aren't meaningless.
|
|
All that is needed is the subdir, pass it explicitly (and make it
an optional argument so that the backend does not have to pass it).
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This reverts https://github.com/mesonbuild/meson/pull/15107
Explicit objections regarding the design were raised and not answered,
so it shouldn't have been merged. It needs to be discussed and
revisited.
|
|
|
|
|
|
|
|
Fixes: #2296
Fixes: #4481
Fixes: #5968
|
|
Same as the previous, but for VAPI
|
|
This allows targets that don't link with a vala target to rely on the
header generation.
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Do not call update() and Enum.__hash__ a gazillion times; operators
are the same for every instance of the class. In order to access
the class for non-trivial operators, the operators are first marked
using a decorator, and then OPERATORS is built via __init_subclass__.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
In preparation for moving them to the class, make the operator functions
binary. Adjust the lambdas for trivial operators, and store unbound
methods for non-trivial ones.
Note that this requires adding operators manually for every override,
even subclasses. It's decidedly ugly at this temporary stage; later
it will result in just an extra @InterpreterObject.operator decorator
on the subclasses.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Also ensure that .get_version() can be called on the output of
_find_tool by the modules (kind of required for #14422).
|
|
A doctest target is a separate build target (with its own linker
arguments, including dependencies) that is built and added as a
unit test whenever the parent target is built. The doctest's
target is not accessible via ninja.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
Co-authored-by: Xavier Claessens <xclaesse@gmail.com>
|
|
|
|
|
|
|
|
If a user imports a module and invokes a method on it,
a raw Python exception is raised to the user. This commit
adds a check to ensure that in this case an appropriate
exception is raised instead.
A test has been added to ensure that this exception is
in fact raised on offending code.
Fixes: #11393, #5134
|
|
|
|
|
|
Although it's not especially common, there are certainly cases where it's
useful to pass the path to an external program to a test program.
Fixes: https://github.com/mesonbuild/meson/issues/3552
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
|
|
This reverts commit 9f02d0a3e5a5ffc82256391c244b1af38e41ef78.
It turns out that this does introduce a behavioral change in existing
users of ConfigurationData, which it wasn't supposed to (it was supposed
to preserve behavior there, and add a new *warning* for
EnvironmentVariables).
This breaks projects such as pulseaudio, libvirt, and probably more.
Roll back the change and try again after 1.5.0 is released.
Fixes: #13372
|
|
|
|
|
|
|
|
The docs didn't really explain what the issue was with using it. And
it's not actually a "crash" either way.
The FeatureNew mentions that "name" is new, but it is standard for
these warnings to tell you both the type of object you're operating on
and the name of the method that is an issue. This omitted the former,
and was very confusing.
|
|
This allows `cc.find_library().name()` to work, just like
`dependency().name()`.
Fixes: #13053
|
|
Only Environment and ConfigurationData are mutable. However, only
ConfigurationData becomes immutable after first use which is
inconsistent.
This deprecates modification after first use of Environment object and
clarify documentation.
|
|
Use a capital letter at the beginning of a sentence.
|
|
Fixes #6567
|
|
|
|
This is needed now that str.format() is not allowing it any more. It is
also more consistent with other objects that have that method as well,
such as build targets.
Fixes: #12406
|
|
It was previously impossible to do this:
```
dep.get_pkgconfig_variable(
'foo',
define_variable: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
since get_pkgconfig_variable mandated exactly two (if any) arguments.
However, you could do this:
```
dep.get_variable(
'foo',
pkgconfig_define: ['prefix', '/usr', 'datadir', '/usr/share'],
)
```
It would silently do the wrong thing, by defining "prefix" as
`/usr=datadir=/usr/share`, which might not "matter" if only datadir was
used in the "foo" variable as the unmodified value might be adequate.
The actual intention of anyone writing such a meson.build is that they
aren't sure whether the .pc file uses ${prefix} or ${datadir} (or which
one gets used, might have changed between versions of that .pc file,
even).
A recent refactor made this into a hard error, which broke some projects
that were doing this and inadvertently depending on some .pc file that
only used the second variable. (This was "fine" since the result was
essentially meaningful, and even resulted in behavior identical to the
intended behavior if both projects were installed into the same prefix
-- in which case there's nothing to remap.)
Re-allow this. There are two ways we could re-allow this:
- ignore it with a warning
- add a new feature to allow actually doing this
Since the use case which triggered this bug actually has a pretty good
reason to want to do this, it makes sense to add the new feature.
Fixes https://bugs.gentoo.org/916576
Fixes https://github.com/containers/bubblewrap/issues/609
|
|
|
|
This also makes it more consistent with get_pkgconfig_variable() which
always return empty value instead of failing when the variable does not
exist. Linking that to self.required makes no sense and was never
documented any way.
|
|
Make sure that pkgconfig_define is a pair of strings and not a list with
more than 2 strings.
|
|
ExternalProgram and CustomTarget have some use cases for producing
subclassed interpreter holders with more specific types and methods. In
order for those subclasses to properly refer to their held_object, we
need a shared base class that is still generic, though bound.
For the derived held objects, inherit from the base class and specify
the final types as the module-specific type.
|
|
This detects cases where module A imports a function from B, and C
imports that same function from A instead of B. It's not part of the API
contract of A, and causes innocent refactoring to break things.
|
|
|
|
This has never been undocumented and there's no obvious value to having
it or using it. We're not even sure anyone ever has used it.
Closes #6061
|
|
|
|
This adds two new methods, that are conceptually related in the same way
that `enable_auto_if` and `disable_auto_if` are. They are different
however, in that they will always replace an `auto` value with an
`enabled` or `disabled` value, or error if the feature is in the
opposite state (calling `feature(disabled).enable_if(true)`, for
example). This matters when the feature will be passed to
dependency(required : …)`, which has different behavior when passed an
enabled feature than an auto one.
The `disable_if` method will be controversial, I'm sure, since it
can be expressed via `feature.require()` (`feature.require(not
condition) == feature.disable_if(condition)`). I have two defences of
this:
1) `feature.require` is difficult to reason about, I would expect
require to be equivalent to `feature.enable_if(condition)`, not to
`feature.disable_if(not condition)`.
2) mixing `enable_if` and `disable_if` in the same call chain is much
clearer than mixing `require` and `enable_if`:
```meson
get_option('feat') \
.enable_if(foo) \
.disable_if(bar) \
.enable_if(opt)
```
vs
```meson
get_option('feat') \
.enable_if(foo) \
.require(not bar) \
.enable_if(opt)
```
In the first chain it's immediately obvious what is happening, in the
second, not so much, especially if you're not familiar with what
`require` means.
|
