| Age | Commit message (Collapse) | Author |
|---|
|
This allows linker arguments containing a space (or other special
character) to pass through to the linker correctly. For example, the spaces
in "test cases/windows/25 embed manifest" when using
meson.project_source_root().
|
|
only the real arguments to response file
|
|
Fixes #6710
|
|
|
|
Fixes #12330
|
|
Depending on the target/linker, rustc --print native-static-libs may
output MSVC-style names. Converting these to Unix-style is safe, as the
list contains only native static libraries.
Fixes linking with C targets built with clang on x86_64-pc-windows-msvc
target.
Fixes: #14366
|
|
Because we will need to call it from a module in a followup commit.
|
|
Because rustc does not support extract_objects, QEMU creates a static library
with all the C objects. It then passes this static library as link_whole,
together with another static library containing general purpose utility
functions which is passed as link_with.
However, this is brittle because the two have a circular dependency and
they cannot be merged because of the link_whole/link_with difference.
While lld seems to have the --start-group/--end-group semantics
automatically, ld.bfd can fail if these options are needed. This can
cause difference between distros depending on how Rust is packaged
(e.g. Ubuntu 22.04 and Debian bookworm seem to use ld.bfd).
The simplest solution is for Meson to implement "objects:" properly
for Rust. Then QEMU can use the same internal dependency objects that it
already has in place for C programs.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Allow reusing it for Rust targets.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Allow CUDA to completely override the -std arguments but not the rest.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
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.
|
|
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>
|
|
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>
|
|
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 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
|
|
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.
|
|
In the preceding commit we have started to perform compiler checks for
the value of `b_sanitize`, which allows us to detect sanitizers that
aren't supported by the compiler toolchain. But we haven't yet loosened
the option itself to accept arbitrary values, so until now it's still
only possible to pass sanitizer combinations known by Meson, which is
quite restrictive.
Lift that restriction by adapting the `b_sanitize` option to become a
free-form array. Like this, users can pass whatever combination of
comma-separated sanitizers to Meson, which will then figure out whether
that combination is supported via the compiler checks. This lifts a
couple of restrictions and makes the supporting infrastructure way more
future proof.
A couple of notes regarding backwards compatibility:
- All previous values of `b_sanitize` will remain valid as the syntax
for free-form array values and valid combo choices is the same. We
also treat 'none' specially so that we know to convert it into an
empty array.
- Even though the option has been converted into a free-form array,
callers of `get_option('b_sanitize')` continue to get a string as
value. We may eventually want to introduce a kwarg to alter this
behaviour, but for now it is expected to be good enough for most use
cases.
Fixes #8283
Fixes #7761
Fixes #5154
Fixes #1582
Co-authored-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
|
|
Using str.split is faster than Path.parts
|
|
Introduce an alternative to os.path.commonpath(name, path) == path,
which is a common idiom throughout Meson. Call it is_parent_path
just like the existing static method in Generator.
It is a bit faster and handles drives on Windows without the need
for an exception handler.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
If a project uses PCH and they are for e.g. GCC, it will not help to build
them before running clang-tidy. Just skip creating the clang-tidy and
clang-tidy-fix targets in that case.
|
|
"ninja clang-tidy" will not work if you are using pch files and have
not run a full build yet: the pch files will not yet be built and
there is no dependency between the pch targets and the clang-tidy
target.
Fixes: #13499
|
|
|
|
|
|
In large repositories, transitive link dependency resolution using the current
recursive algorithm can result in enough duplicate calls to cause the full
system memory space to be used up.
This commit simplifies link dep resolution by converting the currently used
recursive algorithm to an iterative one that avoids performing work more than
once. If a target's direct dependencies have already been processed, that
target will not be processed again.
These changes result in multiple orders of magnitude of improvements to dep
resolution time and memory usage in the worst case.
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
|
|
The swift compiler does not update the modification time of output
object files when the code has not changed. Without this, Swift
targets may continuously be rebuilt.
|
|
|
|
|
|
This makes SourceKit-LSP work using a meson-generated
compile_commands.json.
|
|
Since we're going to split generate_rust_target() in multiple functions,
eliminate the only variable that spans large parts of it.
The cratetype ninja variable has been unused since Meson started invoking
rustc directly nine years ago (commit d952812b1, "Fix Rust to work with 1.3
release. Closes #277.", 2015-10-11).
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Add functions to RustCompiler() to account for differences
between rustc and "rustdoc --test": rustdoc always generates
a binary, does not support -g, and does not need --emit.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Since the introduction of dep-info=... it is possible to move the depfile
away from the main build directory without using --out-dir. This is
less surprising, since the rules for mixing --emit, --out-dir and -o
are not really documented.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Implement RustCompiler.build_rpath_args, so that more code can
be shared between non-Rust and Rust targets. Then, RustCompiler
can override it to convert the arguments to "-C link-arg=" and
add the rustup sysroot.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
os.path.abspath of the target subdir is not guaranteed to give a sensible
answer; depending on what directory you run meson from, it could build
an absolute path relative the source directory or the build directory
or possibly neither one. In fact, using os.path.abspath is quite rare
in Meson's code and generally only done in code like
subdir = os.path.abspath(os.path.join(self.sourcedir, target['subdir']))
or
ndir1 = os.path.abspath(os.path.realpath(dir1))
While at it, don't use getattr unnecessarily, the cratetype is available.
Reviewed-by: Dylan Baker <dylan@pnwbakers.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
SharedModule (like Python extension modules) are loaded dynamically.
Therefore, they cannot be detected from executable dependencies, and
we must call `determine_windows_extra_paths` on them as well.
Also, those extra paths need to be computed even if the module or the
executable is not installed in the default location.
|
|
There was a missing parameter in one call.
This was caused by b95e1777ddbf0f8aebb56b84a6011468088c06ec
|
|
Closes mesonbuild#14185.
|
|
As the comment to get_generated_headers says, these dependencies should
be order-only dependencies.
Fixes #10882.
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
This is a very hot function, improve the memoization of the results by removing
an argument (that is almost always empty, in fact).
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
The proj_dir_to_build_root argument of determine_ext_objs is always empty,
remove it.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
|
Add support for the TASKING compiler family, and its MIL linking feature
|
