It's possible that a module will have a product variant
but not a core variant. In that case, we still need to
apply the vendor suffix to the androidmk module name.
Bug: 188720375
Bug: 187963715
Test: Build vendor image using vendor snapshot.
Change-Id: I190fdd707ca23357d1c324c1b1f3318457625f03
VNDK snapshots newer than v30 have LLNDK stub libraries. In that
case, the vendor variant for the BOARD_VNDK_VERSION must not be
generated from the LLNDK modules. They are already provided by the
VNDK snapshots.
Generate the vendor variant of the BOARD_VNDK_VERSION only if
BOARD_VNDK_VERSION has an integer value less than or equal to 30.
Bug: 187963715
Bug: 181815415
Test: m nothing
Change-Id: I31e90f4d7e7678c45558f6bf987f5582a4c34f78
At least until libc and libm builds, which are the common values in
system_shared_libs. We don't have a way to break the cycle of:
libstdc++.so (system_shared_libs) -> libc.so -> ...(whole_static_libs) -> libstdc++.a (system_shared_libs) -> []
because bp2build just sees it as:
libstdc++ (system_shared_libs) -> libc -> (whole_static_libs) -> libstdc++ (system_shared_libs) -> libc -> ...
therefore creating a cycle.
This CL punts the problem for now by ignoring system_shared_libs in the cc deps mutator, with a TODO.
Test: TH
Bug: b/186024507
Bug: b/186489250
Change-Id: Id4744593af39b7eb3b31418c8afaeeac99a0ab5f
.. in preparation for the upcoming change. This change doesn't alter any
behavior.
InApexes is a misleading name. People expects that it has the list of
soong module names of the APEXes that a module is part of. So, for
example, `core-oj` is a part of both `com.android.art` and
`com.google.android.art`. However, in reality, that's not true. The
field has `com.android.art` only. This is because the two APEXes
(android and Google) have the same apex name which is `com.android.art`.
That apex name is used in various places like the `apex_available` and
allows us to keep using the same name regardless of whether the APEX is
overridden or not.
However, this is causing problems in some cases where the exact list of
soong module names is required. The upcoming change will add a new field
to handle the case and the new field actually will get the name
'InApexes'. So, the existing field is renamed to a less misleading name
`InApexVariants`.
Bug: 180325915
Test: m nothing
Change-Id: I0c73361b452eddb812acd5ebef5dcedaab382436
There are two pieces to make this work:
1. Local include paths must include $(BINDIR)-relative paths, to support
generated headers in those directories.
2. The srcs that bp2build outputs for BUILD targets must include labels
for targets given in generated_hdrs and generated_srcs.
Support for exported_generated_hdrs intentionally deferred.
This allows us to remove several targets from the bp2build denylist.
Some are moved to the mixed build denylist, because genreated headers are
still unsupported in mixed builds.
Test: bp2build.sh CI script
Change-Id: Ib4f9dac20f6445487b8dad53b91eac01f437a590
This is so that its implementation is more amenable to implementing
`target: { android_arm: { ... } }` and the like.
In addition, add a Boolean return value to getChildPropertyStruct() and
use it at every call site so that we only merge property structs when it
makes sense.
Bug: 187530594
Test: Presubmits.
Change-Id: I1b441c14b3d90a12b84dc89f82dd053978e89c7e
Checking sdk_version broke mainline code that compiles against a current
API level but needs to be able to run on an older API level.
Bug: http://b/187907243
Test: treehugger
Change-Id: If1192ef2809e39b043f0a384775b6c9e3a8bd619
VNDK snapshot depends on addExportedGeneratedHeaders to grab generated
headers. This change adds a missing addExportedGeneratedHeaders call to
make libc's headers captured correctly.
Bug: 181326838
Test: VNDK_SNAPSHOT_BUILD_ARTIFACTS=true m dist vndk && unzip -l
out/dist/*.zip
Change-Id: Iaa89b5255c836761a26c77bb27f35f768f49039e
test_options in cc_test can have vsr_min_shipping_api_level to define
the minimum shipping api level that checks vendor api level in
addition to the device shipping api level. It can be used for the
tests that have dependency on the vendor api level.
vsr stands for the vendor software requirements.
Bug: 181284704
Test: manual test
Change-Id: I7f2cecd2818d35d86f7c08cb220e0c9db71fe0a8
Propagating enabling ASAN through shared library dependencies
doesn't make much sense, because only the non-ASAN variant is exposed
to Make, leading to an non-installed dependency.
Bug: 186487510
Test: TestAsan
Change-Id: I7d3f20f2d10beac09c66c6b6dcb7a34a513ff3b8
Improve the dependency accuracy by adding an order-only dependency
on the shared library alongside the existing depenency on the
table of contents file. The dependency won't cause the module
to be rebuilt when the the shared library changes, but will allow
anything using the ninja graph for sandboxing to know the dependency
exists.
Test: manual
Change-Id: I3accbcabee62fa0ad3eb3d1aaedc5a4bffe27308
This is to fix the unnecessary dependencies inclusion
when building apex modules.
Test: Build
Bug: 186306595
Change-Id: I1f3bbdb0a1f97a8338b45ca29c92acf9b20eadd3
This CL exports common/global/device/host clang/ld/ldd flags
from their Ninja variable initialization locations in
cc/config/global.go and cc/config/clang.go to make Bazel's cc_toolchain
and Soong's cc actions more consistent with each other.
This does not handle env-dependent or arch-specific toolchain flags
yet (logic in compiler.go and linker.go).
Test: TH
Bug: 187086342
Bug: 187084737
Bug: 186628704
Bug: 187857770
Change-Id: Ie403d7cd23f35160897b9dd902c799cbf1bd7f0c
Refactors the vendor snapshot support to use the LinkableInterface
so that support can be extended to Rust. This CL does not add
vendor snapshot support for Rust; that is left for a follow-on CL.
Bug: 184042776
Test: m nothing
Change-Id: Id0c4970ca00053484a52677d182153cbc454c301
