| Age | Commit message (Collapse) | Author |
|---|
|
If the user runs `sudo meson install` this may run ninja to build
everything that gets installed. This naturally happens as root also, by
default, which is bad. Instead, detect root elevation tools and drop the
uid/gid of the child ninja process back to the original invoking user
before doing anything.
|
|
There's a couple issues with the current approach:
- pkexec is an unusual elevation method, the standard is sudo
- it tries to elevate even in automated workflows
- the user may not want to automatically rerun as root, that might be
badly behaved
Do some upfront checks instead, first to make sure it even makes sense
to try becoming root, and then to ask the user "do you really want
this". Also check for a couple common approaches to root elevation,
including doas.
Fixes #7345
Fixes #7809
|
|
This method allows meson.build to introspect on the changed options.
It works by merely exposing the same set of data that is logged by
MesonApp._generate.
Fixes #10898
|
|
When using a pre-built library
|
|
Instead of just giving a note about about how this is best practice,
actually do it.
|
|
|
|
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)
```
|
|
Added in commit 2fa074917597fea0cf3332c6620d3414034825e4 but I forgot to
document it.
|
|
|
|
|
|
Fixes #11373.
|
|
|
|
|
|
"extra_arguments" should be "extra_args"
|
|
Currently Meson allow the following (Muon does not):
```meson
option('foo', type : 'boolean', value : 'true')
option('bar', type : 'integer', value : '42')
```
This is possibly a holdover from very old code, but it's a bad idea and
we should stop doing it. This deprecation is the first stop on that
journey.
|
|
|
|
|
|
It is often more useful to generate shell script than dumping to stdout.
It is also important to be able to select the shell format.
Formats currently implemented:
- sh: Basic VAR=prepend_value:$VAR
- export: Same as 'sh', but also export VAR
- vscode: Same as 'sh', but without substitutions because they don't
seems to work. To be used in launch.json's envFile.
|
|
I forgot to ask the original author to add this to the original MR
(#11243)
|
|
@jaos please review
|
|
See https://github.com/llvm/llvm-project/commit/a8f75d49
|
|
|
|
Generated objects can already be passed in the "objects" keyword argument
as long as you go through an extract_objects() indirection. Allow the
same even directly, since that is more intuitive than having to add them
to "sources".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Unless `meson.install_dependency_manifest()` is explicitly used, this
will cause a default implied one to be installed.
|
|
Hook this up to installed dependency manifests. This is often needed
above and beyond just an SPDX string -- e.g. many licenses have custom
copyright lines.
|
|
- change asabil.meson to vscode-meson
- remove unmaintained Meson-UI and Meson Cmake Wrapper
- remove note that Ecplise CDT support is experimental
|
|
|
|
|
|
|
|
The documentation for build_target(...) does not list file or str as
the possible types for the "objects" keyword argument, even though in
theory the argument is meant for prebuild object files that are part
of the sources.
Of course that is only the theory, because an ExtractedObjects object
is probably used a lot more than a file in the source tree. But
at least make the reference manual's typing information accurate.
|
|
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.
|
|
It's a clone of dependency() anyway.
|
|
We support these for a couple more things now.
|
|
Convert http to https in some links
|
|
Java module 1.0.0 updates
|
|
Remove the note about the unstable API of the Rust module, since it's no longer unstable as of Meson 1.0.0.
|
|
This follows the Meson naming scheme which typically leaves off a verb
like generate.
|
|
This API existed for 2 minor releases and was worthless for pretty much
every usecase.
|
|
Add a `dependencies` keyword argument to bindgen
|
|
|
|
devenv: various improvements
|
|
|
|
|
|
|
|
This is needed for cases where we need external C headers, which are
passed to clang.
|
|
Which we support for basically every other case, but not this one.
|
|
|
