| Age | Commit message (Collapse) | Author |
|---|
|
We already test for custom_targets and configure_file, but we should
test a generator too
|
|
This splits the scanner into two discrete steps, one that scans the
source files, and one that that reads in the dependency information and
produces a dyndep.
The scanner uses the JSON format from
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1689r5.html,
which is the same format the MSVC and Clang use for C++ modules
scanning. This will allow us to more easily move to using MSVC and
clang-scan-deps when possible.
As an added bonus, this correctly tracks dependencies across TU and
Target boundaries, unlike the previous implementation, which assumed
that if it couldn't find a provider that everything was good, but could
run into issues. Because of that limitation Fortran code had to fully
depend on all of it's dependencies, transitive or not. Now, when using
the dep scanner, we can remove that restriction, allowing more
parallelism.
|
|
This requires that every Fortran target that uses modules have a full
dependency on the scan target of it's dependencies. This means that for
a three step target `A -> B -> C`, we cannot start compiling any of B
until all of A is linked, and cannot start compiling any of C until
all of A and B is linked.
This fixes various kinds of races, but it serializes the build and makes
it slow. This is the best we can do though, since we don't have any sort
of portable format for telling C what is in A and B, so C can't know
what sources to wait on for it's modules to be fulfilled.
|
|
It is not sufficient to have an order dependency on generated sources.
If any of those sources change we need to rescan, otherwise we may not
notice changes to modules.
|
|
Otherwise they won't be able to find their module outputs.
This requires a new method to look at dependencies, as the existing ones
wont find static libraries that were linked statically into previous
targets (this links with A which link_whole's B). We still need to have
B in that case because we need it's BMI outputs.
|
|
Because we use this dependency to ensure that any binary module files
are generated, we must have a full dependency. Otherwise, if a new
module is added to a dependent target, and used in our target, we race
the generation of the binary module definition.
|
|
Because we don't set the appropriate dependencies
|
|
|
|
But we really expect it to be a string once the initializer is done.
Therefore, let's set it to `''` just like we do with the scratchdir in
the case that it's set to None in the initializer.
|
|
Windows toolchains append `.exe` to executables. When cross-compiling on
Linux, attempting to run `./rusttest` will not execute the generated
`rusttest.exe`.
Fix this by always appending `.exe`, which is a valid filename on all
supported platforms. This is what the `CLikeCompiler` class does too.
While reviewing `rust.py`, there are opportunities for improvements and
better unification with the rest of the Meson code. However, this commit
focuses on fixing cross-compilation with minimal changes.
Fixes: #14374
|
|
|
|
sort_files has always defaulted to true.
Fixes: 2b37101998c8 ("meson format command")
|
|
--wrapper and --gdb are mutually exclusive per run(), so make get_wrapper
reflect this (which would've saved me some time earlier with trying to
make the two work together for something else, when it turns out that's
impossible).
As suggested by Eli.
|
|
We currently suggest that users run `meson test --wrapper valgrind`, but
this doesn't do what one might expect: Valgrind doesn't error out on
violations/issues it detects.
In the past, we had special handling for Valgrind in tests, see
1f76b76a84cb635f764ecbd2b77aaba1d375d72b but it was later dropped in
951262d7590343ffa9730666c427ad9d708a9fb6.
This is similar to what we do for {A,UB,M}SAN_OPTIONS to give sensible
behaviour that users expect out-of-the-box.
Only do this if we see 'valgrind' in the wrapper command to avoid
polluting logs. We may want to do that for the sanitizers variables
in future too.
Note that we're not adding --exit-on-first-error=yes here, as there
may be several issues in an application, or a test may be rather slow,
and so on. But --error-exitcode=1 to simply make Valgrind's exit status
reflect whether an error was found is uncontroversial.
Bug: https://github.com/mesonbuild/meson/issues/4727
Bug: https://github.com/mesonbuild/meson/issues/1105
Bug: https://github.com/mesonbuild/meson/issues/1175
Bug: https://github.com/mesonbuild/meson/issues/13745
|
|
When doing a host == build configuration. This allows us to remove the
ignore in check_unused_options, which was papering over this bug.
|
|
Because it makes machine files more generically useful (ie, you can use
a file as both a cross and native file) we allow all options to be
defined in native files, even when those options are not per machine. It
makes more sense to filter invalid options at Environment setup time
then to wait and have them filtered when the initializing the project
call.
|
|
|
|
Which better describes their purpose, especially now that this is in the
options module rather than the compilers module.
|
|
It's not just project options, it's all options that can end up on here.
|
|
Since they're not just native files, they're native files and cross
files combined.
|
|
This makes more sense from a "group all options together" It also allows
us to remove a bunch of imports in functions, a clear code smell.
|
|
|
|
Mostly this was just adding a few asserts for options, and one bug fix
from the option refactor
|
|
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Because this check is done on the actual key, it will fail even if
"subproject:project options" is used. The correct test is already
performed in mfilestr2key.
Fixes: #14373
|
|
There is no point in printing warning about unstable module, in the
worst case we can just deprecate and add new API. It has been tested in
a few projects already, and this warning is a blocker on wider adoption.
|
|
QEMU needs it in its integration tests (in order to run global constructors),
and therefore in rust.doctest too. With this change I could do:
# Rust executables do not support objects, so add an intermediate step.
rust_qemu_api_objs = static_library(
'rust_qemu_api_objs',
objects: [libqom.extract_all_objects(recursive: false),
libhwcore.extract_all_objects(recursive: false)])
rust.doctest('rust-qemu-api-doc', _qemu_api_rs,
dependencies: [qemu_api, qemu_api_macros],
link_with: libqemuutil,
link_whole: [rust_qemu_api_objs],
suite: ['doc', 'rust'])
followed by "meson test --suite doc".
For completeness, add it to rust.test as well.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Pass down the full_version, otherwise assigning "self.is_beta"
fails.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
rust.doctest() will have to typecheck that to a list of strings,
no other argument types are allowed. Extract the field out of
BaseTest, placing it in FuncBenchmark and the rust modules's
FuncTest.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Adjust get_rust_compiler_args() to accept the crate-type externally, because
rustdoc tests are an executable but are compiled with the parent target's
--crate-type.
Apart from that, the rustdoc arguments are very similar to the parent target, and
are handled by the same functions that were split out of generate_rust_target.
This concludes the backend implementation of doctests, only leaving the
implementation of a doctest() function in the rust module.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
A doctest target is a separate build target (with its own linker
arguments, including dependencies) that is built and added as a
unit test whenever the parent target is built. The doctest's
target is not accessible via ninja.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This will be used by rustdoc tests because the Test objects takes a
single string for the command and everything else goes in the args.
But apart from this, the need to split the executable from the
arguments is common so create new methods to do it.
While at it, fix brokenness in the handling of the zig compiler, which
is checking against "zig" but failing to detect e.g. "/usr/bin/zig".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Allow reusing the code for doctests. In particular, the sources are
shared between the two cases.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Another rust tool, another rough copy of the code to run clippy.
Apart from the slightly different command lines, the output is in a
directory and test targets are skipped.
Knowing the output directory can be useful, so print that on successful
execution of rustdoc.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
We have previously updated the python_command handling to correctly
detect PyInstaller builds without assuming that it is only Windows, back
in commit c39ee881a1959ae37aded8e0c24cec23b2bd6a90. But the fix was
incomplete. This affects e.g. running --internal scripts such as
symbolextractor.
The issue in this case is slightly more subtle. While sys.executable
won't be a valid python so it intuitively falls over quite badly when
trying to run it as one, getting the original command is broken in a
more interesting way. PyInstaller sets `sys.argv[0]` to the basename of
the executable, which then got absolutized to a nonexistent file in the
current working directory.
Fixes: https://github.com/mesonbuild/meson/issues/14412
|
|
Fix the unhandled KeyError exception that occurs when cross-compilation
configuration files are missing required parameters (such as 'endian').
This issue was introduced in commit b0d2a92 (PR #11692), where the key validation
logic didn't properly handle the relationship between provided and required keys:
- Previously, the code used `set(literal) < minimum_literal` to check if provided keys
were a strict subset of the required keys in minimum_literal
- This validation logic broke down when the provided keys weren't a strict subset anymore,
but rather an overlapping set with disjoint elements on both sides
- When required keys were missing, the code continued execution and later threw
an unhandled KeyError when trying to access the non-existent keys
Changed the condition check from:
if set(literal) < minimum_literal:
to:
if minimum_literal - set(literal):
This new check specifically identifies keys that are "present in required but not present
in provided", providing users with clear error messages instead of raising unhandled
exceptions. This change also removes the implicit requirement that "provided keys must not
contain any keys not present in the required set" - allowing for optional keys to exist
in the provided configuration.
Fixes #14385
|
|
|
|
Both dynamic libraries and bundles these days can be dynamically loaded
using the dl APIs (e.g. dlopen, dlclose). It is not possible to include
bundles on a linker command line as if they were shared libraries,
but that's pretty much the only difference.
However, bundles fail the Apple verification for iOS:
2025-02-10 13:54:09.095 ERROR: Validation failed (409) The binary is invalid.
The executable 'Runner.app/Frameworks/numpy._core._operand_flag_tests.framework/numpy._core._operand_flag_tests'
has type 'BUNDLE' that is not valid. Only 'EXECUTE' is permitted.
2025-02-10 13:54:09.096 ERROR: Validation failed (409) Missing load commands.
The executable at 'Runner.app/Frameworks/numpy._core._operand_flag_tests.framework'
does not have the necessary load commands. Try rebuilding the app with the latest
Xcode version. If you are using third party development tools, contact the provider.
So switch to -dynamiclib for shared modules as well.
Fixes: #14240
|
|
|
|
|
|
Don't hardcode paths in /usr when looking for the GTest sources, as in
cross-compile or other builds with a sysroot this will find the host
sources, not ones that we want to use in the sysroot.
Closes #12690.
|
|
Cuts down the spam radically when building with MSVC.
|
|
Put cygwin filemode tests back under the sourcedir
Remove inheritable permissions from the sourcedir
For :reasons:, the unit tests which check file mode were built in the
tempdir.
Instead, remove inheritable permissions from the working directory
(which the GitHub VM image has set for some reaons), since they can
interfere with getting exactly the file mode you asked for.
Partially reverts 04ae1cfb7999e25f476f84572ff0ad853629346c
|
|
Move the mention of the (deprecated) default command mode
down near the end of the page, instead of presenting it right
up front.
|
|
We should simply remap these to elide the ../ as it's pretty obviously
the natural expectation of using ../ to fetch files from outside the
project and then drop them *into* the project.
Monorepos will likely have a single license file (or set) under which
the monorepo is licensed. But there will be many components, each of
which may use a different build system, which are "standalone" for the
most part. We already support this case as long as you build from the
monorepo, but the resulting license file gets installed to
```
{licensedir}/../
```
which is silly and unhelpful.
Bug: https://github.com/apache/arrow/issues/36411
|
