Suppressing all exceptions was hidding even syntax errors in compiler
source code. If a compiler cannot be found, a MesonException is raised,
we should only expect that type.
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)
```
#8259 induced a regression, causing Meson 0.57.0 and upward to
stop printing outputs of scripts added using `meson.add_*_script()`.
This makes _find_source_scripts() mark executables as verbose
in meson_exe.
If someone specifies a binary in a machine file, but the resulting
prog.found() is false because it doesn't actually exist on disk, then
the user was probably trying to disable finding that program. But
find_program() currently doesn't distinguish between a machine file
lookup returning a not-found program, and returning a dummy program
because there's no entry at all.
Explicitly check for a dummy program, rather than checking if the
program was found, before deciding whether to discard the lookup results
and continue trying other program lookup methods.
Include a frivolous error message too. We never see it, but if someone
reads the code and wonders why on *earth* there's a DSL function to
raise a RuntimeError, the message string will clue them in.
We have to allow through build.BuildTarget and build.ExtractedObjects,
which is what our previous level of checking did, even though they are
ignored. I've used FeatureDeprecated calls here, so that we have a clear
time of "this was officially deprecated in 1.1.0"
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.
T.Sequence is a questionable concept. The idea is to hammer out generic,
maximally forgiving APIs that operate on protocols, which is a fancy way
of saying "I don't care if you use tuples or lists". This is rarely
needed, actually, and in exchange for this fancy behavior you get free
bugs.
Specifically, `somestr` is of type `T.Sequence[str]`, and also
`somestr[0]` is another string of type you guessed it. It's ~~turtles~~
strings all the way down.
It's worth noting that trying to code for "protocols" is a broken
concept if the contents have semantic meaning, e.g. it operates on
"the install tags of this object" rather than "an iterable that supports
efficient element access".
The other way to use T.Sequence is "I don't like that T.List is
invariant, but also I don't like that T.Tuple makes you specify exact
ordering". This sort of works. In fact it probably does work as long as
you don't allow str in your sequences, which of course everyone allows
anyway.
Use of Sequence has cute side effects, such as actually passing lists
around, knowing that you are going to get a list and knowing that you
need to pass it on as a list, and then having to re-allocate as
`list(mylist)` "because the type annotations says it could be a str or
tuple".
Except it cannot be a str, because if it is then the application is
fatally flawed and logic errors occur to disastrous end user effects,
and the type annotations:
- do not enforce their promises of annotating types
- fail to live up to "minimal runtime penalties" due to all the `list()`
Shun this broken concept, by hardening the type annotations. As it turns
out, we do not actually need any of this covariance or protocol-ism for
a list of strings! The whole attempt was a slow, buggy waste of time.
When auto-generating e.g. a `clang-format` target, we first check to see
if the user has already defined one, and if so we don't bother creating
our own. We check for two things:
- if a ninja target already exists, skip
- if a run_target was defined, skip
The second check is *obviously* a duplicate of the first check. But the
first check never actually worked, because all_outputs was only
generated *after* generating all utility rules and actually writing out
the build.ninja file. The check itself compares against nothing, and
always evaluates to false no matter what.
Fix this by reordering the target creation logic so we track outputs
immediately, but only error about them later. Now, we no longer need to
special-case run_target at all, so we can drop that whole logic from
build.py and interpreter.py, and simplify the tracked state.
Fixes defining an `alias_target()` for a utility, which tried to
auto-generate another rule and errored out. Also fixes doing the same
thing with a `custom_target()` although I cannot imagine why anyone
would want to produce an output file named `clang-format` (unless clang
itself decided to migrate to Meson, which would be cool but feels
unlikely).
Since it's also used in the rust module, it should be in a common place.
Also rename from `TEST_KWARGS` to `TEST_KWS`, which is more in line with
the `*_KW` naming scheme used in the type_checking module.
This finds uses of deny-listed functions, which defaults to map and
filter. These functions should be replaced by comprehensions in
idiomatic python because:
1. comprehensions are more heavily optimized and are often faster
2. They avoid the need for lambdas in some cases, which make them
faster
3. you can do the equivalent in one statement rather than two, which
is faster
4. They're easier to read
5. if you need a concrete instance (ie, a list) then you don't have
to convert the iterator to a list afterwards
Regression test: libccpp has both C and C++ sources. The executable only
has C sources. It should still link using the C++ compiler. When using
both_libraries the static has no sources and thus no compilers,
resulting in the executable linking using the C compiler.
https://github.com/Netflix/vmaf/issues/1107
This was introduced in commit 3a6e2aeed9
as part of 0.50.0, but did not contain a FeatureNew. As a result, people
would use it without realizing that they broke support for versions of
Meson included in their minimum requirements.
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.
This introduce a new type of BuildTarget: CompileTarget. From ninja
backend POV it is the same thing as any other build target, except that
it skips the final link step. It could be used in the future for
transpilers too.
When using both_libraries(), or library() with default_library=both, we
remove all sources from args and kwargs when building the static
library, and replace them by the objects from the shared library. But
sources could also come from any InternalDependency, in which case we
currently build them twice (not efficient) and link both objects into
the static library.
It also means that when we needlessly build those source for the static
library, it miss order dependency on generated headers that we removed
from args/kwargs, which can cause build errors in the case the source
from static lib is compiled before the header in shared lib gets
generated.
This happened in GLib:
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2917.
cc.compiles(), and other compiler checks that use cc.compiles() under
the hood, do not use link args at all when doing the compile check, so
messages like this:
```
Checking if "have zlib" with dependency -lz compiles: YES
```
is very misleading. The compiler check command-line for that is:
```
cc [...]/testfile.c -o [...]/output.obj -c -D_FILE_OFFSET_BITS=64 -O0
```
Note the lack of linker args.
When _subproject_impl() is called the wrap file could not have been
downloaded form wrapdb yet, it is done when fetching the subproject.
Delay getting the variable name to when we actually need it, at that
point we are sure the wrap file has been downloaded.
Those classes are used by wrapper scripts and we should not have to
import the rest of mesonlib, build.py, and all their dependencies for
that.
This renames mesonlib/ directory to utils/ and add a mesonlib.py module
that imports everything from utils/ to not have to change `import
mesonlib` everywhere. It allows to import utils.core without importing
the rest of mesonlib.
In commit 47426f3663 we migrated to
typed_kwargs, but the validator accepted a list and checked to see if it
was a single Dependency object.
Fixes#10813
To differentiate it from the function parameter itself. Annotating a
function as
```
def func_foo(kwargs: kwargs.FooKwargs):
```
is confusing, both visually and to static linters.
This is supposed to expose all primitives together, but to do that we
need to actually "use" each variable in `__all__`, which we... didn't.
Sorry about that.
Strictly speaking code restructuring isn't needed, but making this PEP8
compliant results in indentation of the code that reduces the
readability. By moving the offending code on the outside of the method
call, the readability is maintained.
Xavier Claessens
Dylan Baker
Charles Brunet
Eli Schwartz
Paolo Bonzini
Marvin Scholz
Michael Champanis
David Robillard
Tristan Partin
Elliott Sales de Andrade
Nirbheek Chauhan
Thomas Li
Alf Henrik Sauge