api providing modules (droidstubs, cc_library etc.) can refer to the api
file via a separate filegroup module. Therefore these modules should be
generated in the api_bp2build workspace as well
Test: m api_bp2build && build/bazel/bin/bazel build
--config=api_bp2build --config=android //build/orchestrator/apis:*
Change-Id: I77371bd94a2794770b01b98aaf84b1bc42810841
- Create the alias under the module-libapi directory. This is the
api_surface that cc_stubs_suite maps to.
- Create the alias only for "current" (atleast for now)
- Create one alias for the stub shared lib, and another for its headers
Test: b build @api_surfaces//... (with aosp/2475091)
Change-Id: Ib004c2c34256f971e74d75317fa5fbbe7273720e
The expected use case for this is to create aliases for stub libraries
in the @api_surfaces repository in build/bazel/api_surfaces.
This restricts the scope to just aliases. If we have a use case for
generating actual Bazel targets in another directory, a workaround could
be to generate the targets in the current directory (via
CreateBazelTargetModule) and aliases to it in the other directory
Test: go test ./bp2build
Change-Id: I6b63d9d018618d447fc7c260a2a94aaa00e57a4d
override_apex's bp2build converter had a bug where it was looking at
the product variables for the override_apex module itself instead of
for the base module it is overriding.
Fixes: 271424349
Test: go test
Change-Id: If1e2653d3751fa908faf0ab97dfa2e943ebe98ec
This is to match the behavior of BUILD file generation.
Test: m and all existing bp2build conversion tests
Bug: 271122205
Change-Id: I6320a65aaad06114817eaed722cc0a0939c57bc1
makes it clearer which attributes are kotlin specific
embedded within javaCommonAttributes since both
java_* and android_* use kotlin.
Change-Id: Ib7c9b912a9901cd1c3d150ab1e0a79011d8e07de
Test: go test ./bp2build
These are not necessary for queryview and can lead to inaccurate query results.
Test: m queryview; grep bp2build_all_srcs
Change-Id: Ifaf65b4ec5828718c2becb39b4507cf033ea4546
`proto` sub command now fails when the output file exists.
This is to avoid accidental overwrite.
To handle the case properly, it support --force and --append.
This is to support amending /{partition}/etc/linker.config.pb in the
build process.
Bug: 244531518
Test: manual testing
Change-Id: I0af8c83015e485f2c7533221cae8caf6143403c8
Armv9 with mandatory PAC and BTI extensions.
Stack protector is disabled as it is irrelevant with PAC.
Bug: 263283855
Test: NFC
Change-Id: I2f298f21dade12824597e0a6920772a2bfc63afb
This is no longer necessary after we reduce the exported static libs in
roboleaf.
Bug: None
Test: b build adbd with coverage enabled.
Change-Id: Ia049138c4cdd536670371b4fc9a54fca40d16d20
Unlike most module types, config variable handling is always namespaced
to the Android.bp file, which limits reuse of the variable definitions.
Additionally multiple of these module types can define a string variable
in the same config namespace, but specify different valid values for the
string.
Previously, we cached the first instance we see of variable + namespace;
however, this caused non-determinism in which defintion would be used
and not migrating all values. Instead, we now only cache within a single
Android.bp file where the variable definitions are re-used.
Test: go tests
Bug: 271481817
Change-Id: Ic327657c508e47a705bacd24712a1916e105c7cd
PRODUCT_VENDOR_LINKER_CONFIG_FRAGMENTS lists json files for vendor
linker config. It's annoying to handle the case of empty list.
`proto` subcommand now works for empty input. This is useful to generate
the empty linker config.
Bug: 244531518
Test: conv_linker_config proto --source --output output.pb
Change-Id: Iec6de67a979814a818730c393d9a4a7ca5d2eebe
there is now support for resoure_strip_prefix in kt_jvm_library targets.
Test: built AnalyzerKt and updated go ./bp2build tests
Change-Id: I4a6fe45276d45519186b6f40a02db990511d6def
