| 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
|
|
|
|
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.
|
|
When arrays were added they were called arrays. Because the are
implemented with Python lists, that language started leaking into
talking about Meson types. This is confusing. I've attempted, as much as
possible, to move to using one name, array. I picked array because 1)
It's the original name used, and 2) what Meson has are more properly
arrays as they have a fixed length, while a critical property of lists
are the ability to link and unlink them.
There are a couple of places where the list language has leaked into the
names of keyword arguments. I have not made any attempt to change those,
I don't know if it's that useful or not.
|
|
|
|
|
|
|
|
The example incorrectly uses `then` after the if condition, which is
incorrect meson syntax as meson does not support a `then` keyword.
|
|
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
|
|
This is a similar commit to the one that added required to all the
compiler.has* functions.
|
|
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.
|
|
Fixes #10901
|
|
|
|
This was inherited from documentation of build target, but some sentences do not make sense in the context of the preprocessor.
|
|
This patch adds 'depends' keyword to compiler.preprocess().
It allows to execute other targets before doing the preprocessing.
Test-case is added to demonstrate that functionality: it
generates the header before preprocessing the C source that
uses that generated header.
Thanks to @bruchar1 for getting this patch to work.
|
|
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
|
|
|
|
A standard C library may not exist for cross-compile
environments, thus the existence of <stdio.h> cannot be
guaranteed.
Use <stddef.h> instead, this header contains compiler-specific
defines thus it usually comes from the compiler.
|
|
Adds a new method to the compiler object, has_define.
This makes it possible to check if a preprocessor macro/define
is set or not.
This is especially helpful if the define in question is empty,
for example:
#define MESON_EMPTY_DEFINE
This would yield the same results as a missing define with
the existing get_define method, as it would return an empty
string for both cases. Therefore this additional method is
needed.
|
|
|
|
|
|
These are much easier to understand at a glance than free-form text.
|
|
Fixes: #5399
|
|
|
|
add the "required" keyword to the functions
has_function
has_type
has_member
has_members
has_argument
has_multi_arguments
has_link_argument
has_multi_link_argument
has_function_attribute
Co-authored-by: Milan Hauth <milahu@gmail.com>
|
|
The object is not used only for tests, but also for `custom_target` etc.
|
|
|
|
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
|
|
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.
|
|
It's always been strange to me we don't have an opposite method of the
`disable_auto_if` method, but I've been pressed to find a case where we
_need_ one, because `disable_auto_if` can't be logically contorted to
work. I finally found the case where they're not equivalent: when you
don't want to convert to a boolean:
```meson
f = get_option('feat').disable_auto_if(not foo)
g = get_option('feat').enable_auto_if(foo)
dep1 = dependency('foo', required : f)
dep2 = dependency('foo', required : g)
```
|
|
|
|
|
|
Fixes: #11202
|
|
Link to feature options consistently, and point out that it controls
"whether" the function finds what it's trying to find. This clues people
in to the fact that disabled features exist.
|
|
|
|
The previous description update was lacking an example of why
external_program cares about inter-target dependencies.
|
|
Claiming that "it should literally never be used ever no matter what" is
confusing and wrong -- it's definitely useful sometimes, but does result
in downsides, like not tracking inter-target dependencies correctly.
Ref: #10901
|
|
Add cc.preprocess() method
|
|
|
|
|
|
|
|
|
|
|
|
It is often useful to check the found version of a program without
checking whether you can successfully find
`find_program('foo', required: false, version: '>=XXX')`
|
|
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.
|
