By setting android_exe_type to `application`, the executable gets
actually built as a shared library instead of an executable. This makes
it possible to use an application within an android application process.
mesonbuild#13758
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/7555/
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
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.
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>
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.
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>
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>
#13837 broke both_lib transitive deps, because the
`as_static` and `as_shared` functions return libraries
that still contain references to the other lib type.
Internal dependency names were generated from object id. This cause
problem when objects are copied, especially when generating partial
dependency, or when extracting shared or static dependencies from
both_library, because dependency names in target and dependencies
introspection files become unrelated.
This fixes that by generating the dependency name from the internal id,
and by using that base name when generating partial dependencies.
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
Sanity check for bare metal rust wasn't working for a while and there is a pending PR (#12175).
To workaround this problem, we used to let sanity check for build machine and manually defined
rustc target.
Commit 18f8aeda8b breaks this workaround as, even without an
exe_wrapper, native_static_libs are appends as internal deps.
This behaviour makes sense for cross compiled rust in a rich environment but not any for
no-std rust. As said in comments, one can't tell if the code is no-std or not because this is
an annotation from sources. From our point of view, it is pretty clear that building a no-std
rust target means that one has to define system='bare metal' and kernel='none' in his cross-file.
According to that, sanity_check for rust compiler is modified to handle kernel == 'none' case
by building a specific no-std rust snippet, with an extra args if rust_ld is ls.bfd (in order
to prevent the linker to link with a potentially non existing startfile for the given target).
'native_static_libs' is also leave empty in that very case.
This commit fix the spurious native static libs for no-std case and allow us to remove
our dirty workaround which by-passed non working sanity check for bare metal rust.
One who wants to use meson for baremetal Rust project only have to define the rust target
in their cross file.
e.g.
rust = ['rustc', '--target', '<rustc valid target>']
aee941559 ("rust: recursively pull proc-macro dependencies as well")
had to be reverted (in a66cb97e8) because it broke Mesa cross
compilation. This happened because a C shared library was linked with
a Rust C-ABI static library, which caused it to inherit the proc macro
dependency the Rust static library was linked with.
The right way to handle this is for only Rust targets to inherit proc
macro dependencies from static libraries they link with. A Rust
executable, library, or whatever will need the proc macros its Rust
dependencies use, as illustrated in the test case that I've
reintroduced here.
I've verified that Mesa still cross compiles correctly with this
change. The same failure was also identified by the "rust/21
transitive dependencies" test case, but only when cross compiling, so
it wasn't caught by CI.
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
This reverts commit aee941559c.
The commit being reverted breaks compilation of a major Meson consumer
(Mesa). As a result, various distros are either pinning to <1.4.0 (before
the commit) or performing this same revert downstream.
Fixing a regression takes priority, so let's revert.
Fixes: https://github.com/mesonbuild/meson/issues/12973
When the proc-macro rlib is in a different subdir, it would miss the
needed -L argument and rustc would not find it. Meson was assuming that
proc-macros are only needed when building libraries that uses it, but it
turns out that was wrong, as show by the unit test.
This code cleverly tried to use a fancy new pathlib.Path method to get
the os.path.commonpath of two paths and check whether one is inside the
other. It failed pretty badly, because of a hidden secret of pathlib: it
is designed to throw random exceptions at all times (except when
building os.PathLike interfaces) instead of performing useful work.
Return to `os.path`.
In particular, before this change, we wanted to check if files are NOT
in a subpath of `preserve_path_from`, and raise a meson "ERROR: xxx" in
such a case. However, the code to check for it would raise a python
ValueError if that was the case, so we never got to the properly
formatted error.
Since we don't get a location for these errors, we can at least tell you
which targets you happen to be mixing together that produce this
problem.
Ran into while trying to debug a target mixing bug.
This patch adds 'depends' keyword to compiler.preprocess().
It allows to execute other targets before doing the preprocessing.
Test-case is added to demonstrate that functionality: it
generates the header before preprocessing the C source that
uses that generated header.
Thanks to @bruchar1 for getting this patch to work.
Florian "sp1rit"