| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
This has never worked for built/found programs, only for script files.
In commit 2fabd4c7dc22373e99fc63823d80083ad30704b8 scripts learned an
attribute stating which subproject they came from. In commit
3990754bf55727ef5593769b48f0a03c6b7a3671 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 0deab2ee9efc2ffe9e43f2787611e34656e6a304 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
|
|
|
|
|
|
It may be None. This was encountered with radare's build system on
Windows, where symbolextractor.py crashes without any output displayed.
|
|
|
|
|
|
|
|
New keyword argument `verbose` for tests and benchmarks
|
|
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
|
|
|
|
This should address some concerns outlined in
https://github.com/yhirose/cpp-httplib/pull/1182
|
|
Add a new keyword argument to test() and benchmark(), completing the
implementation of the feature.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
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
|
|
|
|
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.
|
|
This should have been removed when typed_kwargs was added
|
|
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
|
|
|
