When installing with 'meson install --quiet' I'd get the following output:
This file does not have an rpath.
This file does not have a runpath.
(It turns out that of the couple hundred of binaries that are installed,
this message was generated for /usr/lib/systemd/boot/efi/linuxx64.elf.stub.)
There doesn't seem to be any good reason for this output by default. But those
functions can still be used for debugging. Under a debugger, returning the
string is just as useful as printing it, but more flexible. So let's suppress
printing of anything by default, but keep the extractor functions.
The code was somewhat inconsistent wrt. to when .decode() was done. But it
seems that we'll get can expect a decodable text string in all cases, so
just call .decode() everywhere, because it's nicer to print decoded strings.
We could have an OptionOverrideProxy of an OptionOverrideProxy,
recursively. This fix is a minimal subset of the refactoring I did in
https://github.com/mesonbuild/meson/pull/9394. Instead of faking
UserOption we can just do a shallow copy of one and set a new value on
it.
Fixes: #9448
NamedTemporaryFile can't be opened by name on Windows.
For Windows the created temporary bat file is now closed before
passing to a subprocess, prevented from removal automatically upon
close and deleted explicitly upon finish.
The `except` line was missing its `as e` clause.
As a result, when erroring out, after not finding a compiler, Meson
gives an error ending:
```
File "C:\Users\Matthew\AppData\Roaming\Python\Python39\site-packages\mesonbuild\mesonlib\vsenv.py",
line 100, in setup_vsenv
mlog.warning('Failed to activate VS environment:', str(e))
```
Allow using the links method to test that the C++ driver (e.g. g++) can be used to
link C objects. One usecase is that the C compiler's libsanitizer might not be
compatible with the one included by the C++ driver.
This is theoretically backwards-incompatible, but it should be treated as a
bugfix in my opinion. There is no way in Meson to compile a .c file with the
C++ driver as part of a build target, therefore there would be no reason to
do something like meson.get_compiler(meson.get_compiler('cpp').links(files('main.c')).
Fixes: #7703
This simplifies things for us, as we don't have to have threading
imported for no other reason, and we can remove the
`an_unpicklable_object` from the Interpreter and mesonlib, since there
was only one user of this.
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
This is really, really, annoying. What we really want is (psuedocode):
```python
class SubValues(TypedDict[str, str], total=False):
@INPUT@: T.List[str]
@OUTPUT@: T.List[str]
```
Which would specifiy that `@INPUT@` and `@OUTPUT@` *may* be present and
if they are, then they are lists. There may be additional keys, which
have a single string as a value. Of course there is currently no way to
do that with typing, so we have to instead take a union type and then
use asserts to help the type checker unerstand this.
More info: https://github.com/python/mypy/issues/4617
get_compiler_for_source and classify_unity_sources are both wrong, in
that they expect to be given a seqence of strings, but they really
should take a `Sequence[str | File]`.
Additionally, they're using `CompilerType`, which we don't need anymore,
and should stop using, most methods for the Compiler are actually
defined in the base compiler class.
"meson setup" is resolving symlinks for the build directory in
validate_core_dirs. For consistency with it, do the same when
the build directory is passed via -C to devenv, dist, init, install
and test.
This ensures for example that the path to test dependencies is
computed correctly in "meson test".
Fixes: #8765
This commit introduces a new type of `HoldableObject`: The
`SecondLevelHolder`. The primary purpose of this class is
to handle cases where two (or more) `HoldableObject`s are
stored at the same time (with one default object). The
best (and currently only) example here is the `BothLibraries`
class.
When mutable items are stored in an lru cache, changing the returned
items changes the cached items as well. Therefore we want to ensure that
we're not mutating them. Using the ImmutableListProtocol allows mypy to
find mutations and reject them. This doesn't solve the problem of
mutable values inside the values, so you could have to do things like:
```python
ImmutableListProtocol[ImmutableListProtocol[str]]
```
or equally hacky. It can also be used for input types and acts a bit
like C's const:
```python
def foo(arg: ImmutableListProtocol[str]) -> T.List[str]:
arg[1] = 'foo' # works while running, but mypy errors
```
Tristan Partin
Dylan Baker
Zbigniew Jędrzejewski-Szmek
Eli Schwartz
Xavier Claessens
Gabor Kertesz
Matthew Brett
Christian Clauss
Paolo Bonzini
Will
Daniel Mensinger
Volker-Weissmann
Nellie Zhang
Jussi Pakkanen