This setting is for things like `ccache`, but if Meson treats zig that
way, then it will expand the second argument to become:
```
/usr/bin/zig /usr/lib64/ccache/cc
```
in CMake and `/usr/lib64/ccache/cc` is _not_ an argument to `zig`.
If you run
```
$ CC='zig cc' CXX='zig c++' ./meson.py setup 'test cases/cmake/1 basic' build
```
then CMake will fail to compile a "simple test program" and setup
fails.
We've documented these lists as being `List[Path]`, but then we have the
potential to insert a None into them via the `rel_path()` function,
which can return `None` in some cases. Currently we fix some (but not
all) of these later, but we should actually remove them from the list
before we assign, so that it's actually a `List[Path]` at all times.
While we're here I've simplified the logic a bit.
Closes: #13551
It's always true because the func is always a real, truthy func object.
In the cmake case, the logic seems to be broken because if a path is not
a file, then that includes the case where it does not exist. It also
clearly meant "or" instead of "and".
What actually ended up happening was that this check never fired at all.
Because "if not func and not ..." would always fail, because "not func"
is always false. Maybe we don't need this logic at all...
CMake has two target properties, LINK_OPTIONS and INTERFACE_LINK_OPTIONS.
The former is for link flags that apply only to the target (PRIVATE).
The latter is used for link flags that propagate to dependents (PUBLIC
or INTERFACE). Meson currently propagates all flags, PUBLIC and PRIVATE,
as part of the generated dependency() which causes problems when some of
the private flags are highly disruptive, e.g. `-Wl,--version-script`.
Tease apart the two kinds of link flags and, for non-static libraries,
only propagate the PUBLIC/INTERFACE flags and not the PRIVATE ones.
* Explicitly look for 'OpenAL' with method: 'cmake'
This test was added for testing cmake depenencies,
so no other method must be accepted here, and
the spelling must match FindOpenAL.cmake.
* Resolve frameworks in IMPORTED_LOCATION
The IMPORTED_LOCATION property of CMake targets may contain macOS
framework paths. These must be processed into flags. By putting the
values in the list of targets, they will be processed as if they
appeared in INTERFACE_LINK_LIBRARIES.
GENERATED files can be used as dependencies for other targets, so it's
misguided (at best) to filter them with a blunt whitelist.
However, there does exist an extension that needs to be skipped: on Windows +
MSVC, CMake will by default try to generate a Visual Studio project, and
there dependencies with no inputs are instead tied to a dummy .rule
input file which is created by the generation step. The fileapi will
still report those, so it will cause Meson to bail out when it realises
there's no such file in the build tree.
Fixes#11607
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
This properly sets the project version in projects meson generates from
cmake projects. This allows dependency fallbacks to properly check the
version constraints in dependency calls when falling back to a cmake
subproject. Before this would fail, because the project version was
undefined.
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
It's shorter and more descriptive. Although we always enforce the same
rules either way, a unified decorator is one less line of code for each
location, and also tells you how many "too few" arguments you *did*
pass.
Which adds the `use-set-for-membership` check. It's generally faster in
python to use a set with the `in` keyword, because it's a hash check
instead of a linear walk, this is especially true with strings, where
it's actually O(n^2), one loop over the container, and an inner loop of
the strings (as string comparison works by checking that `a[n] == b[n]`,
in a loop).
Also, I'm tired of complaining about this in reviews, let the tools do
it for me :)
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
Add a MissingCompiler class returned by compiler detecting methods
intead of None - accessing such an object raises a DependencyException
Fixes#10586
Co-authored-by: duckflyer <duckflyer@gmail.com>
flake8 6 upgrades to pyflakes 3, and in turn this means that support for
parsing `# type: ` style annotations has been removed.
https://github.com/PyCQA/pyflakes/pull/684
This caused one file to fail linting, because it had a typing import
which was only used by a type comment.
```
mesonbuild/cmake/interpreter.py:55:5: F401 '.common.CMakeConfiguration' imported but unused
```
Updating it to actual annotations allows pyflakes to detect its usage
again, and flake8 passes. Do the whole file while we are here.
This catches some optimization problems, mostly in the use of `all()`
and `any()`. Basically writing `any([x == 5 for x in f])` vs `any(x == 5
for x in f)` reduces the performance because the entire concrete list
must first be created, then iterated over, while in the second f is
iterated and checked element by element.
Frank Richter
scivision
Elliott Sales de Andrade
Stephan Lachnit
Dylan Baker
spaette
Jonathan Schleifer
Eli Schwartz
Jussi Pakkanen
Jonathon Anderson
Kai Pastor
Jouke Witteveen
L. E. Segovia
Nicolas Werner
Tristan Partin
Xavier Claessens
Charles Brunet
Eli Schwartz
kiwixz
Josh Soref
SmallWood-D