Parameterize the sdk member processing
Extracts the type specific functionality into the SdkMemberType
interface which has to be implemented by each module type that can
be added as a member of the sdk. It provides functionality to add
the required dependencies for the module type, check to see if a
resolved module is the correct instance and build the snapshot.
The latter was previously part of SdkAware but was moved because
it has to be able to process multiple SdkAware variants so delegating
it to a single instance did not make sense.
The custom code for handling each member type specific property,
e.g. java_libs, has been replaced with common code that processes
a list of sdkMemberListProperty struct which associates the
property (name and getter) with the SdkMemberType and a special
DependencyTag which is passed to the SdkMemberType when it has to add
dependencies.
The DependencyTag contains a reference to the appropriate
sdkMemberListProperty which allows the resolved dependencies to be
grouped by type.
Previously, the dependency collection methods would ignore a module if
it was an unsupported type because they did not have a way of
determining which property it was initially listed in. That meant it
was possible to add say a droidstubs module to the java_libs property
(and because they had the same variants) it would work as if it was
added to the stubs_sources property. Or alternatively, a module of an
unsupported type could be added to any property and it would just be
ignored.
However, the DependencyTag provides information about which property
a resolved module was referenced in and so it can detect when the
resolved module is of the wrong type and report an error. That check
identified a bug in one of the tests where the sdk referenced a
java_import module (which is not allowed in an sdk) instead of a
java_library module (which is allowed). That test was fixed as part
of this.
A list of sdkMemberListProperty structs defines the member properties
supported by the sdk and are processed in order to ensure consistent
behaviour.
The resolved dependencies are grouped by type and each group is then
processed in defined order. Within each type dependencies are grouped
by name and encapsulated behind an SdkMember interface which includes
the name and the list of variants.
The Droidstubs and java.Library types can only support one variant and
will fail if given more.
The processing for the native_shared_libs property has been moved into
the cc/library.go file so the sdk package code should now have no type
specific information in it apart from what is if the list of
sdkMemberListProperty structs.
Bug: 143678475
Test: m conscrypt-module-sdk
Change-Id: I10203594d33dbf53441f655aff124f9ab3538d87
diff --git a/android/sdk.go b/android/sdk.go
index 01e18ed..b9220ca 100644
--- a/android/sdk.go
+++ b/android/sdk.go
@@ -17,6 +17,7 @@
import (
"strings"
+ "github.com/google/blueprint"
"github.com/google/blueprint/proptools"
)
@@ -31,9 +32,6 @@
MemberName() string
BuildWithSdks(sdks SdkRefs)
RequiredSdks() SdkRefs
-
- // Build a snapshot of the module.
- BuildSnapshot(sdkModuleContext ModuleContext, builder SnapshotBuilder)
}
// SdkRef refers to a version of an SDK
@@ -203,3 +201,56 @@
type BpModule interface {
BpPropertySet
}
+
+// An individual member of the SDK, includes all of the variants that the SDK
+// requires.
+type SdkMember interface {
+ // The name of the member.
+ Name() string
+
+ // All the variants required by the SDK.
+ Variants() []SdkAware
+}
+
+// Interface that must be implemented for every type that can be a member of an
+// sdk.
+//
+// The basic implementation should look something like this, where ModuleType is
+// the name of the module type being supported.
+//
+// var ModuleTypeSdkMemberType = newModuleTypeSdkMemberType()
+//
+// func newModuleTypeSdkMemberType() android.SdkMemberType {
+// return &moduleTypeSdkMemberType{}
+// }
+//
+// type moduleTypeSdkMemberType struct {
+// }
+//
+// ...methods...
+//
+type SdkMemberType interface {
+ // Add dependencies from the SDK module to all the variants the member
+ // contributes to the SDK. The exact set of variants required is determined
+ // by the SDK and its properties. The dependencies must be added with the
+ // supplied tag.
+ //
+ // The BottomUpMutatorContext provided is for the SDK module.
+ AddDependencies(mctx BottomUpMutatorContext, dependencyTag blueprint.DependencyTag, names []string)
+
+ // Return true if the supplied module is an instance of this member type.
+ //
+ // This is used to check the type of each variant before added to the
+ // SdkMember. Returning false will cause an error to be logged expaining that
+ // the module is not allowed in whichever sdk property it was added.
+ IsInstance(module Module) bool
+
+ // Build the snapshot for the SDK member
+ //
+ // The ModuleContext provided is for the SDK module, so information for
+ // variants in the supplied member can be accessed using the Other... methods.
+ //
+ // The SdkMember is guaranteed to contain variants for which the
+ // IsInstance(Module) method returned true.
+ BuildSnapshot(sdkModuleContext ModuleContext, builder SnapshotBuilder, member SdkMember)
+}