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.
This replaces all of the Apache blurbs at the start of each file with an
`# SPDX-License-Identifier: Apache-2.0` string. It also fixes existing
uses to be consistent in capitalization, and to be placed above any
copyright notices.
This removes nearly 3000 lines of boilerplate from the project (only
python files), which no developer cares to look at.
SPDX is in common use, particularly in the Linux kernel, and is the
recommended format for Meson's own `project(license: )` field
This time we have a case where people are passing non-objects by using
them as str | File, which we never warned about and silently accepted.
If it was passed via custom_target outputs we *would* error out,
interestingly enough. At the backend layer, we just pass them directly
to the linker... which is valid, if we misdetected what's a valid linker
input or people just used funny names. In particular, the mingw
toolchain allows passing a *.def file directly, and some people are
doing that.
If we do want to allow this, we should do it consistently. For now, just
follow the current theme of what's expected, but do so by warning
instead of fatally erroring, for cases where users were able to do it in
the past.
Pass link arguments directly down to linker by using `-C link-args=`
instead of letting rustc/linker resolve `-l` arguments. This solves
problems with e.g. +verbatim not being portable. Note that we also pass
`-l` args as `-Clink-args=-l` because rustc would otherwise reorder
arguments and put `-lstdc++` before `-Clink-args=libfoo++.a`.
However, when building a rlib/staticlib we should still use `-l`
arguments because that allows rustc to bundle static libraries we
link-whole. In that case, since there is no platform specific dynamic
linker, +verbatim works.
This also fix installed staticlib that now bundle uninstalled static
libraries it links to (recursively). This is done by putting them all
into self.link_whole_targets instead of putting their objects into
self.objects, and let rustc do the bundling. This has the extra
advantage that rustc can bundle static libries built with CustomTarget.
Disable bundling in all other cases, otherwise we could end up with
duplicated objects in static libraries, in diamond dependency graph
case.
Fixes: #12484
CustomTarget and CustomTargetIndex often have to be special cased
because they are not subclass of BuildTarget. It's easier to introduce a
dummy base class.
This fix recursive functions over link targets that might encouters
libraries built as CustomTarget.
Previously, AIX support was updated to archive shared libraries per AIX
platform conventions, which expect .a files that contain .so files. This
is usually correct, but an edge case occurs for loadable plugins, e.g.
what meson creates for `shared_module()`. A notable example is python
extensions (SciPy, for example).
These should *not* be archived, because the .so file itself needs to be
loaded as a plugin. For example, SciPy fails to import in the python
interpreter.
Handle this by differentiating between plugins and regular libraries,
and only archiving when safe to do so.
Fixes#12219
adb1a360b9 added the feature and also the
usual meson-style warning to users that might be using the feature but
were not targeting a new enough meson version. Well unfortunately the
warning both doesn't actually work (it didn't take different directories
into account) and is also really slow because it creates an O(N^2) loop
for checking this.
Instead, rework this by adding an additional set that stores a tuple
containing the target name and its subdirectory. We only add this tuple
if the target is an executable since it is the only time it will be
relevant. After that, simply check if the name + subdir combination
already exists in the set along with the target being executable. If so,
then we execute FeatureNew which may possibly warn. This is a simply
O(1) lookup which is way faster. Fixes#12404.
This also moves the repacking into the interpreter, making the build
implementation simpler and removing a layering violation. This also
makes use a defaultdict to remove the need to call `.get()`
Way back in Meson 0.25, support was added to `vala_args` for Files.
Strangely, this was never added to any other language, though it's been
discussed before. For type safety, it makes more sense to handle this in
the interpreter level, and pass only strings into the build IR.
This is accomplished by adding a `depend_files` field to the
`BuildTarget` class (which is not exposed to the user), and adding the
depend files into that field, while converting the arguments to relative
string paths. This ensures both the proper build dependencies happen, as
well as that the arguments are always strings.
When checking target names, meson explictly forbids having multiple
targets with the same name. This is good, but it is strict and it is
impossible to have targets with the same basename and differing suffixes
(e.g. foo and foo.bin) in the same directory. Allow this for executables
by including the suffix (if it exists) in the interal target id. So foo
would be foo@exe and foo.bin would be foo.bin@exe.
The MSVC code is extremely confusing, and it turns out it actually
constructs debug (pdb) files names/path independently in separate
places. This is really hard to parse. Instead, refactor it so that the
source of the debug filename is within the target itself
(get_debug_filename). Add a couple of generic methods to retrieve the
full path of the debug filename name in the backend and use that when
needed.
This differentiates export_dynamic being explicitly set to False from it
being unset. This allows us to deprecate explicitly setting
export_dynamic to false, but setting implib. This is already the case in
the other direction, if implib is False but export_dynamic is enabled
then we get a hard error.
This also moves the validation up to the Interpreter and out of the
build level.
Florent Valette
Charles Brunet
Eli Schwartz
Nirbheek Chauhan
Dylan Baker
Alyssa Ross
Jussi Pakkanen
Sam James
Tristan Partin
Gerion Entrup
Petr Machacek
Xavier Claessens
Stas Sergeev
Aditya Vidyadhar Kamath
Dudemanguy
Nomura