This is a follow up of aosp/2336916. All the properties that have
variant_prepend tag are supported in bp2build.
Bug: 261644490
Test: TH and modified tests with updated expected behaviors
Change-Id: I13bb5d4d8fcd38bf153fa9083c9c945aec2dfa19
The comments in aosp/2336916 are also addressed here
Test: TH and TestCcLibraryVariantPrependPropOrder
Change-Id: If1472658fcd4b5544dec2e2691049a180520c84e
osLinux is implicitly glibc, use //build/bazel/platforms/os:linux_glibc
for the configurability select key for it.
Bug: 259266326
Test: build/bazel/ci/mixed_libc.sh
Test: USE_HOST_MUSL=true build/bazel/ci/mixed_libc.sh
Change-Id: Ifbd121ab3d943f3fdfbd3f6c3e982d1eaaaa9ec1
This will allow the test_suites_{arm64, x86_64} CI targets on
git_master-bazel to build adbd_test with bazel in `m`.
This is currently implemented similar to the cc_binary handler to
hydrate the output path field.
The tradefed config is still currently handled by Soong in
testBinary#install, which is called from both ProcessBazelQueryResponse
and GenerateAndroidBuildActions. We'll move the tradefed config path to
a mixed builds handler when it's ready on the cc_test bazel rule side.
Tested with `atest` with cuttlefish. Since `atest` doesn't have a way to pass
--bazel-mode-staging to its internal call to Soong, so I manually tested
this by adding adbt_test to the prod allowlist, and confirmed that the
installed adbd_test is the same binary as the one in bazel-out.
Test: $ showcommands adbd_test | grep bazel-out | tail -n1
```
/bin/bash -c "rm -f
out/target/product/vsoc_x86_64/data/nativetest64/adbd_test/adbd_test &&
cp -f -d
out/bazel/output/execroot/__main__/bazel-out/android_x86_64_silvermont-opt-ST-59d4124ca041/bin/packages/modules/adb/adbd_test
out/target/product/vsoc_x86_64/data/nativetest64/adbd_test/adbd_test"
```
Test: Add adbd_test to prod allowlist and run 'lunch aosp_cf_x86_64_phone-userdebug; atest adbd_test', all tests pass.
Bug: 258426425
Bug: 261692372
Change-Id: I6be329f39d607af8daa1dc772b23e8dd0247418c
Some properties in soong are marked "variant_prepend", which means
in bp2build output, variant properties(select ...) should come before
general properties.
Prepend property is added in StringListAttribute
stuct so that bp2build can handlle variant_prepend properly, if
Prepend is properly set in different module logics.
This change also coordinates cc library with Prepend.
Coordination with other module types will be in separate CLs.
Bug: 261644490
Test: TestCcLibraryHeadersSimple,
TestCcLibraryHeadersArchAndTargetExportSystemIncludes and TH
Change-Id: I3b61c491c54bbe91ba9aa2af9b4c84193c91ae7f
The axis for OS and in APEX was previously ignoring the excludes from
OS, which would result in excludes for non-Android OSes being
incorrectly ignored.
Test: go test Soong tests
Test: b build //hardware/libhardware:all
Bug: 260131489
Change-Id: Ie77f763bea0f473ac69a0c6b6bc3216e7359ad12
When a target does not have a certain provider we need,
currently we just fail at the dictionary lookup. Change
it so that we fail with a message that tells us what
target had the issue.
Bug: 260131489
Test: Presubmits
Change-Id: I99fd018835c14eba0d4db54ba2769b2da1b278f6
This file contains the java APIs parsed by the 'dexdeps' tool within the gen_java_usedby_apex.sh.
Bug: 239084755
Fixes: 239084755
Test: presubmits
Change-Id: Ia271783a6be3ea3a343481306cde1aaba2166e88
The build uses unstripped binary/shared library to extract function
signatures, so for each each target of this kind Bazel should return
its unstripped version, too.
Fixes: 220164721
Test: treehugger
Change-Id: Id5f6143340519bf2ae98791a9e981d1306bb08d1
The module types in scope of this conversion are
1. cc_library and cc_library_shared (non-null llndk or stubs prop)
2. cc_library_headers (all)
For (2), we need some postprocessing on the results of the parser
bp2BuildParseBaseProps. This is necessary because arch and os specific
API exports need to be flattened and added to the generateed API headers
target along NoConfigAxis
e.g.
```
The api equivalent of
cc_library_headers (
name = "lifoo",
deps = select({
"//build/bazel/platforms/arch:arm": ["arm_deps"],
"//build/bazel/platforms/arch:arm64": ["arm64_deps"],
}),
)
should be
cc_api_library_headers (
name = "lifoo",
deps = ["arm_deps", "arm64_deps"],
)
```
For (1), we also need to generate 1:many header api targets so that
arch-specific deps can propagate arch metadata to the top-level
api_domain rule
Test: go test ./bp2build
Test: go test ./cc
Change-Id: Ie40cba1ac8e89f290b3d926c190d5e93abd52859
Add barebones riscv64-linux-android support. This should be enough
to add riscv64-specific entries to Android.bp files, but can't
actually compile anything until there are riscv64 toolchains.
Test: arch_test.go
Change-Id: I0dcc7e797d9352dd38243be908a7f19004ff3db1
This makes mixed builds resilient to a recent backward-incompatbile
Bazel feature which explicitly adds the main repository (`@`) prefix to
all labels which are stringified by `str(target.label)` in Starlark.
This implementation is compatible with both current Bazel and
Bazel@HEAD.
After a new Bazel release to AOSP, we can clean up this code a little to
only support Bazel with this feature active (and that we need not hedge
on either Bazel behavior).
Bug: 248106697
Test: `m --bazel-mode nothing` with both current Bazel and a new Bazel
Change-Id: Id53c8505bb9080d5073c844de7f1ee57ceceae46
Previous commit: commit fcc53f992b.
Test: 1. use `TARGET_BUILD_VARIANT=userdebug TARGET_PRODUCT=aosp_arm64 build/bazel/ci/mixed_droid.sh` to verify no error occurred.
2. revise the test cases under request_type_test. 3. pass the test cases
Bug: 242587802
Change-Id: I7f70e62f7b6f42fa5f211772888040a0d07a710b
also using a generic json_encode as an approximation for `json.encode`
Test: 1. use m --bazel-mode-dev nothing to verify no error occured. 2.
revise the test cases under request_type_test. 3. pass the test cases
Bug:242587802
Change-Id: I1288ecca1afd3e32f6473bcabae4ee2cb5838007
Fix: 232544453
Test: go tests
Test: b build //frameworks/av/media/module/foundation:libstagefright_foundation
Test: b build //frameworks/av/media/module/foundation:libstagefright_foundation (with in-apex hardcoded to True, non-apex hardcoded to False)
Change-Id: I7b5f356ff6ed31f89a9d9153396bc851d991c487
also using a generic json_encode as an approximation for `json.encode`
Test: USE_BAZEL_ANALYSIS=1 m libc
Bug: b/242587802
Change-Id: Ib83aeda3f99cc3966548b0cd47e72669422ed72d
* changes:
add bp2build unit tests for aidl_interface
AIDL source generation accounts for Bazel paths
convert .aidl srcs for java_library
add Partition method to LabelListAttribute
Bug: 231322789
Test: with this CL on internal master,
1) b build --verbose_failures //vendor/google/modules/AdbdGoogle:com.google.android.adbd --config=android_x86_64
2) adb install bazel-bin/vendor/google/modules/AdbdGoogle/com.google.android.adbd.apex, and adbd is activated successfully on cuttlefish device.
3) m mts && mts-tradefed run mts-adbd, and there is no failure with cuttlefish device
4) packages/modules/adb/test_device.py, and there is no failure with cuttlefish device.
Change-Id: I81b6f5336cacf35c68957ae2dac65f985b6eafb9
It can be tedious to split a LabelListAttribute on all of the
configuration axes, so LabelListAttribute.Partition can be used to do
this based on a predicate function.
Test: go test ./bazel
Change-Id: I78ff8c24ce9c86bab5896290d8afe979d56545b6
Use of the native CcSharedLibraryInfo results in using a superfluous
symlink for shared libraries in mixed builds. The new provider
propagates an unwrapped output file (real file, not a symlink).
Test: With related rules changes, manually verified that installed
mixed-build libc was not a symlink. (cf_x86_64, inspected system.img
with `m droid`)
Change-Id: I2a59b348fbfc2a381c229d66c0098e87674a9ddc
Instead of a StringListAttribute of length 1,
introduce a more appropriately reduced StringAttribute
so that e.g. `select`s work properly
Test: new cases in TestGenerateBazelTargetModules
Change-Id: I0ae0e4a51e39f85caf55b0d00459222ede6de79c
