| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
|
|
After a discussion implementing this for muon [1] and clarification on
IRC on Meson's behaviour.
[1] https://lists.sr.ht/~lattis/muon/patches/26722
|
|
find_library(has_headers)
All kwargs inherited from has_header need to be prefixed `header_` so we
cannot just do straight inheritance. And the part of the description
that highlighted the way kwargs are derived and evolved, went entirely
missing.
Fixes #9551
|
|
|
|
"seperator" -> "separator"
|
|
More stuff that got overlooked during the big refman migration.
|
