StrixOS/build_soong
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Delegate work of apexInfoMutator to ApexInfoMutator interface

Browse Source 
Refactor the apexInfoMutator to delegate the work to an implementation
of ApexInfoMutator and then move the existing functionality into the
apexBundle.ApexInfoMutator(). This will allow a follow up change to
customize the behavior of this mutator for prebuilt_apex modules.

Test: m nothing
Bug: 171061220
Change-Id: I7ccd55818e02a606c5494e215f4370b635ddd0a5
This commit is contained in:
Paul Duffin
2020-12-07 17:39:59 +00:00
parent 90f5c1d5d6
commit a7d6a89774
1 changed files with 23 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
apex/apex.go
View File

@@ -728,7 +728,9 @@ type ApexBundleInfo struct {
var ApexBundleInfoProvider = blueprint.NewMutatorProvider(ApexBundleInfo{}, "apex_info")
// apexInfoMutator is responsible for collecting modules that need to have apex variants. They are
var _ ApexInfoMutator = (*apexBundle)(nil)
// ApexInfoMutator is responsible for collecting modules that need to have apex variants. They are
// identified by doing a graph walk starting from an apexBundle. Basically, all the (direct and
// indirect) dependencies are collected. But a few types of modules that shouldn't be included in
// the apexBundle (e.g. stub libraries) are not collected. Note that a single module can be depended
@@ -739,15 +741,7 @@ var ApexBundleInfoProvider = blueprint.NewMutatorProvider(ApexBundleInfo{}, "ape
// The apexMutator uses that list to create module variants for the apexes to which it belongs.
// The relationship between module variants and apexes is not one-to-one as variants will be
// shared between compatible apexes.
func apexInfoMutator(mctx android.TopDownMutatorContext) {
if !mctx.Module().Enabled() {
return
}
a, ok := mctx.Module().(*apexBundle)
if !ok {
return
}
func (a *apexBundle) ApexInfoMutator(mctx android.TopDownMutatorContext) {
// The VNDK APEX is special. For the APEX, the membership is described in a very different
// way. There is no dependency from the VNDK APEX to the VNDK libraries. Instead, VNDK
@@ -826,6 +820,25 @@ func apexInfoMutator(mctx android.TopDownMutatorContext) {
})
}
type ApexInfoMutator interface {
// ApexInfoMutator implementations must call BuildForApex(ApexInfo) on any modules that are
// depended upon by an apex and which require an apex specific variant.
ApexInfoMutator(android.TopDownMutatorContext)
}
// apexInfoMutator delegates the work of identifying which modules need an ApexInfo and apex
// specific variant to modules that support the ApexInfoMutator.
func apexInfoMutator(mctx android.TopDownMutatorContext) {
if !mctx.Module().Enabled() {
return
}
if a, ok := mctx.Module().(ApexInfoMutator); ok {
a.ApexInfoMutator(mctx)
return
}
}
// apexUniqueVariationsMutator checks if any dependencies use unique apex variations. If so, use
// unique apex variations for this module. See android/apex.go for more about unique apex variant.
// TODO(jiyong): move this to android/apex.go?