We don't need a CMakeInterpreter until and unless we actually attempt to
use a cmake subproject via the cmake module.
Minus 10 files and 3679 lines of code imported at startup.
Simply store the module it is expected to be found in. That module then
appends to the packages dict, which guarantees mypy can verify that
it's got the right type -- there is no casting needed.
This lessens the amount of code imported at Meson startup by mapping
each dependency to a dictionary entry and using a programmable import to
dynamically return it.
Minus 16 files and 6399 lines of code imported at startup.
We expose detect.py as the mesonbuild.dependencies entrypoint and import
it upfront everywhere. But unless the `dependency()` function is
actually invoked, we don't need *any* of the private implementations for
this.
Avoid doing so until, as part of actual dependency lookup, we attempt
that specific dependency method. This avoids importing big modules if
`method:` is specified, and in most cases hopefully pkg-config works and
we can avoid importing the cmake implementation particularly.
Actually avoiding most of these imports requires more refactoring. But
even so, the garden path no longer needs to import the dub dependency
impl.
We need to extend the candidates the same way per method, but we handle
each method twice: once in explicit method checks, and once for auto. We
can just handle auto as a special list of methods, though.
We can check something's subtype using properties, without importing the
module up front and doing isinstance checks on specific subclasses of
the interface -- or worse, solving cyclic imports by doing the import
inside the function. ;)
msetup.py doesn't need to know the gory details of PkgConfigDependency,
or directly import it at program startup. It's also slightly wasteful to
generate a devenv for the -uninstalled directory when a project doesn't
even, in the end, use the pkgconfig module anyway.
And avoid passing variables around several functions just to finally get
where they need to be. These function signatures were kind of ugly...
Also the use of dataclasses makes a big chunk of this file now typed
properly.
I noticed when building a project that uses a proc macro that Meson
passed -C prefer-dynamic for the executable, and not the proc macro,
while cargo passed -C prefer-dynamic for the proc macro, but not for
the executable. Meson's behavior broke setting -C panic=abort on the
executable.
As far as we can tell, because we explicitly pass each library path to
rustc, the only thing -C prefer-dynamic affects in Meson is how the
standard libraries are linked. Generally, one does not want the
standard libraries to be dynamically linked, because if the Rust
compiler is ever updated, anything linked against the old standard
libraries will likely break, due to the lack of a stable Rust ABI.
Therefore, I've reorganised Meson's behavior around the principle that
the standard libraries should only be dynamically linked when Rust
dynamic linking has already been opted into in some other way. The
details of how this manifests are now explained in the documentation.
This function has a pretty unique name, and a simple grep shows that it
is only ever called as:
```
add_comment(PbxComment('...........'))
```
It doesn't need to include logic such as handling str. Moreover it looks
like that handling was broken anyway... it handled the case where
comment is type str, by constructing a new PbxComment(str) instead of
PbxComment(comment), a condition that cannot ever be valid (and crashed
due to other assertions).
Fixes:
mesonbuild/backend/xcodebackend.py:148:42: error: Argument 1 to "PbxComment" has incompatible type "type[str]"; expected "str" [arg-type]
We are going to truncate it down below with int() anyway, no need to
carry extra precision. And mypy complains if the type changes between
float and int.
The new splitlines method on str is intended to replace usage of
fs.read('whatever').strip().split('\n').
The problem with the .strip().split() approach is that it doesn't have a
way to represent empty lists (an empty string becomes a list with one
empty string, not an empty list), and it doesn't handle Windows-style
line endings.
an int only accepts operations on other ints, just like other primitive
types only accept operations on values of the same type.
But due to using isinstance in baseobjects "operator_call", an int
primitive allowed operations on a bool, even though reversing the
operator and having a bool perform operations on an int, would fail with
a type error.
Really, we should fail with a type error in both directions. But for
stability reasons, make this a loud warning and break --fatal-meson-warnings
builds.
This is useful for totally terrible stuff that we really dislike, but
for some reason we are afraid to just use `mlog.deprecation()` and
unconditionally tell people so.
Apparently this is because it is totally absolutely vital that, when
telling people something is so broken they should never ever ever use it
no matter what, ever... we can't actually tell them that unless they
bump the minimum version of Meson, because that's our standard way of
introducing a **version number** to tell them when we first started
warning about this.
Sigh. We really want to warn people if they are doing totally broken
stuff no matter what version of Meson they support, because it's not
like fixing the thing that never worked is going to suddenly break old
versions of meson.
So. Here's some new functionality that always warns you, but also tells
you when we started warning.
The version output scraping for identifying strings checked for "IFORT"
in parentheses after the executable name, which is probably a mistake by
Intel. Current versions of ifx have "IFX" in parentheses there.
Detect both.
Fixes#11873
When a project targets a dev version of Meson (e.g. 1.1.99) for
experimenting, this allows to use:
project(..., meson_version: '>=1.2.0')
It avoids getting warnings when using FeatureNew for features introduced
in 1.2.0.
Specifically, when those files can be created by a build rule with one
version of meson.build, and created as e.g. a shared_library alias
symlink in another version of meson.build, the cleandead command will
delete important files just because they don't happen to be created by
ninja itself.
Work around this by making a dummy rule that exists solely to insert the
files into the build graph to trick ninja into not deleting them.
Closes#11861
Eli Schwartz
Xavier Claessens
Alyssa Ross
Dylan Baker
Martin Dørum
Jussi Pakkanen
L. E. Segovia
Karol Herbst