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
"exec format error" showed up on Mac when running the rbe_test.go.
The generated bash scripts did not have a newline at the end of
the file.
Bug: b/162600461
Fixes: b/162600461
Test: "m blueprint_tools" on Android Mac builder.
Change-Id: I425fa5f428733b6569c3fcdaa312023f9761d020
Disable the error test cases to allow developers to build
AOSP on Mac.
Bug: b/162600461
Test: m nothing
Change-Id: Ic8c6fe04743a8e4fe197a1bb71259036fb749edc
Disable the error test cases to allow developers to build
AOSP on Mac.
Bug: b/162600461
Test: m nothing
Change-Id: Iac4373dcb10710d8a2325eeb3ee20a6eeca6143f
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
This will allow us to remove `create_stubs: false` throughout the
codebase easily, then remove the functionslity to create stubs from
droiddoc.
Test: m docs
Test: m checkapi
Test: m updateapi
Bug: 144248501
Bug: 143136634
Change-Id: Ib95f68bc064fbe1475e4b25433bee6292bc005dc
Previously, the prebuilt mutators were added by the
cc.RegisterRequiredBuildComponentsForTest() function as a convenience
but unfortunately it lead to some of the mutators being in a different
order in the tests than in the normal build.
This change:
* Extracts the RegisterPrebuiltMutators() call from
cc.RegisterRequiredBuildComponentsForTest()
* Makes sure that the prebuilt mutators are registered before the
visibility gatherer and enforcer mutators.
Bug: 162505935
Test: m nothing
Change-Id: I7d959b558200b502f0a5e4653c41ea01414e142a
When a module is disabled by calling Disable(), it could be
unexpectedly enabled by the archMutator. For example, a module has
```
enabled : false,
arch : {
arm64 : {
enabled : true,
},
}
```
When this modules is disabled by calling Disable() before the
archMutator, it became enabled again ignoring Disable() command.
By defining the `ForcedDisabled` property, we can disable a module
regardless of `Enabled` property.
Bug: 161565086
Test: m
Change-Id: I443720715edbac25cb6d7c3d9eb1bc9806719161
com.android.gki.* matches any APEX with the prefix com.android.gki.,
like com.android.gki.bar.
Test: use it
Bug: 162267963
Change-Id: Ie46fcb08b031611d26b2b6cde157253f51ba9bfc
llndk_library and llndk_headers are backward compatible. We may use
the source code instead of snapshot for those modules.
Bug: 161565086
Test: build with vendor snapshot
Change-Id: If3da3f9b31f7180d8d0835f8dbd7ba938a60d967
Multiple GKI APEXes may write to the same path
under $OUT/apex. Prevent it.
Fixes: 162366062
Test: build GKI APEX
Change-Id: I1b19870b10d6da2a85c3f7b9d93408d3a0fe90bc
When a vendor APEX sets use_vndk_as_stable: true, then the apex doesn't
bundle VNDK libraries but instead it uses them from the "vndk" namespace
at runtime.
":vndk" is a pseudo-name for VNDK libraries, which is processed by
linkerconfig so that the generated linker configuration allows the
namespace for the apex to access VNDK libs.
Bug: 159576928
Test: test with a test-only vendor apex
it runs okay with VNDK libs. (lsof shows that it opens libs from
VNDK APEX)
Change-Id: I924ce0fea696162575f59589b8f858deddf436b3
