This CL adds the support for static/shared cc_library props nested
within target and arch structs, and correctly sets them in the right
select statement.
Test: TH
Bug: 189183307
Change-Id: I48f7d62755ebab56fe03d3ecee2e15427eb552c9
Test: Added new unit test and updated existing tests.
Test: bazel build //bionic/... //external/... //frameworks/... //system/...
Test: ./build/bazel/scripts/run_presubmits.sh
Change-Id: I250d1964f5cf42b92ddb929379d35d8c844423f7
This fixes a test and rolls forward I28cf7437ee96cdf2fdbcb1eda2303691cff08ba4
Test: m nothing
Test: See I28cf7437ee96cdf2fdbcb1eda2303691cff08ba4
Change-Id: I0e450c28e70087e406e7b562d7e772785f177379
Revert submission 1714835-roboleaf-asm-c
Reason for revert: TestCcLibraryStaticProductVariableSelects fails everywhere
Reverted Changes:
I28cf7437e:Split asm and c flags and srcs in bp2build output
I2b47e6b55:Split libraries by language in cc_library_static
Change-Id: I85d39a462f0a5b3f5ff3d685906813fab9f01358
This allows removal of almost all current items from the mixed build
denylist, which were previously broken due to being unable to separately
control flags for compilations of different languages within the same
target.
Note that this does not appropriately implement asm/c srcs and flags for
either the shared variant or the static variant. This will require a
followup.
Test: bp2build.sh and mixed_libc.sh CI scripts
Test: Updated b2build tests
Change-Id: I28cf7437ee96cdf2fdbcb1eda2303691cff08ba4
llndk.libraries.txt is used to list the LLNDKs for the linkerconfig.
This is also required to define the VNDK snapshot modules of LLNDK
stub libraries.
The list had a filter for hwasan libraries, but the filter must be
used only for the LLNDK_LIBRARIES make variable, but not for the
llndk.libraries.txt file.
Bug: 189070366
Bug: 188716508
Test: m nothing
Test: LLNDK_LIBRARIES in make_vars-*.mk does not include hwasan.
Change-Id: I820dd1161892dc76700aa1d696ea2643764d2052
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
Test: bp2build and mixed_libc CI
Test: Manually verified that libc_bionic_ndk compilation gets the
appropriate headers (and no extra headers) from downstream
Change-Id: I79eb6e8ec1d415bd50d12105da4cf97101f95474
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
