With proper prebuilt modules, we can avoid any rustc implicit sysroot
searching.
Asd a bonus, this should make rust-project.json generation correctly
grab otherwise implicit dependencies.
Prebuilt rlibs may include several dependency rlibs. Without a
link_dirs attribute, every dependency (even if unexported) would need a
separate module.
Previously we were casing out on exact structs, which might be OK when
libraryDecorator and procMacroDecorator were the only possibilities, but
repeating the logic for three types is too much. Using an interface
makes this logic scale better.
Bug: 159591910
Test: cd external/rust; mma; m crosvm.experimental
Change-Id: Ia1124e09f48cd05e39f094bbcb988622ebd2272f
This change makes it possible to use a single module to provide both
dylib and rlib varieties of a library. This allows the use of libstd and
libtest from a rustlibs property, allowing linkage type to change
for different variants.
Bug: 159718669
Test: cd external crates; mma; m crosvm.experimental
Change-Id: I477c4d2faec63703fdc6dd42ba020747d6a50714
Adds the rustlibs dependency type which will automatically select
between rlib and dylib based on the type of the library.
Bug: 143217452
Test: cd external/rust; mma
Change-Id: I97faadae98bf957090a32939cfb2d3a10f74a057
rust_library now produces only rlib and dylib variants.
rust_library_foreign now produces static and shared variants.
This change was made because both are common cases, but all four
together essentially never happens. This allows us to have fewer repeat
module definitions.
Bug: 143217452
Test: cd external/rust; mma
Change-Id: Iaf69e8da38f7c12710331c51464699cf7cbbb656
The moduleContextImpl structure contains duplicate information on the
contexts. BaseModuleContext, ModuleContext and DepsContext can already
surface which Module is being processed via Module(). Because most of
the Rust-specific methods on the *Context structures simply forward to
the Module methods, expose a RustModule() method.
Test: cd external/rust/crates; mma
Change-Id: Ifee90825d54081fc5e9a8df0b7c4580412e9158c
Bug: 144861059
Test: cd external/rust/crates; mma
Test: Manual verification through ldd that libstd is a dependency
Change-Id: I603cf519215317aa8c400cd0f6ebb1b58f5bcf15
Without specifying -soname, cc binaries are unable to locate Rust
provided shared libraries. This adds the -soname linker flag for shared
libraries.
Bug: 158490355
Test: readelf -d <cc_binary> shows the expected SONAME
Change-Id: I66852a7ce24d5ea5e426f11bc1834fb56a150628
This adds gcov coverage support for Rust device library and binary
modules (including test modules). Support is provided to pass Rust
static library gcno files to CC modules and visa versa.
Additional changes:
* Begin mutator added for Rust modules.
* SuffixInList added to android package.
* CoverageEnabled added to Coverage interface.
* CoverageFiles added to LinkableLibrary interface.
* Fix in coverage mutator for non-CC modules which marked the wrong
variant as the coverage variant.
* Added coverage libraries to the cc.GatherRequiredDepsForTest.
Bug: 146448203
Test: NATIVE_COVERAGE=true COVERAGE_PATHS='*' m -j <rust_module>
Change-Id: If20728bdde42a1dd544a35a40f0d981b80a5835f
CC libraries which depend on Rust libraries get missing dependency
errors when building 32-bit variants dependent on Rust modules which
don't explicitly have "multilib: both" declared.
Because CC libraries use MultilibBoth by default, Rust should do the
same.
This also fixes a bug where the ARM32 toolchain incorrectly embedded
toolchain64Bit instead of toolchain32Bit.
Bug: 154730212
Test: Rust libraries provide both variants by default.
Change-Id: Ia545fe069d3c6b77c3d18f4f10267e2c72ee0bab
cdylib targets cannot currently dynamically link to Rust crates, so this
flag was not actually doing anything, and in conjunction with -C lto
which we *do* want on for this target, causes a hard error on
rustc-1.40.0.
Bug: 147438124
Test: Build a rust_library module, this implicitly tries to build cdylib
Change-Id: I828b3e6bae7c58f4081db3e73009b443a382a296
If we want to build a component which uses two versions of a crate in
the dependency graph (for example, libc in std and libc from
external/crates), Rust requires at least one of them have a metadata
field to differentiate them.
Since Soong module names should be distinct for a given target, they
should serve as metadata.
Bug: 147397356
Test: Build a rust library with "rlibs: ["liblibc"]" in the blueprint
Change-Id: I5d85ea8b3197972c09de301c9523efaff08adf81
* Now the installation directories match those for C/C++ tests:
* The relative_install_path refers to path under nativetest(64).
* Device test files are installed in data/nativetest(64).
* Automatically generated configuration files and copied test binaries
are still in the "testcases" directory.
* Change host test configuration to run test binary files
in testcases/<mutated_module_name>/<arch_type>/<stem_name>
Bug: 140938178
Test: atest --include-subdirs under external/rust/crates
Change-Id: I4b29afb897f4ba8749e87f79857c5b1a959bb2b0
Rust C libraries cannot currently depend on dylibs. This prevents device
libraries from attempting to link the stdlib dynamically, instead using
rlibs.
Bug: 144861059
Test: Simple Rust library compiles as a shared/static library.
Change-Id: I38e5aae90e50ddcc5fc72d5a8d1820d92955cf48
Make sure LinkabeInterfaces can export include dirs to cc modules. This
fixes the Rust implementation and makes sure these are pulled in for cc
modules.
Bug: 144052093
Test: cc module depending on a rust library includes dirs correctly.
Change-Id: I6b5d5e6ab6afb507178b4f2cbdc45f01031dbfe4
rustc expects libraries and proc_macro filenames to conform to
a particular format, alphanumeric with underscores and lib${crate_name}.*.
Enforce this with a check when getStem() is called.
This makes the crate_name property required for proc_macros and
libraries. This also removes the notion of a default crate name derived
from the module name. It's not needed for binaries, so this won't impact
them.
Bug: 143579265
Test: m -j crosvm.experimental
Change-Id: I2770cf7d02dd4291c3d240d58d242b940098dcee
Adds the ability for rust modules to be compiled as C libraries, and
allows cc modules to depend on these rust-generated modules. This also
means that soong-rust should not have any dependencies on soong-cc aside
from what's required for testing.
There's a couple small fixes included as well:
- A bug in libNameFromFilePath that caused issues when library's had
"lib" in their name.
- VariantName is removed from rust library MutatedProperties since this
was unused.
Bug: 140726209
Test: Soong tests pass.
Test: Example cc_binary can include a rust shared library as a dep.
Test: m crosvm.experimental
Change-Id: Ia7deed1345d2423001089014cc65ce7934123da4
Adds support to Soong for building rust modules. This currently only
supports x86_64 device and x86 linux host targets. The functionality
is sufficient to build crosvm.
Bug: 136189233
Test: Test module builds.
Test: crosvm builds.
Change-Id: I6ea04615834a6d673578ab10ea1a2eb04259fe09
