| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
The word "cannot" expresses inability to do something whereas "can not"
expresses the ability to refrain from doing something.
|
|
|
|
We will still try to load `meson_options.txt` if `meson.options` doesn't
exist. Because there are some advantages to using `meson.options` even
with older versions of meson (such as better text editor handling)
we will not warn about the existence of a `meson.options` file if a
`meson_options.txt` file or symlink also exists.
The name `meson.options` was picked instead of alternative proposals,
such as `meson_options.build` for a couple of reasons:
1. meson.options is shorter
2. While the syntax is the same, only the `option()` function may be
called in meson.options, while, it may not be called in meson.build
3. While the two files share a syntax and elementary types (strings,
arrays, etc), they have different purposes: `meson.build` declares
build targets, `meson.options` declares options. This is similar to
the difference between C's `.c` and `.h` extensions.
As an implementation detail `Interpreter.option_file` has been removed,
as it is used exactly once, in the `project()` call to read the options,
and we can just calculate it there and not store it.
Fixes: #11176
|
|
As discussed in issue #8037, using `c_args` in `project()` leads to
`CFLAGS` not being respected, which is a common mistake. Document this
and suggest using `add_project_arguments()` instead.
Signed-off-by: John Levon <levon@movementarian.org>
|
|
s/Accecpts/Accepts/
Signed-off-by: John Levon <levon@movementarian.org>
|
|
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
|
|
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.
|
|
|
|
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.
|
|
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.
|
|
|
|
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
|
|
|
|
This is based on searching for `@FeatureNew*` decorators.
There is also one correction to a version in a decorators;
`build_by_default` was added in #1303, which is 0.38.0, not 0.40.0.
|
|
Add cc.preprocess() method
|
|
|
|
|
|
|
|
|
|
It's mentioned in the error message if you try to do it, that you cannot
use `..`, but it is probably useful to mention this in the online docs
too.
|
|
custom_target allows selective installation if it outputs more than one
file. Mention this explicitly in install.
Additionally, fix the types for install_dir.
see: https://github.com/mesonbuild/meson/issues/505
|
|
Primarily interesting to me because it is then available for the python
module's install_sources method.
Based on the new feature in install_headers.
|
|
Dlang uses both integer version "levels" and arbitrary string
identifiers, and we support both, but don't mention it in the docs.
Also update a test case to pass one via declare_dependency. We already
test this kwarg for build_target.
|
|
The type information is clearly wrong as it disagrees with the
description w.r.t. generated headers.
We also rely on it accepting custom targets for the obvious reason that
we accept it in a build target too! In fact, we rely on this in the
testsuite too.
|
|
|
|
The `install_headers` function now has an optional argument
`preserve_path` that allows installing multi-directory
headerfile structures that live alongside sourcecode with a
single command.
For example, the headerfile structure
headers = [
'one.h',
'two.h',
'alpha/one.h',
'alpha/two.h',
'alpha/three.h'
'beta/one.h'
]
can now be passed to `install_headers(headers, subdir: 'mylib', preserve_path: true)`
and the resulting directory tree will look like
{prefix}
└── include
└── mylib
├── alpha
│ ├── one.h
│ ├── two.h
│ └── three.h
├── beta
│ └── one.h
├── one.h
└── two.h
Fixes #3371
|
|
This function can be used to add fundamental dependencies such as glib
to all build products in one fell swoop. This can be useful whenever,
due to a project's coding conventions, it is not really possible to
compile any source file without including the dependency.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
In the original RefMan 2.0 implementation, the types for this were
filled in as `str | file`, but the code only ever accepted the former.
Fix the documentation so that it aligns with reality.
Fixes #10338
|
|
This makes vcs_tag behave like other commands so it accepts not only
string and file arguments, but also exe, custom_tgt, and
external_program.
|
|
|
|
|
|
|
|
It isn't possible to have one target depend on a run_target, because
those produce no outputs and are always out of date. But the docs didn't
specify which types of target are valid here.
Correct the docs to align with the implementation.
Fixes #10198
|
|
This was implemented in commit 280346da3ac5904ec097afe89ef45ad34bd4a173
but never properly documented (it predated the version-controlled docs).
|
|
We have always accepted an int here as an alternative to a string, but
the initial documentation thought it was only a string.
|
|
Adds a new debug() function that can be used in the meson.build to
log messages to the meson-log.txt that will not be printed to stdout
when configuring the project.
|
|
Previously subprojects inherited languages already added by main
project, or any previous subproject. This change to have a list of
compilers per interpreters, which means that if a subproject does not
add 'c' language it won't be able to compile .c files any more, even if
main project added the 'c' language.
This delays processing list of compilers until the interpreter adds the
BuildTarget into its list of targets. That way the interpreter can add
missing languages instead of duplicating that logic into BuildTarget for
the cython case.
|
