| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Otherwise we're racing between the header generation and the source
generation.
|
|
Because we don't want to pass the Interpreter kwargs into the build
layer. This turned out to be a mega commit, as there's really on elegant
way to make this change in an incremental way. On the nice side, mypy
made this change super easy, as nearly all of the calls to
`CustomTarget` are fully type checked!
It also turns out that we're not handling install_tags in custom_target
correctly, since we're not converting the boolean values into Optional
values!
|
|
This is the right thing to do, using which is wrong.
|
|
This has been completely replaced by typed_kwargs now
|
|
|
|
|
|
The utility function that processes this for both 'variables' and
'uninstalled_variables' accepts a kwarg for the name of the argument,
but then hardcodes 'variables' in the warning message. This is
misleading.
|
|
It's not a MesonBug which needs to be reported, and the existing error
already adequately points out the problematic file.
It is impossible to get a PermissionError for files created by meson
itself, once the build directory has been created, anyway.
|
|
This was allows up to 0.61.0 (including with the initial type
annotations), but was accidentally broken by fixes for other bugs in
0.61.1.
Fixes: #9883
|
|
In commit 06481666f4e74ecef01e59351fc345ab0962d998 this warning got
moved from build.py to the interpreter. Unfortunately it got added to
the wrong function... it is supposed to be part of custom_target and
even mentions this as the feature_name.
Since then, build_always became a KwargInfo and has the deprecated-since
attribute baked into it. But it didn't have the additional message which
it really should have.
Add that message at the same time we remove it from vcs_tag.
|
|
Rather than pointlessly evolving it in the exactly one place which it is
used. It's not clear what the purpose for this was.
|
|
|
|
|
|
|
|
And one undefined T.cast name in a file that isn't yet mypy-ready
anyway.
|
|
|
|
Do not require users to convert it to a string first. This is a waste of
time and effort for exactly the same results.
|
|
|
|
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.
|
|
|
