This gives us a simpler way to annotate things returning an option
value, and gives us an easy single place to change that will affect
everywhere if the option value types are changed.
On Windows, if you accidently add a space at the end of a file name, like
`files('myfile.txt ')`, the file is not reported as missing, because of
the normalization performed by the OS. However, ninja will reference it
with the trailing space, and will fail because the file does not exist.
See https://github.com/python/cpython/issues/115104 for reference.
It's not especially explanatory to say:
```
meson.build:357:34: ERROR: Automatic wrap-based subproject downloading is disabled
```
But if we instead say this:
```
ERROR: Subproject libsamplerate is buildable: NO
meson.build:357:34: ERROR: Automatic wrap-based subproject downloading is disabled
```
It becomes a lot clearer to casual inspection, why it failed. And it
matches the way we otherwise report errors for an unbuildable subproject
(configure errors).
Bug: https://github.com/jacktrip/jacktrip/issues/1380
It catches the exception message itself, but for multi-line exceptions
it may be worth print an error() as well as raising, to communicate
multiple bits of information.
When using the VS backend, this means that we get an actual `ERROR: ...`
printed during a successful run, which then breaks msbuild as msbuild
parses stdout of successful commands, regexes them for the word "error:"
and interprets that as... an error. So a meson project tests example
that uses testcase expect_error() and then successfully configures and
builds, fails to successfully `meson --internal regenerate`.
Sneak around this by doing our own pattern replace to evade msbuild.
There is probably a way to tell msbuild to stop doing this, but that
would require me understanding the vs backend well enough to patch the
xml it generates. No thanks...
Except for set_variable(), the variable name is certainly an identifier because it
comes from the parser; thus, the check is unnecessary. Move the regular expression
match to func_set_variable().
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
in `func_install_data`, `rename` parameter is `ContainerTypeInfo(list, str)`
in `module/python.py`, rename is `None`
`rename` is stored in `build.Data` object under the type `T.List[str]`
The following log output:
Checking if "strnstr() available" : links: NO
now becomes:
Checking if "strnstr() available" links: NO
This is more consistent with the compiles() method.
It's not actually useful, we can just add the root meson.build file to
the depfiles when we translate the meson.build into ast. If there's a
provided ast then we don't go down that path anyway.
This was only used in a couple of places, and requires extra tracking to
ensure it is correct, while we already have `current_node.lineno`, which
is always accurate and up to date.
I have also fixed a potential strict-null issue by using a sentinel node
for `current_node`
In the case the main project has a .wrap file for a cargo subproject,
that subproject's Cargo.lock must be loaded before we can recursively
fetch all its dependencies.
Introduce a global Cargo interpreter state that keeps track of enabled
features on each crate.
Before generating AST of a Cargo subproject, it downloads every
sub-subproject and resolves the set of features enabled on each of them
recursively. When it later generates AST for one its dependencies, its
set of features and dependencies is already determined.
When we're using the output of configure_file() with
override_find_program(), we weren't storing the version anywhere, so
get_version() was trying to run the script during setup.
This is usually fine, except in cases where the configure_file()
script actually has to import a library built as part of the project,
and fails to run.
For built executables, we simply use the project version, and we
now do the same here too.
Otherwise internal dependencies have auto-generated names that are not
human readable. Instead, use the name that the dependency overrides. For
example:
```meson
meson.override_dependency('zlib', declare_dependency())
dep_zlib = dependency('zlib')
assert(dep_zlib.name() == 'zlib')
```
Fixes: #12967
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
These errors can make reading comments and documentation
unnecessarily confusing for users and contributors who
do not speak English as their first language.
This commit harmonizes the handling of `d_import_dirs` and
`include_directories`. The treatment of `d_import_dirs` was also
different depending on the context: in `declare_dependency` it was
treated like the `include_directories`, but in `build_target` et al,
it had special treatment. With this commit, they are all treated
by the same function. The documentation has been updated to
reflect this.
Fixes#12742
When projects do not specify a minimum meson version, we used to avoid
giving them the benefit of the Feature checks framework. Instead:
- warn for features that were added after the most recent semver bump,
since they aren't portable to the range of versions people might use
these days
- warn for features that were deprecated before the upcoming semver
bump, i.e. all deprecated features, since they aren't portable to
upcoming semver-compatible versions people might be imminently upgrading
to
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>
Jussi Pakkanen
Dylan Baker
Charles Brunet
Eli Schwartz
Marco Rebhan
Paolo Bonzini
Pierre Lamot
meator
Xavier Claessens
Xavier Claessens
Andoni Morales Alastruey
Nirbheek Chauhan
unknown
Andrew McNulty
spaette
Eli Schwartz
David Gibson