Commit graph

5 commits

Author SHA1 Message Date
Paul Duffin
74fc190d90 Dedup adding of arch/common properties to cc library snapshot
Some additional, possibly arch specific, properties need adding to
cc library (e.g. recovery_available). This dedups and cleans up the
code involved to simply the addition of those new properties.

Bug: 142918168
Test: m nothing
Change-Id: I0963aa02e9504af1ae9b427ff1016e7c481465f4
2020-02-04 18:48:31 +00:00
Paul Duffin
e602918294 Restrict SdkMemberTypes that can be used with sdk/sdk_snapshot
By default SdkMemberTypes are only supported on module_exports module
type. Support for sdk module type has to be explicitly specified.

The java_header_libs, native_shared_libs and stubs_sources are
supported on sdk. The latter is required to provide the stubs source
for an API specified in java_header_libs as they should be kept in
sync.

Bug: 146341462
Test: m nothing
Change-Id: I19b9e60792780a797458d4a9e489506602b13144
2019-12-31 15:08:59 +00:00
Paul Duffin
a0843f6a6f Differentiate between cc library and binary
The cc library and cc binary (and other cc module types) are all
instances of cc.Module. So, to differentiate between them and make
sure that only appropriate library instances can be added to
native_shared/static_libs this adds a special sdkMemberTypes field to
Module which if set specifies the SdkMemberTypes the module supports.
If it is not set then the module type cannot be used in the sdk at all.

Corrects an issue with one of the tests where a prebuilt cc
library was added to the sdk instead of a source cc library.

Adds a new test to ensure that cc_library_(shared|static)_host module
types work with the sdk as well and another test to ensure that
cc_library can be used as either.

Bug: 142918168
Test: m checkbuild
Change-Id: I359cdbdd15328ca571f276d2b6ce9a229ebb2c86
2019-12-20 15:45:17 +00:00
Paul Duffin
255f18e584 Decouple addition of new sdk member types from sdk code
Previously, adding a new SdkMemberType would require adding a new
sdkMemberListProperty instance to the sdkMemberListProperties as well
as adding a new property into the sdkProperties struct. They are
potential sources of conflict and couple the sdk code with all the
packages that add members to it. This change switched to a
registration model that allows each package to register its sdk
member types decoupling them from the sdk code.

Adds an SdkPropertyName() method to SdkMemberType that specifies the
name of the property to use in the sdk/sdk_snapshot. Also provides
an SdkMemberTypeBase struct to be used by providers of SdkMemberType
implementations.

SdkMemberType instances are registered using the
RegisterSdkMemberType() func which sorts the registered instances
by their SdkPropertyName() to ensure the behavior is consistent and
not affected by order of registration.

When creating a new sdk module a dynamicSdkMemberTypes instance is
created that contains the following:

* A properties struct is created dynamically that contains a field for
  each registered SdkMemberType, corresponding to that type's
  SdkPropertyName().

* A list of sdkMemberListProperty instances is also created, one for
  each registered SdkMemberType.

The dynamicSdkMemberTypes instance is cached using a key that uniquely
identifies the set of registered types just in case new types are
registered after one has been created, e.g. by tests.

Bug: 142918168
Test: m checkbuild
Change-Id: I4bf2bf56a2a49025aa41454048bc1e8ccc6baca2
2019-12-13 20:07:33 +00:00
Paul Duffin
2f6bc09fee Separate sdk membership support out of cc/library.go
Bug: 142918168
Test: m checkbuild
Change-Id: I4a7f2af8e0b41feca2b5a431b42ad03bbfe94b0c
2019-12-13 10:43:10 +00:00