The first version of setuptools to properly support pyproject.toml was 42 (40-41 were buggy). It is also necessary to specify `build-backend = "setuptools.build_meta"`, otherwise you get the (horrible) default `build-backend = "setuptools.build_meta:__legacy__"`.
This adds 3.10 (didn't check to see if it was tested on 3.10, that should be done, but I'm using it on 3.10).
setup_requires is deprecated and should be producing warnings on modern setuptools, and never worked for setuptools anyway - setuptools can't update itself, and setuptools is what is reading this anyway!
This will really help with pipx run, as `pipx run meson[ninja]` will now work on any system with pipx 0.17 or newer, no dependencies required. This now includes GitHub Actions, which just updated to pipx 1.0.0. Pipx run lets you use recent (always <1 week old) versions of anything on PyPI.
This has never worked for built/found programs, only for script files.
In commit 2fabd4c7dc scripts learned an
attribute stating which subproject they came from. In commit
3990754bf5 dist scripts learned to run
even from a subproject, and relied on that attribute to know when, in
fact, they came from a subproject.
Unfortunately the original attribute was only set in one half of an
if/else, and the other half returned early with only part of the work
done.
Fixes#9964
In commit 0deab2ee9e we added the ability
to pass a declare_dependency() to any compiler method that accepts
"dependencies", but we never marked the version it is available since.
Fixes#9957
The array of licenses is not clear, where and SPDX expression using AND
and OR is very clear, take for example this: `['Apache', 'GPLv2']`. What
does that mean? Any Apache license you like and GPLv2? Using a valid
SPDX license identifier however makes it extremely clear what is meant:
`'Apache-2.0 OR GPL-2.0-only'`. It is very clear that you mean, "this is
Apache 2.0, however, you can use as GPL-2.0 for the purpose of linking
it into your GPL-2.0 project".
For static library crates that depend on other internal static library
crates, all link_with targets get promoted to link_whole targets. Due to
a bug, only link_with targets are considered when generating a Rust
target for the ninja backend. This made it impossible to link a Rust
static library with another internal Rust static library.
This change fixes that issue by chaining link_whole_targets with
link_targets, just like many other languages within the ninja backend.
This is gross and looks terrible, but I'm not entirely sure how else to
do this.
And cmake is an inferior methodology, TBH, since it is effectively the
same as our own builtins. However, cmake also handles some bizarre
Windows library names whose provenance I'm not entirely sure of, in
addition to implementing the usual excessive pattern of hardcoded search
directories. So, this may be useful, at least on Windows, as a fallback.
(I am not really interested in offering feature compatibility with cmake
for a bunch of bizarre naming schemes that ***aren't the official cmake
library names***, so if cmake allows that and people really feel they
need it, all the more power to them.)
Nevertheless, I believe if it got found via our system dependency class,
it will always provide results which are just as functional as cmake.
cmake can only find openssl installations that would otherwise be
missed.
This also avoids the case where users did
```
dependency('OpenSSL', modules: [...], method: 'cmake')
```
and expected it to work, since our builtin dependency supersedes the
divergent case and didn't previously allow the cmake method. I don't
know why they would do such a thing, but who knows... it is always
possible.
On some platforms, this is provided by the base system, which
nevertheless refrains from providing the .pc files that go along with
it. As a result, it's impossible to sensibly find these dependencies.
I'm looking at you, FreeBSD...
Upstream tracking bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257659
This is also a problem on macOS, but that's unfixable (and I believe
they provide some truly ancient and out-of-support version anyway) and
you probably want to use the homebrew OpenSSL. Still, meson can now
detect these old versions and even set their version number.
CMake's write_basic_package_version_file has supported since version 3.14
an ARCH_INDEPENDENT option that makes it skip its architecture check in
the Version file.
With this patch Meson now supports it as well, and the change is also
compatible with older CMake versions, as they will simply ignore the
option.
This also slightly changes the contents of the generated Version file
when arch_independent is not set: previously, the if() needed to skip
the arch check was always filled with an empty string, while CMake puts
"FALSE" (or "TRUE") in it. Now, that if() will always be filled with
either "False" or "True", better matching CMake's behaviour.
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.
Henry Schreiner
Eli Schwartz
Tobias Pankrath
Jussi Pakkanen
Marc-André Lureau
Ole André Vadla Ravnås
Dylan Baker
Daniel Mensinger
Nazar Mokrynskyi
Zach Reizner
William Toohey
Andrea Pappacoda
Guillaume Quenneville
Andrew Krasavin
Paolo Bonzini
Xavier Claessens
Stone Tickle
Nirbheek Chauhan