This refactoring prepares for introduction of bazel prod mode, an
alternative mechanism for mixed builds allowlist handling.
* Decide bazel-mode as close to soong_build main as possible
* BazelContext itself decides whether a module is allowlisted
* Separate bp2build and mixed build allowlist
Test: m nothing, manually verified all modules are mixed build disabled
(via metrics)
Test: USE_BAZEL_ANALYSIS=1 m nothing, manually verified that mixed build
disabled/enabled modules are identical before and after change.
Change-Id: I0f55d8b85000cb4a871a099edc6d7d868d7df509
Bazel conversion state needs to be cloned during module cloning, so it
should be registered via module.AddProperties. Until now it was done
implicitly as the modules converted so far added the whole
base.commonProperties field (and thus transitively all its subfields).
However, adding CommonProperties also adds its fields to the list of
the module's attributes, which is undesirable. The problem surfaced
while implementing Bazel conversion to the `license` rule.
Bug: 190817312
Test: treehugger
Change-Id: Id3de4ede8df81b21f00065a3a1bdc2d707391c3a
This large refactoring has both immense performance implications and
improves mixed builds complexity / usability. Summary:
1. Queueing calls to Bazel is done in a new mutator instead of a full
soong_build pass. Normal soong_build flow is interrupted (via a
functional hook in blueprint) to invoke bazel and parse its response.
2. Implementing mixed build support for additional modules is as simple
as implementing MixedBuildsBuildable. In this interface, define the
request that must be queued to Bazel, and then subsequently define
how to handle the returned bazel cquery metadata.
3. Mixed builds consists of only a single pass. This greatly
improves mixed build performance.
Result:
A 33% runtime improvement on soong analysis phase with mixed builds.
Caveats:
C++ BazelHandler handling still remains a bit of a mess; I did what
I could within this CL's scope, but this may require additional cleanup.
Test: Treehugger
Test: Verified that aosp_arm ninja file is bit-for-bit identical with or
without this change.
Change-Id: I412d9c94d429105f4ebfafc84100d546069e6621
To make testing easier, refactor existing module-global variables into a
struct that can be mocked.
Test: build/bazel/bp2build.go
Change-Id: I9d177677644ea743641a745b1839a3a8b29f902a
Also, add java_imports that were blocked by jetifier binary.
b/221082840 was blocking the build of jetifier which these java_imports
depended on. That bug is now resolved, so we can unblock these targets.
Bug: 220168131
Test: b build //packages/apps/Car/libs/car-ui-lib/car-ui-androidx/...
Test: build/bazel/ci/bp2build.sh
Change-Id: I89a32bde30c133a44aeb7826afa11d4140433f5d
In Soong, java_library can specify static_deps which are dependencies
that get aggregated into the final jar (akin to static linking). This is
useful because it allows dependencies higher up in the chain to compile
against the APIs exported by transitive dependencies. Bazel does not
support this functionality directly, but it can be emulated via the
exports attribute which makes any targets listed in the attribute public
to targets further up the chain.
Bug: 217236083
Bug: 219908977
Test: b build //external/error_prone:error_prone_core
Test: b build //external/bouncycastle:bouncycastle-host
Test: b build --platforms=//build/bazel/platforms:linux_x86
//prebuilts/sdk/tools/jetifier/jetifier-standalone:jetifier
Change-Id: I2867e3f816de720a6f4bd9ff7a847d1b0c2da2d6
Add a --fix option that will cause the script to automatically fix the
issues that it finds. It uses the bpmodify tool to add values to the
bootclasspath_fragment's hidden_api properties.
This adds analyze_bcpf to bp2buildModuleDoNotConvertList as
analyze_bcpf depends on bpmodify which is a blueprint_go_binary which
is not yet supported by bazel.
Bug: 202154151
Test: m analyze_bcpf && analyze_bcpf --bcpf art-bootclasspath-fragment
m analyze_bcpf && analyze_bcpf --bcpf art-bootclasspath-fragment --fix
atest --host analyze_bcpf_test
Change-Id: I5ee52419b4829474f6dbeb47f86ab2aeb22b1382
This change also requires that java_import modules be prepended with the
"prebuilt_" prefix in the `bp2buildModuleAlwaysConvertList`. This fixes
a bug where trying to disable a java_import by name without the
"prebuilt_" prefix would also disable the corresponding source module if
it exists with the same name.
Test: build/bazel/ci/bp2build.sh
Change-Id: If75236891810e5112d70441653be4644d8fe5ecf
If a module is enabled via the module-level allow list,
bp2buildModuleAlwaysConvertList, then we should error if that same
module is hidden by an existing BUILD file.
Bug: 220875679
Test: add a module in a directory covered by an existing BUILD file
Change-Id: I5426bd9edac593690c0989b68a421ac1c3216010
Test: b test //build/bazel/tests/apex:build.bazel.examples.apex.minimal_mainline-module
Bug: 217838178
Change-Id: If94a2086db2a4afabe600b691f65b388ea19dcfe
This depends on go modules and is musl specific, not a current focus.
Allows CI to be green again.
Test: bp2build.sh
Change-Id: I35520636b38eed3f829e176c4ba91517fd61364a
We currently enabled modules in bp2build on a package level, and we
disable individual modules based on a denylist. To enable a specific
module individually, we must change the corresponding Android.bp file to
include a bp2build_available property. Instead, have a centralized list
of specifically enabled modules.
Bug: 220875679
Test: m bp2build
Change-Id: I908f2f2366b72affb04234fbe92ba03bf5a37338
The android_app certificate property can be converted to the
@android_rules debug_signing_keys attribute in Bazel after converting
the .pk8/.pem key pairs to a JKS keystore in Starlark.
Test: b build -s //frameworks/base/tests/appwidgets/AppWidgetHostTest
and verify includes SignApk action with generated keystore
Bug: 194133023
Change-Id: I2c4276f94a7856fc68a7674e89742f887dca31b4
Bug: 216114082
Test: Run mixed build on adbd apex and verify the pavkaged adbd binary;
add unit test.
Change-Id: Id11549a7952a7ce5ac02988b88b747bbfe8339ff
Change-Id: If01efe076c223886278f466b65628602bff3a964
These trigger a few failure modes (duplicate genrule srcs, failure in
matching config conditions, depending on unconverted soong_zip host
tool).
Test: CI
Bug: 218405924
Change-Id: I15c119803a057e94ef6a941df3b58103d42eb4e4
To unblock mixed builds, uses a common mechanism to determine cc module
type across bp2build and mixed builds.
Test: mixed_droid.sh
Change-Id: I1f69ad0858cda549b7c95dbadd596e46df0f23b2
This commit enables conversions of java_library_static and adds the
static_deps Soong attribute to Bazel deps for all Java libraries.
Currently, Soong handles static dependencies for Java differently, and
Bp2build may need to address that later (see b/217236083).
Bug: 215229742
Test: go test ./bp2build
Change-Id: I4f86780c634dca0a2cfb9294084b14e139cc2375
This only supports the `jars` property/attribute.
Test: b build external/error_prone:error_prone_core_jars
Bug: 215229744
Change-Id: If0d9c8c4e9c1c560d35a501c20bef9361ef45e15
Bp2build currently supports building genrules for cc modules, but does
not support building java_genrule* modules. This commit adds this
functionality.
Bug: 213480907
Test: go test ./bp2build
Change-Id: I473196c5bcf5582ba0c8faa65b5005f81ac973a4
