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 06481666f4 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.
In commit 928078982c a good error message
about the directory not being a valid build directory, was replaced by a
worse message.
In commit abaa980436 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
Now cygwin seems to have completed a migration of the default python to
3.9, so that is where the devel package is at.
Back out the changes from commit 3304a38496
and update the pip/wheel packages as appropriate.
Do not recommend running the 'upload' target by default in order to
build the docs. That will fail with permission errors when trying to
push to a repo most people don't have commit access to, and if they did
have commit access it would be an even worse problem -- unpredictably
overwriting the main website without any guarantee it was generated from
the latest version of the docs!
Plus, it does not actually work. The first thing it does is spawn an
error message that required files do not exist, because the actual docs
were not, in fact, built. So they cannot be uploaded either.
The docs will build by default if you do not specify a non-default
target.
Fixes#9873
In https://github.com/python/cpython/pull/23858 the section header for
option flags was changed from "optional arguments" to "options" with the
rationale that they are not (necessarily) at all optional, while GNU
coreutils calls them options.
In fact, POSIX calls them options (-o) and option-arguments (-o val) and
operands ("positional arguments") so it is indeed a mess, but argparse
is not yet perfect.
Still, fix the documentation generator for now so that it is compatible
with python 3.10 as well.
Fixes traceback on building the docs with:
```
[1/4] Generating gen_docs with a custom command
FAILED: gen_docs.stamp
/home/eschwartz/git/meson/docs/../tools/regenerate_docs.py --output-dir /home/eschwartz/git/meson/docs/builddir --dummy-output-file gen_docs.stamp
Traceback (most recent call last):
File "/home/eschwartz/git/meson/docs/../tools/regenerate_docs.py", line 160, in <module>
regenerate_docs(output_dir=args.output_dir,
File "/home/eschwartz/git/meson/docs/../tools/regenerate_docs.py", line 146, in regenerate_docs
generate_hotdoc_includes(root_dir, output_dir)
File "/home/eschwartz/git/meson/docs/../tools/regenerate_docs.py", line 113, in generate_hotdoc_includes
cmd_data = get_commands_data(root_dir)
File "/home/eschwartz/git/meson/docs/../tools/regenerate_docs.py", line 106, in get_commands_data
cmd_data[cmd] = parse_cmd(cmd_output)
File "/home/eschwartz/git/meson/docs/../tools/regenerate_docs.py", line 65, in parse_cmd
assert arguments_start
AssertionError
```
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.
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.
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.
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.
Eli Schwartz
Dylan Baker
Will Toohey
Bilal Elmoussaoui
Arsen Arsenović
Tristan Partin
andy5995
Jussi Pakkanen
Matthias Klumpp