Converters for contributions to systemapi and vendorapi

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

1 files changed, 2 insertions, 2 deletions

diff --git a/android/api_domain.go b/android/api_domain.go
index 787665475..0993e3d84 100644
--- a/android/api_domain.go
+++ b/android/api_domain.go
@@ -73,9 +73,9 @@ func ApiDomainFactory() Module {
 func (a *apiDomain) DepsMutator(ctx BottomUpMutatorContext) {
 	for _, cc := range a.properties.Cc_api_contributions {
 		// Use FarVariationDependencies since the variants of api_domain is a subset of the variants of the dependency cc module
-		// Creating a dependency on the first variant is ok since this is a no-op in Soong
+		// Creating a dependency on the first variant that matches (os,arch) is ok since this is a no-op in Soong
 		// The primary function of this dependency is to create a connected graph in the corresponding bp2build workspace
-		ctx.AddFarVariationDependencies([]blueprint.Variation{}, nil, cc)
+		ctx.AddFarVariationDependencies(ctx.Target().Variations(), nil, cc)
 	}
 }