Previously we ran mutators in bp2build mode to add dependencies, now we
look up modules by name directly. Remove workarounds to allow bp2build
mode to not fail when adding/handling dependencies.
Test: m bp2build
Change-Id: Ibf6fd905150cac306e5c395902ef28f609f4df2a
Currently error messages appear like:
&fs.PathError{Op:"open", Path:"..." Err:0x18}
which make them difficult to parse.
Test: CI
Change-Id: I18da18abc43230d0ea37d166179d07e585077f51
Add a rust toolchain for musl libc, use std library built from source,
and add default dependencies on musl libc.
Bug: 216192129
Test: m USE_HOST_MUSL=true host-native
Change-Id: Ic5ff4487db9693aeb08a13405f4d18465eecdc4b
Musl libc with an embedded linker uses multiple crtbegin dependencies,
convert rust's CrtBegin and CrtEnd to lists.
Bug: 190084016
Test: m USE_HOST_MUSL=true host-native
Change-Id: Ie843801e87b1f38ace84502d9e4f938a92ec1fa2
These modules do not currently build correctly. Support is planned but
not complete.
Bug: 204303985
Test: Presubmit + build `rust_library` with `vendor_available: true`
Change-Id: Iac7df9fe0d4eaa9a5ec0ff5a9cd5670af23df2a6
Rust installed files reside in "$MODULE_OUT/stripped/" when they are
stripped, otherwise they reside in "$MODULE_OUT". However, other parts
of Soong assume that installed files are always in $MODULE_OUT
(cc_modules place *unstripped* files in $MODULE_OUT/unstripped).
This notably causes problems when adding Rust modules as test data in
AndroidMkDataPaths. When Rust modules are parsed by AndroidMkDataPaths,
if they are stripped then they incorrectly get installed as test data
with the path:
<install_root>/<relative_install_path>/stripped/file.
This CL refactors how we handle Rust stripped output such that the
installed file always resides in $MODULE_OUT.
Bug: 171710847
Test: Installed files now always reside in $MODULE_OUT
Change-Id: I53a6ff57a0a5a55cd95ea78ae592ce22abfa20c9
Write toc files that list the exported symbols so dependents are
only rebuilt if the exported symbols change.
This exports the CC function TransformSharedObjectToToc, and also
removes an unused arg from its signature.
Bug: 178185435
Test: New Soong test passes.
Test: m <toc file path>
Change-Id: I7ab69bf7e7f32f25eb4c7ca9d18d877dac1511db
Move the cfg and feature flag calculation out of compilerFlags so that
it's a separate step.
The previous arrangement resulted in overridden compilerFlags which
must to set any additional cfgs/features before calling the base.
This is a bit confusing and undocumented behavior, so instead break
it out into a separate call that can itself be overriden.
Bug: N/A
Test: Soong tests pass
Change-Id: I28e4f707b3b3ca6eb621b7613c3737817f877bb8
Current snapshot definition is located in the CC module, so it is
difficult to capture non-CC module (such as prebuilt_etc) to the
snapshot. Separate general snapshot definition from cc so other modules
can also define its own snapshot.
Bug: 192430376
Test: m nothing passed
Change-Id: Ifb69fb3d2ec555b629aa31ec03e7ce5831fd3063
Adds an android_dylib cfg when building a Rust crate as a dylib. This
cfg lets us make the hack to add a dependency on std for the
panic_handler and eh_personality conditional on actually building a
dylib.
Test: m nothing
Bug: 193087363
Change-Id: Idad5b98245264f916afa327812a435b368f99321
There was a reference to the static library provider, but only the
transitive static deps were used, so only store that part. Other members
were stored but unused anywhere.
Test: go test soong tests
Test: m nothing
Change-Id: I12a6b94806c052c3f0df3cab0a10f17042af1c38
Adds support for snapshotting Rust rlibs. This allows us
vendor-specific code that uses rlib-only linkage until dylib
snapshot support is added.
Bug: 184042776
Test: m nothing # new Soong tests pass
Test: Example test Rust vendor module builds
Test: m dist vendor-snapshot # includes rlibs
Change-Id: I4976d3e1efec0ee778cc97730d45be471dffb678
Adds support for platform vendor_available Rust FFI libraries and
binaries to be included in the vendor snapshot.
Because rlib and dylibs are not yet in snapshots, libstd cannot be
included in a vendor snapshot. As a result, vendor-specific Rust code
can't be guaranteed to work with the platform-provided vendor_available
modules built with a newer toolchain. For now, a check is added
indicating vendor-specific Rust code is unsupported.
This changes the linkage for vendor variants of these modules to default
to rlib linkage since dylibs cannot be included in the snapshot yet.
Bug: 184042776
Test: m nothing # new Soong tests pass
Change-Id: I502eaa4bb962eb87ff868fcf49b435f0d2f982e6
Adds `m rustdoc` which generates documentation for all Rust libraries
to $OUT_DIR/soong/rustdoc.
Follow up work:
* Generate an index page that lists all modules.
* Preserve the artifacts so we can have an always-up-to-date go link.
Test: m rustdoc
Bug: None
Change-Id: Id2d6b9cbab5b02e36b575567563d7cc7606b9401
This adds Rust vendor image support for all module types except
Rust prebuilts.
Bug: 184042776
Test: New Soong tests.
Test: Example cc_library vendor module can depend on rust_ffi_shared.
Test: Example rust_library vendor-only module compiles.
Change-Id: Iaa30ad51fdaedcbf14687da5472581f6af62ff59
Rustc unstable option "link-native-libraries" is used to prevent the
linkage of other libraries via the #[link] directive. Add a dependency
to libclang_rt.builtins, similarly to cc.
Bug: 141331117
Test: lunch aosp_crosshatch-userdebug; m
Change-Id: I5c232291a5dd08a99e6a12a1295e30bb8e4fcaf1
Pass static libraries to rustc via the "-lstatic" flag so that rustc can
reason how to handle these libraries. This means that these static
libraries get bundled into rlibs, reducing the need to redeclare these
dependencies in dependent modules.
Additionally, exported depFlags were never used anywhere, so remove this
from flagExporter.
Bug: 175886967
Bug: 179122837
Test: m
Test: Checked that static symbols aren't duplicated in a resulting
binary when it appears in a dependency graph more than once.
Change-Id: Ifeb3c384e4fad8704206997242a0156ddcb87d2c
This currently expands all globs, still need to support converting glob
syntax.
Test: go build_conversion_test
Test: GENERATE_BAZEL_FILES=true m nothing
Test: m nothing
Bug: 165114590
Change-Id: If7b26e8e663d17566fad9614ca87a8da1f095284
Dependencies from common arch modules like java libraires to cc modules
may need to retrieve the Target of the library, add it to
SharedLibraryInfo.
Bug: 176593487
Test: cc_test.go
Change-Id: I93ab9da5fab2ccc42c6b483a6d83c071b541d1e6
Use WriteFileRule instead of a rule that calls printf for generating the
module source file for rust_protobuf.
Bug: 171361369
Test: rust_protobuf modules compile
Change-Id: Ie83a30e19d7d09875f3d209662526783862d8ea0
We don't have Rust VNDK support yet, but static linkage can be
supported in the interim. This adds support for making rust_ffi_static
libraries available to CC vendor modules.
Since rust_ffi_static modules will link against rlibs, we allow rlib
linkage into vendor as well, but only for the variants which use the
rlib libstd.
Bug: 172525289
Test: New Soong tests pass
Test: Example vendor cc_binary links against rust_ffi_static module.
Change-Id: Idf3aeb51e32293866f1ad965e329aa6b9e0bf2ef
Moves the prefer_rlib property out from being exclusively a binary
property to one thats part of the base compiler properties. This
provides a little more control over the libstd linkage in our libraries.
Specifically, this enables a usecase where rust_ffi_shared needs to link
against libstd statically rather than dynamically.
Bug: 175121262
Test: New Soong tests pass.
Change-Id: If68014c684a75ba70e9d7dacbb01c7d360dc25a1
This further emulates the rust-protobuf gen_mod_rs flag by providing
support for generating a single module containing multiple protobuf
definitions.
Bug: 171361369
Test: New Soong tests.
Test: Example module containing multiple protos works.
Change-Id: I815f9628a8289ae512758073dac49bc4535abf01
Export information about static libraries, shared libraries and
exported flags through Providers instead of accessing the module
directly. Much more is left to be converted, but this significantly
simplifies the dependencies on libraries with stubs by making it easy
for a module to masquerade as another by simply exporting the
providers from the other module. Instead of depending on all the
versions of a library and then picking which one to use later, it
can depend only on the implementation variant and then select the
right SharedLibraryInfo from the variant.
Test: m checkbuild
Test: only expected changes to build.ninja
Change-Id: I1fd9eb4d251cf96ed8398d586efc3e0817663c76
Adds the "static_executable" property to rust_binary modules which
allows for building fully static executables. This only impacts bionic
targets.
Bug: 169434439
Test: rust_binary module with static_executable true builds, runs on
device.
Change-Id: I83c19fddd070859b7e56d248237cfd73e1768519
Instead of returning a boolean, return an enum value to improve
readability and provide greater flexibility for future modifications.
Bug: 168729404
Test: Soong tests pass
Change-Id: Iddcdae8c34be09e476404382e43d1ea5935bae65
Until now, source provider modules duplicated the rule to generate the
source for each variant. Add a inter-variant dependency between the
source and the other variants (e.g. rlib, dylib) to avoid this
duplication. Add documentation on this behaviour.
Bug: 162588681
Test: m
Change-Id: I41c9e2220f8875245415e17374852e540dfd47ec
The current state of linkage is that device targets always link
libstd dynamically except for rust_ffi_static which requires a static
libstd linkage. However this prevents producing rust_ffi_static
modules which depend on other Rust libraries as those dependencies
will link libstd dynamically and cause a collision. We also want our
rust_test modules to statically link in libstd as well.
This adds a linkage mutator for rlibs that creates a variant for each
libstd linkage. Dependent modules can then select the variant that
matches their linkage of libstd.
Also fixes an issue where installation paths were being generated for
rlibs and static libs even though they weren't being installed. This broke
when adding the linkage mutator as Make would complain about multiple
targets producing the same output.
Bug: 168729404
Test: rust_ffi_static module with other rustlib dependency can be built.
Change-Id: I955b484bf5809e8fc5517750c7f8df82d3ca8895
Reuses the cc.Stripper logic. Abstracts Stripper to avoid the spreading
of references to the cc package.
rustc requires unstripped libraries (precisely, with the `.rustc`
section) when building dependent targets. Contrary to cc, the output of
a compiler module will remain unstripped and only an extra build rule
will be added. This rule will be referenced at install time (in
baseCompiler.install or androidmk).
This change drastically reduces the size of the installed libraries:
(unstripped, from out/target/product/crosshatch/system)
$ find . -name \*.dylib.so -print0 | du -c --files0-from=-
149996 total
(stripped, with this change)
$ find . -name \*.dylib.so -print0 | du -c --files0-from=-
42380 total
Bug: 153430439
Test: cd external/rust; mma
Change-Id: I94fd8bbcec97e0610aa325d3db4460be84d01734
In order to support cc dependencies which do not start with the 'lib'
prefix, we can't pass them through the -l flag. Instead, we can pass
them directly to linker flags.
Bug: 166151658
Test: cd external/rust/; mma
Test: cd external/crosvm/; mma
Test: Test linking to a cc dep that does not begin with 'lib'
Change-Id: I5acbf3d3405e66446f3eae600b35683c4eb3d8a5
Device binaries currently are linked statically by default. Instead we
should be linking these dynamic by default. To avoid conflicts when
manually specifying rlib dependencies on modules, we always link libstd
dynamically for all device modules except static libraries.
This removes the "prefer_dynamic" property entirely to avoid confusion.
Bug: 165161105
Test: m profcollectd is built dynamically.
Test: cd external/rust/; mma
Test: cd external/crosvm/; mma
Change-Id: I25ac897040acbcc2d97c791a33e8e01610632272
This allows SourceProvider modules to create rust_library variants so
that generated source can be referenced as an external crate rather than
via an include macro. This is done by including rust_bindgen modules
like any other library, as a dependency in either rlibs, dylibs, or
rustlibs.
This renames the stem and flags properties for rust_bindgen modules to
source_stem and bindgen_flags, respectively. This deconflicts with the
usage in baseCompiler.
This also removes 'subName' from the Module struct and moves it over to
SourceProvider, which was the only user. This allows us to set it in
baseSourceProvider's AndroidMk; setting it in Module's AndroidMk was
causing problems finding NOTICE files for bindgen library variants.
Bug: 159064919
Test: New Soong tests pass.
Test: Local test rust_binary can use rust_bindgen module as a crate.
Change-Id: Ieb2cb614c2dd0b5aa7120541d77f6f822a6a1806
rust_library modules no longer produce "link" variants alongside
"rust_libraries" variants as the former have been moved to rust_ffi
modules. rust_library modules however still create empty link variants
and code paths still assume that modules can support both rust linkage
and cc linkage. This adds unnecessary complexity that no longer serves a
purpose.
This cleans this up by removing the unused "link" variant for
rust_library modules and simplifies code paths that can now assume
modules are either a rust library or a cc library, but not both.
This also fixes a bug where Shared() was returning the wrong value.
Bug: 159064919
Test: cd external/rust/; mma
Test: cd external/crosvm/; mma
Change-Id: I3b5498c80b315c56b621dcb1388022fecc1bfc1b
rust_bindgen was not hermetic previously as it would pull in host
headers for device targets. This fixes that by using the same flags we
use when compiling with Clang. This also makes sure our rust_bindgen
headers are built as similar as possible to their respective
cc_libraries.
This also pulls in the bionic dependencies as well, which provide the
headers required for device targets.
Bug: 162007475
Test: device rust_bindgen deps file does not reference host headers.
Change-Id: I4efdf333e011a6c6d73a0345e5485823f166d17a
Modules defined in the srcs property are automatically added as
dependencies with AddDependency(), which will use any variant available.
This can cause incorrect architecture bindings to be silently pulled in,
such as when a host module uses a rust_bindgen module that doesn't
create a host variant.
This moves populating depPaths.SrcDeps over to depsToPaths and adds a
check for SourceProviders to make sure the correct OS and architecture
is being used.
Bug: 161826371
Test: Soong no longer silently pulls in bindings for the wrong
target.
Test: New Soong test to catch this case passes.
Change-Id: I2b3651cf6fc7dabf4081434df1c455e637f5b3a4
Allow rust modules to depend on and use generated source code provided
by SourceProvider modules and genrule modules without resorting to
hardcoded output paths.
All generated sources are now copied to a dependent module's
intermediates directory, then OUT_DIR is set to point to that path when
calling rustc. This matches the common convention used in most rust
crates to include generated source code from the path defined in the
OUT_DIR environment variable.
A couple other small notable changes are included in this CL:
* prebuiltLibraries can no longer include generated source files as they
should be prebuilt.
* srcPathFromModuleSrcs now excludes the main source file from the
second return value so its a list of only the generated sources.
Bug: 159064919
Test: Local example rust_library compiles with rust_bindgen dependency.
Test: Local example rust_library compiles with genrule dependency.
Test: Collision detected when multiple providers produce similar output.
Test: New Soong tests pass.
Change-Id: I59f54a25368c680b9086420c47ec24ab8cd1de6b
* "srcs" list contains one main Rust source file,
followed by optional dependent modules.
* A dependent module included in the "srcs" list is
the module name prefixed with ":".
* Add a simple test.
Bug: 160331255
Test: make and manual test build dependencies on genrule modules
Change-Id: I4f079138c2599158810b6412fce81b612a3f64a4
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
