This convertor was initially implemented doing all the things the TODO
says it doesn't yet do. The freestanding interpreter function is what
doesn't do this.
To take good decisions we'll need to know if we are a Rust library which
is only know after processing source files and compilers.
Note that is it not the final list of compilers, some can be added in
process_compilers_late(), but those are compilers for which we don't
have source files any way.
This allows changing the crate name with which a library ends up being
available inside the Rust code, similar to cargo's dependency renaming
feature or `extern crate foo as bar` inside Rust code.
We need to remember its value when reconfiguring, but the Build object
is not reused, only coredata is.
This also makes CLI more consistent by allowing `-Dvsenv=true` syntax.
Fixes: #11309
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
It can only be used for projects that don't have any rules at all, i.e.
they are purely using Meson to:
- configure files
- run (script?) tests
- install files that exist by the end of the setup stage
This can be useful e.g. for Meson itself, a pure python project.
In commit 97a72a1c53 we started to allow
cmakedefine with 3 tokens, as cmake expects (unlike mesondefine). This
would silently start working even if the declared minimum version was
older than 0.54.1
In commit c2a55bfe43 multiple bugs were
fixed, but a FeatureNew was only added for the one that was mentioned in
the commit message.
Make sure to warn users about the reliability of the one that wasn't
mentioned, too.
We add a unique ID to each rule we create, to work around the use of
an entire build target with private directory named "preprocess" per use
of the preprocess() method.
But this ID doesn't need to increment every time it is used anywhere --
only when it is used in the same subdir as a previous time. That is the
only case where it could conflict.
By making the increment counter per-subdir, we can avoid potential
frivolous rebuilds when a new preprocess() is added in a different
directory, the build is reconfigured, and all uses in the entire project
tree suddenly get new output paths even if they haven't changed.
We need to know the project minimum version before evaluating the rest
of the function. There's three basic approaches:
- try to set it inside KwargInfo
- just run a minimal version of func_project for this, then load
everything after
- drop down to the AST and set it before anything else
In order to handle FeatureNew emitted by a FunctionNode evaluated
before project() due to being inlined, such as `version: run_command()`,
only option 3 suffices, the rest all happen way too late. Since we have
just added AST handling support for erroring out, we can do that to set
the version as well.
If the meson.build file is sufficiently "broken", even attempting to lex
and parse it will totally fail, and we error out without getting the
opportunity to evalaute the project() function. This can fairly easily
happen if we add new grammar to the syntax, which old versions of meson
cannot understand. Setting a minimum meson_version doesn't help, because
people with a too-old version of meson get parser errors instead of
advice about upgrading meson.
Examples of this include adding dict support to meson.
There are two general approaches to solving this issue, one of which
projects are empowered to do:
- refactor the project to place too-new syntax in a subdir() loaded
build file, so the root file can be interpreted
- teach meson to catch errors in building the initial AST, and just load
enough of the AST to check for meson_version advice
This implements the latter, allowing to future-proof the build
grammar.
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
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
Eli Schwartz
Xavier Claessens
Volker Weißmann
Sebastian Dröge
Charles Brunet
Josh Soref
Dylan Baker
Andres Freund
L. E. Segovia
Paolo Bonzini
Marvin Scholz
Michael Champanis
David Robillard