This target will have a dependency edge to every bp2build equivalent of
Soong's ndk_headers. In b builds, sdk variants will compile against this
aggregated CcInfo providing target
A non monolithic alternative was discarded after conversations in
b/300504837#comment1-5
Contents of bp2build generated target: https://paste.googleplex.com/6643820291686400
Implementation details
- Since there is no equivalent Soong module for ndk_sysroot, hardcode
bp2build/build_conversion.go to collect all ndk_headers soong modules.
Add them to `deps` of a ndk_sysroot target
- Create `ndk_sysroot` in build/bazel/rules/cc/BUILD.bazel. This is
expected to be a temporary location. This will use the
cc_library_headers macro
- Update SetStubsForDynamicDeps so that sdk variant of rdeps depends on
//build/bazel/rules/cc:ndk_sysroot. This will provide a CcInfo during
compilation. Since ndk_sysroot is of type cc_library_headers, it will
not get packaged into the apk.
- Refactor `goBazelTarget` to a generic `bTarget` so that it is
representative of the expanded usage by ndk_sysroot
Test: b build //build/bazel/examples/android_app/java/com/app:app_with_sdk_variant_of_jni_deps --config=android (with aosp/2755284)
Bug: 300504837
Change-Id: Ifa427dd78115703ab251b0e1a0b71d3f19e91008
This should be no-op, as the underlying mutator has not changed yet.
Some other refactoring is required and done in this CL:
- Delete some old, dead ApiBp2build code
- Fix casting to TopDownMutator when it's not necessary
This change is required to prepare for allowlist v2 work, as only
BottomUp mutators can AddDependency.
Bug: 285631638
Test: m nothing
Test: presubmits
Change-Id: I5212a5f5634cc13056195783e6df37ff8eb000da
This is a followup fix for aosp/2753352 that added the name of the
`cc_stub_suite` as deps of `unbundled_app` config setting. However,
cc_stub_suite is really a macro that expands to <name>-<ver>.
Add the version explicitly to rdeps
Bug: 298085502
Test: b build //build/bazel/examples/android_app/java/com/app:app_with_sdk_variant_of_jni_deps --config=android (with aosp/2755284)
Change-Id: I8cf2804141bb14589e11b03a138b715538a3f1ee
Instead, we return an error. This allows us to access some product
variable information earlier when it will not be used as an attribute
without panicing
Test: m nothing
Change-Id: Id094b2b9e1364a8d174d99b3824fa149fb235b3e
If a dependency has ndk stubs, then the sdk variant of the library
should link against the ndk stub variant and not the impl/apex_stubs variant
Unlike module-libapi, the depdendency does not go through an
@api_surfaces external repo indirection. This indirection was created to
support Multi-tree, and will likely be removed in the future
Test: Added a unit test
Bug: 298085502
Change-Id: Ie081e153fa586b6c22db0b8e42f91149fd8e5d9b
Ignore-AOSP-First: ag/24746588, in the same topic, is in an internal repo. This CL will be cherry-picked to AOSP afterward.
Test: go test
Bug: 277091218
Change-Id: I389d9535ea176991a1faa9beb46352b93363acd2
Merged-In: I389d9535ea176991a1faa9beb46352b93363acd2
For a dependency edge A --> B (stublib), Soong will link A's platform
variant against impl of B's platform variant if either of these are true
1. A and B have same apex_available
2. B has bootstrap: true
3. B is only available to platform
(3) was missing from bp2build. This CL adds that.
To implement this, we check the `apex_available` property of B.
Test: updated bp2build tests
Test: Built the internal module b/299191635 that was failing due to this
Bug: 299191635
Change-Id: Iafb173a3ab20d69b89f7949ce40c6f4096396f24
Without an explicit deduping in this helper function, a dependency may
appear multiple times in the generated BUILD files. I noticed this while
converting some internal google tests.
This currently does the deduping for the non-configurable root value. I
ran into some issues deduping the configurable values, and I will
address it in a followup CL.
Test: go test ./bp2build
Change-Id: Ie7b588a9c922d72e4fabfb1414a7cc3dc402ff86
Soong's proto.include_dirs becomes the -I path for aprotoc cpp code
generation. This does not translate well to Bazel because it runs this
action in a sandbox. Even if we construct an -I path, the .proto files
will not be there. This CL attempts to handle this kind of dependency
automatically via bp2build.
For this hypothetical example
```
foo.proto # contains `import bar.proto"
Android.bp # cc_library {srcs:"foo.proto", p.include_dirs:["subdir"]},
subdir/bar.proto
```
Implementation details for CcProtoGen of foo
- Glob the labels of .proto files for each includeDir, and create a
proto_library that encapsulates them.
- Since Bazel poses a contraint that proto_library target needs to be
in the same pacakge as the .proto file, the proto_library might be created
in a subdirectory with an import_prefix
- Add bar's proto_library as transitive deps of foo's cc_proto_library.
This will be added to -I during aprotoc. We cannot add them to `deps`,
otherwise bar's symbols will be statically linked into foo's .a
file.
Implementation details for clang compile of foo
At the end of CcProtoGen, we have converted foo.proto
to .cpp/.h files. To compile them to .a files, we need the .h files
generated from bar.proto. Soong specifies this at the
top-level cc_library soong module, so add those deps as the
implementation deps for clang compile.
(Will add support for java in a follow-up CL)
Test: go test ./bp2build
Test: built some internal modules that were previously blocked by this
Bug: 285140726
Change-Id: I7e1f9f0d1b1ba916a7ba8278f6cfb342b381d695
If `srcs` contains a gensrcs/genrule module, the current bp2build module
will put it in the catch-all `srcs` attribute. This is reserved for .cpp
sources, so if the genrule produces a .proto/.aidl/... file, this will
fail.
This handles genrules that produce .proto files. To implement this, this
creates an additional partition that detects if the other module is a
genrule/gensrc that produces .proto files. If true, it will append it to
the proto partition.
This CL does not handle
- genrule that produce .c/.aidl/.yacc/.... files. They will continue to
be partitioned into the catch-all partition
- java modules
Test: unit tests
Test: TH
Bug: 293205700
Change-Id: Ib720fdf3a053ff5dd256e6faa632e3fa7776966d
Embedding multiple includes from a genrule may be difficult to read,
instead we generate a header library that contains the headers and all
include dirs that Soong generates.
Test: go test bp2build tests
Change-Id: I590c74c133f015f27cccf5a2fd916153ad9c125e
This is prep work to add additional special handling for genrule
generated headers as there will be similar partitioning for those
headers.
Test: go test soong tests
Change-Id: Ib63e7e4f7554b2b7b7bc78b2825b20c05403216a
Bazel does not support using .rscrip/.fs files as cc srcs.
For a module foo with foo srcs, Bp2build will create a bazel
target of rule class rscript_to_cpp with name foo_renderscript
which will have only the renderscript files as srcs.
Bp2build will also create a target foo with the expected cc rule class.
The foo target will have all other src files as srcs and will also
have the target foo_renderscript as another src.
Bug: 210509914
Test: bp2build testing & b build target rstest-latency
Change-Id: Ifdc55051a3595f5fcf54eab8b59e11e9351e141c
In Soong, CFI being explicitly set to false overrides presence in
CFI_INCLUDE_PATHS, so this change causes Bazel to mimic the same
precedence.
Bug: 278789968
Test: Unit tests
Change-Id: I827b3d4272eac2002031970f1e67c9321979b14b
By default, the artifacts generated by cc_binary and cc_library in Soong
track the module name. But Soong supports overidding this using the stem
property. e.g.
```
cc_library {
name: "foo.1.2",
stem: "foo",
}
```
will generate foo.so
This CL adds this property to bp2build
Test: bp2build unit tests
Bug: 240563612
Change-Id: I1dfed870d5bad450511b72c397d2355c01fa3b60
In Soong, cc libraries depend on source files generated from xsd_config
using generated_sources and generated_headers. In Bazel, these souces
will be wrapped in a static library. Updated bp2build so that these are
written to implementation_whole_archive_deps instead.
Bug: 211678537
Test: bp2build test in sibling CL in system/tools/xsdc
Change-Id: Ib57c563a1eb7483bd7b04ba0d3852ecac17cde6c
host_ldlibs are used during linking. Set these in `linkopts` for now.
Note that this CL does not do the `CheckBadHostLdLibs` validation of
Soong. There are some different ways to do this, and these are being
discussed in b/216626461. It is likely that we will need to create a new
property `host_ldlibs` to do the validation. But for now, re-use
`linkopts`.
Bug: 216626461
Test: bp2build unit tests
Change-Id: Id4c77e4460fb1fb003fa58ea27bab5b50ea8cefe
https://source.android.com/docs/core/architecture/aidl/aidl-backends#custom-parcelables
Some aidl files have custom parcelables with references to cpp headers. Hence, we need to pass the include dirs from cc libs to cc_aidl_library so that custom cpp headers are findable by the generated cpp/h files.
Test: go test
Bug: 278704136
Change-Id: I4ede1d23fbc04bdbfb69823d955c6df6b0a7b4ee
Introduce aidl.libs prop on cc libraries to pass in aidl_library. The goal is to eventually disallow aidl.include_dirs (a pattern for passing aidl headers dir for aidl compilation) and enforce aidl headers to be explicitly specified in Android.bp.
Bug: 278704136
Test: go test
Change-Id: Ia78bc11dfa12f47d2d1bb90dc65372ddb17f7e14
We now rely on a `with_features` clause to effectively disable
thumb when `arm_isa_arm` is enabled. Thus, we no longer need to
add `-arm_isa_thumb` in bp2build.
Bug: 261733820
Test: Unit tests
Change-Id: I9da85834855b297a75097ce3a11e101f55bd53f4
For cc_libraries containing .y/.yy srcs, we will generate an additional
cc_yacc_static_library target. This target will produce an .a file that
will be statically linked to the parent target.
Test: go test ./bp2build
Bug: 281546029
Change-Id: I094ba56f0a95869e5bc1e1d38b83c777192b7ddd
* changes:
Special case platform variant of bootstrap libs
Select stub/impl per apex variant
For test apexes, base_apex_name is the api domain
Broaden the granularity of config_setting from apex_name to api_domain
Print default val if all vals in axis match default val
For converting the art plugins to pure soong, it would be useful to
have a property that's qualified on both a soong config variable and
the OS. Soong had very little-known support for this by saying your
soong config variable changes the "target.android.cflags" property,
and we didn't supporting bp2building that. Add the bp2build support.
This cl also refactors product variable and soong variable bp2building
so that they're separate from each other, which I think makes the code
easier to understand.
Test: go test
Change-Id: Ic74dc75da8103fa2523da95c3560c9ce3c5e5672
Platform variants of libraries that set `bootstrap: true` in their
Android.bp file gets impl in Soong. This CL ports this behavior to
bp2build.
Note that even after this CL, there will be still be some other cases
where stub/impl logic does not match Soong perfectly (most notably the
platform_apis property which is propagated top-down from the parent
apex).
Test: bp2build.sh
Change-Id: I3da284ab42631d6de1c0d52e56ccbfd4e4a09f1d
Create a select statement for every api_domain a library could be
included in. The stub/impl
selection heuristics per apex domain are
1. If dep has stubs and the api domain appears in dep's apex_available, use
impl
2. If dep has stubs and the api domain does not appear in dep's
apex_available, use stubs
(Category 3: If dep does not have stubs and the apex does not appear in
dep's apex_available, then a separate apex_available validation in Bazel
will emit an error).
Platform variants have been special-cased for now to use equality of
apex_available for stub/impl selection
Test: go test ./bp2build
Bug: 272378496
Change-Id: Ibd29efd763c8863c7e6d2a9af0da30bbde07175d
apex_test do not "override" the source apexes that they test. However,
similar to override_apexes, test apexes have the same path
(/apex/<apex_name>) on device. Instead of creating another property,
reuse the existing base_apex_name property. The use case for this will
be for creating selection statements for stub/impl selection.
Test: go test ./bp2build
Change-Id: I4b7548e0e0fc920e407e1c5e5c00e87efc6e70c9
The use case for this is for creating a select statement for stub/impl
selection. Since Bazel propagates apex_name from the top-level apex,
the source apex and test apex builds a specific library in two different
configurations. We need select statements for both these two
configurations, but this metadata might not always exist in Android.bp
since test apexes are not necessary to be listed in Android.bp files.
To overcome this, the select statements will be created per api domain
instead. This CL uses a naming convention to infer the api domain of
apexes.
Test: go test ./bp2build
Change-Id: Iad2b45f736bc98a24d2ce1cf2f69aad67973092d
