This was a nice idea in theory, but in practice it had various problems:
- On the only platform where ldconfig is expected to be run, it is
really slow, even when the user uses a non-default prefix and ldconfig
doesn't even have permission to run, nor can do anything useful due to
ld.so.conf state
- On FreeBSD, it bricked the system: #9592
- On cross builds, it should not be used and broke installing, because
ldconfig may not be runnable without binfmt + qemu: #9707
- it prints weird and confusing errors in the common "custom prefix"
layout: #9241
Some of these problems can be or have been fixed. But it's a constant
source of footguns and complaints and for something that was originally
supposed to be just "it's the right thing to do anyway, so just do it
automatically" it is entirely too risky.
Ultimately I do not think there is justification for keeping this
feature in since it doesn't actually make everyone happy. Better for
users to decide whether they need this themselves.
This is anyways the case for cmake and autotools and generally any other
build system, so it should not be too intimidating...
Fixes#9721
Store in TestSerialisation whether a particular test must always be logged
verbosely. This is particularly useful for long-running tests or when a
single Meson test() is wrapping an external test harness. In this case,
TAP can be used by the external harness and Meson will log each subtest as
it runs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Basically the last thing we did during target processing was to generate
shlib symlinks for e.g. libfoo.so -> libfoo.so.1.
In some cases we would dispatch to another function and return early,
though, which meant we never got far enough to generate the symlinks.
This then led to breakage when people tried to compile against libfoo.so
This surely breaks -uninstalled.pc usage, and also caused problems in
https://github.com/rust-lang/rust/pull/90260
Regressed in commit bfb12222c3.
This needs to iterate over all methods, process them, and add them to a
list. Instead, it deleted all methods, processed all remaining methods,
and appended them to the in-use iterator.
Use a second list, instead.
Fixes#9922
unittests/rewritetests.py:19: DeprecationWarning: The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives
from distutils.dir_util import copy_tree
For example:
```
meson builddir \
--native-file vs2019-paths.txt \
--native-file vs2019-win-x64.txt \
--cross-file vs2019-paths.txt \
--cross-file vs2019-win-arm64.txt
```
This was causing the error:
> ERROR: Multiple producers for Ninja target "/path/to/vs2019-paths.txt". Please rename your targets.
Fix it by using a set() when generating the list of regen files, and
add a test for it too.
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!
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.
Eli Schwartz
Guillaume Quenneville
Andrew Krasavin
Andrea Pappacoda
Paolo Bonzini
Xavier Claessens
Stone Tickle
Nirbheek Chauhan
Dylan Baker
Will Toohey
Bilal Elmoussaoui
Arsen Arsenović
Tristan Partin
andy5995