| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
retain is a relatively young attribute which has proven itself useful
for working with --gc-sections -z start-stop-gc.
|
|
In commit 928078982c8643bffd95a8da06a1b4494fe87e2b a good error message
about the directory not being a valid build directory, was replaced by a
worse message.
In commit abaa980436f53100041bd5535589bb1c42019bd6 the error message was
replaced by a traceback when trying to load the coredata before checking
if it was a build directory.
Revert back to using the helper function with the good error message.
Reorganize code so that we check basic things first, and do less work
before detecting errors.
Fixes #9584
|
|
Due to the support for specifying version as files('VERSION'), we need
to internally accept an array, since that is what files() returns.
Before that, we didn't accept arrays, and after that, we don't intend to
accept generic arrays, only arrays as a side effect of files(). So
tighten the typechecking to ensure that that is what we actually get.
|
|
Python inherited a really bad design from C, booleans happen to be ints.
Which is awful, but it's true.
Fixes: #9858
|
|
|
|
|
|
It was not added in 0.61.0 as that was already released.
|
|
i18n: Add support for joining XML localization via itstool
|
|
|
|
If the found python returns None from sysconfig.get_config_var('LIBPC')
then we cannot (and don't) set PKG_CONFIG_LIBDIR from it. In fact, we
can virtually guarantee we won't find a PkgConfigDependency either,
because any python that doesn't have a LIBPC is presumably not installed
to the system pkg-config directory (maybe it's an isolated relocatable
install, maybe it just doesn't have pkg-config support for who knows
what reason).
Trying to find one anyway using pkg-config's builtin search paths can
unexpectedly succeed, though, by finding a completely unrelated python
installation installed to a system location, which isn't the one we are
actually building for.
Instead, return early so that we use the system dependency class
fallback.
While we are at it, add back the debug messages from #3989 which got
removed.
|
|
Since they don't use the instance or class state, they should be static
methods.
|
|
Which is one incorrect type annotation, and a couple of instances of
concatenating lists of unlike types. List being invariant is super
annoying.
|
|
|
|
|
|
|
|
_get_gir_target_deps
The typing issues with these are tightly intertwined, so it didn't
really make sense to solve them independently
|
|
These don't return `Target`, they return `BuildTarget | CustomTarget |
CustomTargetIndex`
|
|
|
|
|
|
Which is pretty much necessary to make anything involving unions of
lists work
|
|
This is better as it avoids building unnecessary lists, and two fixes
the typing issue from concatenating lists of different types.
|
|
gnome points out that CustomTargets can be linked with, so we should
allow that.
|
|
This is hard to fix, and it's really doing something bad anyway. But we
know it's right, so just tell mypy to not worry about it.
|
|
_gather_typelib_includes_and_update_depends
There is the problem of the annotations themselves, then there is
the problem with depends being mutated. The mutation side effect is a
problem in itself, but there's also the problem that we really want to
use Sequence, which isn't mutable.
|
|
|
|
RunTargets and AliasTargets may depend on RunTargets, so annotate them
that way. The Gnome module relies on this internally.
|
|
This is currently allowed, and is used in at least a few projects. It
was not intended to work or documented, but it does and since it is in
use a full deprecation period must be used. A warning has also been
added for values < 0, which have surprising behavior.
|
|
It's no longer required because we don't allow arrays as fallbacks
anymore.
|
|
Which do nothing, and shouldn't be allowed.
|
|
This is much cleaner, and more in line with the way we handle
interpreter objects in modern meson practice
|
|
It really belongs here, not in the interpreter
|
|
|
|
This removes the ability to use ConfigurationData as a dict, but
restricting the inputs to `str | int | bool`. This may be a little too
soon for this, and we may want to wait on that part, it's only bee 8
months since we started warning about this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is a layering violation, we're relying on the way the interpreter
handles keyword arguments. Instead, pass them as free variables,
destructuring in the interpreter
|
|
|
|
|
|
|
|
|
|
|
|
We currently use a mixture of dependency, Dependency, and dep
|
|
Implementation modeled after mesonlib.windows_proof_rmtree().
Implements the other half of #9688
|
|
This code path is only called on initial download of a subproject, but
if we raise an error and abort while downloading/applying a patch
overlay we still have the upstream sources extracted... which appears to
be a subproject, then turns out to be broken due to missing meson.build
Partially implements #9688
|
|
The tests and the unittests both unconditionally call setup_vsenv()
because all tests are run using the backend commands directly: ninja,
msbuild, etc.
There's no way to undo this vs env setup, so the only way to test that
--vsenv works is by:
1. Removing all paths in PATH that provide ninja
2. Changing setup_vsenv(force=True) to forcibly set-up a new vsenv
when MESON_FORCE_VSENV_FOR_UNITTEST is set
3. Mock-patching build_command, test_command, install_command to use
`meson` instead of `ninja`
4. Asserting that 'Activating VS' is in the output for all commands
5. Ensure that compilation works because ninja is picked up from the
vs env.
I manually checked that this test actually does fail when the previous
commit is reverted.
|
