| Age | Commit message (Collapse) | Author |
|---|
|
Instead of having a raw python exception, provide a helpful error
message that `[sub:sub1:project options]` should just be `[sub1:project
options]`
No test is provided as this is basic error handling, and I felt it was
not worth adding to our test runtime to test that we don't raise a raw
exception.
Fixes: #14222
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
They are duplicates of what is already in compilers and have no state. Just
use compilers.
Fixes: #15082
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
cmd_line.txt is not related to serialized data, in fact it's a fallback
for when serialized data cannot be used and is also related to setting
up argparse for command line parsing. Since there is no code in common
with the rest of coredata, move it to a new module.
Fixes: #15081
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Do not create a single cargo.Interpreter for the whole execution, instead
create one as soon as a Cargo.lock file is read and only make it last until
that Cargo.lock has been processed.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Avoid different but equivalent code between ast and regular
interpreter, and avoid using coredata.set_options since
all options are known to be backend options.
Move to environment since it uses environment.options.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The key is already correct at this point, no need to look up CFLAGS_MAPPING.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
this fixes the "frameworks: 15 llvm" tests with llvm 21.1
|
|
together
Rust sources are not compiled separately: generation of the .a or .so
or binary happens at the same time as compilation. There is no separate
compilation phase where the .o file is created.
In preparation for moving generate_rust_target where generate_link is now,
make the compilation phase of generate_target skip them.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Fixes: #14789
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This is allowed -- it is already deprecated for the cross file, but it should not
assert. Add a deprecation for the native file too, and remove the assert.
Fixes: d37d649b08b832d52fa684bc0506829fb40d5261
Fixes: #14789
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
That is where env_opts are stored, so make the compiler call back directly
into the environment.
Suggested-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Thanks to several fixes applied between commit d37d649b0 ("Make all
Meson level options overridable per subproject.", 2025-02-13) and now,
OptionStore never gets a string key. Tighten the type of OptionDict,
and use it whenever possible.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
For compatibility with Autotools, CFLAGS is added to the linker command
line if the compiler acts as a linker driver. However, this behavior
was lost in commit d37d649b0 ("Make all Meson level options overridable
per subproject.", 2025-02-13).
The issue is that (for example) c_link_args is stored in env.options, and
from that point on it is treated as a machine-file option. This includes
not being able to override it in compilers.get_global_options:
- initialize_from_top_level_project_call places it in pending_options
- add_lang_args passes the right value to add_compiler_option
- add_compiler_option calls add_system_option_internal
- add_system_option_internal fishes the value out of pending_options
and ignores what get_global_options provided.
Instead, store the putative values of the compiler options coming from
the environment in a separate dictionary, that is only accessed by
get_global_options. This way it never appears in pending_options, and
also there is no internal *_env_args variable anymore.
Fixes: #14533
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Make space for moving the larger comment about *_env_args, which will be before
the for loop once *_env_args is removed.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
All of iOS, tvOS, visionOS, watchOS use the XNU kernel. Report that and also
make them return true for is_darwin() which is really more like "is_xnu()".
Co-authored-by: Russell Keith-Magee <russell@keith-magee.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
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.
|
|
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.
|
|
|
|
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
|
|
This is an old method, that is now just a wrapper around the OptionStore
method, that doesn't add any value. It's also an option related method
attached to the CoreData instead of the OptionStore, so useless and a
layering violation.
|
|
|
|
this fixes the "frameworks: 15 llvm" tests with llvm 20.1
|
|
This as much as anything is to stop lying to envconfig about the
potential types it will be given.
|
|
These include things like not narrowing unions and boolean error
handling
|
|
|
|
|
|
|
|
It is possible to run a container or chroot with one ABI on a CPU and
kernel that would normally have a different ABI, most commonly by
running a 32-bit container on a 64-bit CPU and kernel. When we do a
native build in such an environment, the build and host architectures
are both equal to the architecture of the container, and it is safe to
assume that we can run executables from that architecture, because if
we could not, we wouldn't be running Python successfully.
Until now, we have been handling this by adding explicit special
cases in `machine_info_can_run()` for each known-good combination of
the detected CPU and the host architecture: every x86_64 can run x86
binaries, and every mips64 is assumed to be able to run 32-bit mips
binaries. However, the equivalent would not be true on ARM systems: *most*
aarch64 CPUs can run arm binaries, but not all (according to Wikipedia,
ARM Cortex-A34 is an example of a purely 64-bit CPU that cannot execute
32-bit instructions).
Instead, assume that if we are doing a native build (not a cross build),
by definition we can run build-architecture executables, and since the
host architecture is equal to the build architecture during a native
build, this implies that we can run host-architecture executables too.
This makes the behaviour of `need_exe_wrapper()` consistent with
`meson.can_run_host_binaries()`, which in turn avoids `Compiler.run()`
failing with error message "Can not run test applications
in this cross environment" during native builds even though
`meson.can_run_host_binaries()` has previously succeeded.
Resolves: https://github.com/mesonbuild/meson/issues/13841
Signed-off-by: Simon McVittie <smcv@debian.org>
|
|
|
|
Introduce a global Cargo interpreter state that keeps track of enabled
features on each crate.
Before generating AST of a Cargo subproject, it downloads every
sub-subproject and resolves the set of features enabled on each of them
recursively. When it later generates AST for one its dependencies, its
set of features and dependencies is already determined.
|
|
uname -s does return gnu there.
Resolves: https://github.com/mesonbuild/meson/issues/13740
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
|
|
The clang-tidy-fix target uses run-clang-tidy to do the fixing, however
this script itself spawns `os.cpu_count()` threads as part of its
internal parallelism. When combined with Meson's parallelism this
results in the creation of potentially thousands of unecessary threads.
This commit rewrites the clang-tidy-fix to perform the same task
run-clang-tidy does but exclusively on Meson's thread pool. "Fix-it"
snippets are saved to `meson-private/clang-tidy-fix/` by a parallel
clang-tidy phase, afterwards (to avoid races) all collected fixes are
applied with a single call to clang-apply-replacements.
|
|
|
|
|
|
Originally from here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080463
|
|
|
|
Signed-off-by: Jannik Glückert <jannik.glueckert@gmail.com>
|
|
|
|
If need_exe_wrapper() is called while figuring out the language compiler,
the MachineInfo isn't complete yet, so machine_info_can_run() would return
False despite not cross compiling.
Make sure this fails loudly.
|
|
This reverts commit cc201a539674babf46f726859587afb5ed6a6867.
It's true that some aarch64 CPUs can run 32-bit ARM code, but some
(especially high-end ones, those most likely to be running builds)
cannot. It's better to assume that they can't, so builds don't
unnecessarily fail due to attempting to run a sanity check executable.
|
|
|
|
|
|
The documentation for subprocess.run at https://docs.python.org/3/library/subprocess.html#popen-constructor has a warning,
pointing to using shutil.which() instead of subprocess.run for detecting if exe files exists on the path.
shutil.which() is used in many places already.
|
|
|
|
|
