Recently, it is possible to install Clang with Visual Studio Installer. By
default this Clang has a MSVC target, and invokes the Microsoft Linker; if
`-fuse-ld=lld` is specified, it will invoke LLD-LINK. Both linkers take
MSVC-style arguments, and take DEF files with `/DEF:<path>`.
Previously DEF files were passed in the GNU way, directly on the linker
command line like an object file, which caused errors like
lld-link: error: ..\my.def: unknown file type
While Clang-CL takes Unix-style options, it actually passes MSVC-style
options to LINK or LLD-LINK with `-Wl,`. There is already a check for both
linkers in `linker_to_compiler_args()`, so it's necessary to do the same
in `gen_vs_module_defs_args()`.
This commit closes https://github.com/mesonbuild/meson/issues/13988.
Signed-off-by: LIU Hao <lh_mouse@126.com>
Doctests have a slightly different output compared to what "protocol: rust"
supports:
running 2 tests
test ../doctest1.rs - my_func (line 7) ... ignored
test ../doctest1.rs - (line 3) ... ok
test result: ok. 1 passed; 0 failed; 1 ignored; 0 measured; 0 filtered out; finished in 0.12s
Add a little more parsing in order to accept this; a simple minded split()
fails to unpack the tuple. I plan to contribute an extension of the rust
module to invoke doctests, for now this allows running rustdoc --test with
"protocol: 'rust'" and get information about the subtests:
▶ 4/8 ../doctest1.rs:my_func:7 SKIP
▶ 4/8 ../doctest1.rs:3 OK
4/8 rust_unit_tests:doctests / rust doctest OK 0.28s 1 subtests passed
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
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>
Using a rustup-based toolchain fails the "rust/2 sharedlib" test for me:
./prog: error while loading shared libraries: libstd-211931512faabf29.so: cannot open shared object file: No such file or directory
This happens because recent rustup places the standard library under
SYSROOT/lib/rustlib/TARGET/lib. Retrieve the right directory using
"--print target-libdir". This also provides a more accurate version
for rustc installed in /usr.
Before:
$ echo $(/usr/bin/rustc --print sysroot)/lib
/usr/lib
After:
$ /usr/bin/rustc --print target-libdir
/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib
While at it, cache the value to avoid repeated process invocation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
If the same source is provided by multiple dependencies it was added
multiple times, as `added_sources` was only guarding against duplicates
within the same source list. This was not a problem with ninja, but it
triggers multiple sanity checks within xcode backend while attempting to
create multiple ids for the same file.
Rename `added_sources` to `seen_sources` as per reviewers request
The deps and orderdeps are sorted on output, so there is no need to preserve
their order.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
version_compare can take a few milliseconds. If you have a thousand object files
or a multiple thereof, it adds up.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>
Any argument from the base target is copied to the test target, but some
keyword arguments for libraries are not available in executable.
Remove them.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
On Python 3.12, self.prefix.relative_to(self.prefix.drive) no longer
works and raises error like:
```
ValueError: 'C:/msys64/mingw64' is not in the subpath of 'C:'
```
There is actually very little overlap between `install_sources` and
`install_data` in arguments they accept: only 2/7 keywords for `install_data`
apply to `install_sources`.
Closes gh-12601
We don't need an extra process in the process tree (specifically the
`meson devenv` process itself). Aside for the redundancy, it's actively
problematic if you abort a program in the devenv by using CTRL+C, as
meson itself will then emit a traceback (KeyboardInterrupt) which is
quite ugly.
It's not actually useful, we can just add the root meson.build file to
the depfiles when we translate the meson.build into ast. If there's a
provided ast then we don't go down that path anyway.
This was only used in a couple of places, and requires extra tracking to
ensure it is correct, while we already have `current_node.lineno`, which
is always accurate and up to date.
I have also fixed a potential strict-null issue by using a sentinel node
for `current_node`
Cargo sometimes adds new keys and Meson needs to gracefully handle
those. Currently, an unknown key will trigger an uncaught Python
exception, which is pretty much the worse case. With this change Meson
will instead issue a warning much like the one for unknown cpu
architectures.
See #13826 for the motivation for this change
LIU Hao
Jan200101
Sam James
Paolo Bonzini
Dylan Baker
Charles Brunet
Nick
Jussi Pakkanen
Xavier Claessens
Simon McVittie
Luca Bacci
Noah Gitsham
prajwal-ibm
MihailJP
Ralf Gommers
Daniel Markstedt
Eli Schwartz
andy5995
Frank Dana