2015-11-03 01:43:11 +01:00
|
|
|
// Copyright 2015 Google Inc. All rights reserved.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
2016-05-19 00:37:25 +02:00
|
|
|
package android
|
2015-11-03 01:43:11 +01:00
|
|
|
|
|
|
|
import (
|
2020-02-07 02:01:55 +01:00
|
|
|
"reflect"
|
|
|
|
|
2015-11-03 01:43:11 +01:00
|
|
|
"github.com/google/blueprint"
|
|
|
|
"github.com/google/blueprint/proptools"
|
|
|
|
)
|
|
|
|
|
2016-04-12 00:06:20 +02:00
|
|
|
type defaultsDependencyTag struct {
|
|
|
|
blueprint.BaseDependencyTag
|
|
|
|
}
|
|
|
|
|
|
|
|
var DefaultsDepTag defaultsDependencyTag
|
|
|
|
|
2015-11-03 01:43:11 +01:00
|
|
|
type defaultsProperties struct {
|
|
|
|
Defaults []string
|
|
|
|
}
|
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
type DefaultableModuleBase struct {
|
2020-02-07 02:01:55 +01:00
|
|
|
defaultsProperties defaultsProperties
|
|
|
|
defaultableProperties []interface{}
|
|
|
|
defaultableVariableProperties interface{}
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
func (d *DefaultableModuleBase) defaults() *defaultsProperties {
|
2015-11-03 01:43:11 +01:00
|
|
|
return &d.defaultsProperties
|
|
|
|
}
|
|
|
|
|
2020-02-07 02:01:55 +01:00
|
|
|
func (d *DefaultableModuleBase) setProperties(props []interface{}, variableProperties interface{}) {
|
2015-11-03 01:43:11 +01:00
|
|
|
d.defaultableProperties = props
|
2020-02-07 02:01:55 +01:00
|
|
|
d.defaultableVariableProperties = variableProperties
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
|
2019-07-24 13:26:14 +02:00
|
|
|
// Interface that must be supported by any module to which defaults can be applied.
|
2015-11-03 01:43:11 +01:00
|
|
|
type Defaultable interface {
|
2019-07-24 13:26:14 +02:00
|
|
|
// Get a pointer to the struct containing the Defaults property.
|
2015-11-03 01:43:11 +01:00
|
|
|
defaults() *defaultsProperties
|
2019-07-24 13:26:14 +02:00
|
|
|
|
|
|
|
// Set the property structures into which defaults will be added.
|
2020-02-07 02:01:55 +01:00
|
|
|
setProperties(props []interface{}, variableProperties interface{})
|
2019-07-24 13:26:14 +02:00
|
|
|
|
|
|
|
// Apply defaults from the supplied Defaults to the property structures supplied to
|
|
|
|
// setProperties(...).
|
2016-08-09 21:00:45 +02:00
|
|
|
applyDefaults(TopDownMutatorContext, []Defaults)
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
type DefaultableModule interface {
|
|
|
|
Module
|
|
|
|
Defaultable
|
|
|
|
}
|
2015-11-03 01:43:11 +01:00
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
var _ Defaultable = (*DefaultableModuleBase)(nil)
|
2015-11-03 01:43:11 +01:00
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
func InitDefaultableModule(module DefaultableModule) {
|
2020-02-07 02:01:55 +01:00
|
|
|
if module.(Module).base().module == nil {
|
|
|
|
panic("InitAndroidModule must be called before InitDefaultableModule")
|
|
|
|
}
|
|
|
|
module.setProperties(module.(Module).GetProperties(), module.(Module).base().variableProperties)
|
2015-11-03 01:43:11 +01:00
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
module.AddProperties(module.defaults())
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
|
2019-07-24 14:45:05 +02:00
|
|
|
// The Defaults_visibility property.
|
|
|
|
type DefaultsVisibilityProperties struct {
|
|
|
|
|
|
|
|
// Controls the visibility of the defaults module itself.
|
|
|
|
Defaults_visibility []string
|
|
|
|
}
|
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
type DefaultsModuleBase struct {
|
|
|
|
DefaultableModuleBase
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
|
|
|
|
// Container for defaults of the common properties
|
|
|
|
commonProperties commonProperties
|
2019-07-24 14:45:05 +02:00
|
|
|
|
|
|
|
defaultsVisibilityProperties DefaultsVisibilityProperties
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
|
2019-05-24 12:00:30 +02:00
|
|
|
// The common pattern for defaults modules is to register separate instances of
|
|
|
|
// the xxxProperties structs in the AddProperties calls, rather than reusing the
|
|
|
|
// ones inherited from Module.
|
|
|
|
//
|
|
|
|
// The effect is that e.g. myDefaultsModuleInstance.base().xxxProperties won't
|
|
|
|
// contain the values that have been set for the defaults module. Rather, to
|
|
|
|
// retrieve the values it is necessary to iterate over properties(). E.g. to get
|
|
|
|
// the commonProperties instance that have the real values:
|
|
|
|
//
|
|
|
|
// d := myModule.(Defaults)
|
|
|
|
// for _, props := range d.properties() {
|
|
|
|
// if cp, ok := props.(*commonProperties); ok {
|
|
|
|
// ... access property values in cp ...
|
|
|
|
// }
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// The rationale is that the properties on a defaults module apply to the
|
|
|
|
// defaultable modules using it, not to the defaults module itself. E.g. setting
|
|
|
|
// the "enabled" property false makes inheriting modules disabled by default,
|
|
|
|
// rather than disabling the defaults module itself.
|
2015-11-03 01:43:11 +01:00
|
|
|
type Defaults interface {
|
2016-07-27 19:15:06 +02:00
|
|
|
Defaultable
|
2019-07-24 13:26:14 +02:00
|
|
|
|
|
|
|
// Although this function is unused it is actually needed to ensure that only modules that embed
|
|
|
|
// DefaultsModuleBase will type-assert to the Defaults interface.
|
2015-11-03 01:43:11 +01:00
|
|
|
isDefaults() bool
|
2019-07-24 13:26:14 +02:00
|
|
|
|
|
|
|
// Get the structures containing the properties for which defaults can be provided.
|
2015-11-03 01:43:11 +01:00
|
|
|
properties() []interface{}
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
|
2020-02-07 02:01:55 +01:00
|
|
|
productVariableProperties() interface{}
|
|
|
|
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
// Return the defaults common properties.
|
|
|
|
common() *commonProperties
|
2019-07-24 14:45:05 +02:00
|
|
|
|
|
|
|
// Return the defaults visibility properties.
|
|
|
|
defaultsVisibility() *DefaultsVisibilityProperties
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
func (d *DefaultsModuleBase) isDefaults() bool {
|
2015-11-03 01:43:11 +01:00
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
2019-07-24 13:51:21 +02:00
|
|
|
type DefaultsModule interface {
|
|
|
|
Module
|
|
|
|
Defaults
|
|
|
|
}
|
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
func (d *DefaultsModuleBase) properties() []interface{} {
|
2016-07-27 19:15:06 +02:00
|
|
|
return d.defaultableProperties
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
|
2020-02-07 02:01:55 +01:00
|
|
|
func (d *DefaultsModuleBase) productVariableProperties() interface{} {
|
|
|
|
return d.defaultableVariableProperties
|
|
|
|
}
|
|
|
|
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
func (d *DefaultsModuleBase) common() *commonProperties {
|
|
|
|
return &d.commonProperties
|
|
|
|
}
|
|
|
|
|
2019-07-24 14:45:05 +02:00
|
|
|
func (d *DefaultsModuleBase) defaultsVisibility() *DefaultsVisibilityProperties {
|
|
|
|
return &d.defaultsVisibilityProperties
|
|
|
|
}
|
|
|
|
|
2019-06-10 22:12:56 +02:00
|
|
|
func (d *DefaultsModuleBase) GenerateAndroidBuildActions(ctx ModuleContext) {
|
|
|
|
}
|
|
|
|
|
2019-07-24 13:51:21 +02:00
|
|
|
func InitDefaultsModule(module DefaultsModule) {
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
commonProperties := module.common()
|
|
|
|
|
2017-06-24 00:06:31 +02:00
|
|
|
module.AddProperties(
|
2016-05-18 01:34:16 +02:00
|
|
|
&hostAndDeviceProperties{},
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
commonProperties,
|
2019-12-02 05:08:53 +01:00
|
|
|
&ApexProperties{})
|
2016-05-18 01:34:16 +02:00
|
|
|
|
2020-02-07 02:01:55 +01:00
|
|
|
initAndroidModuleBase(module)
|
|
|
|
initProductVariableModule(module)
|
2017-06-24 00:06:31 +02:00
|
|
|
InitArchModule(module)
|
2017-07-07 23:33:33 +02:00
|
|
|
InitDefaultableModule(module)
|
2016-05-18 01:34:16 +02:00
|
|
|
|
2019-07-24 13:26:14 +02:00
|
|
|
// Add properties that will not have defaults applied to them.
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
base := module.base()
|
2019-07-24 14:45:05 +02:00
|
|
|
defaultsVisibility := module.defaultsVisibility()
|
|
|
|
module.AddProperties(&base.nameProperties, defaultsVisibility)
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
|
2019-07-24 14:45:05 +02:00
|
|
|
// The defaults_visibility property controls the visibility of a defaults module.
|
|
|
|
base.primaryVisibilityProperty =
|
|
|
|
newVisibilityProperty("defaults_visibility", &defaultsVisibility.Defaults_visibility)
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
|
|
|
|
// Unlike non-defaults modules the visibility property is not stored in m.base().commonProperties.
|
|
|
|
// Instead it is stored in a separate instance of commonProperties created above so use that.
|
|
|
|
// The visibility property needs to be checked (but not parsed) by the visibility module during
|
|
|
|
// its checking phase and parsing phase.
|
|
|
|
base.visibilityPropertyInfo = []visibilityProperty{
|
2019-07-24 14:45:05 +02:00
|
|
|
base.primaryVisibilityProperty,
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
newVisibilityProperty("visibility", &commonProperties.Visibility),
|
|
|
|
}
|
2016-05-18 01:34:16 +02:00
|
|
|
|
Refactor visibility to support visibility on defaults modules
Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.
The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.
The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
module and those that do not. It checks and gathers all of them with
the last property gathered overriding the rules for the previous
properties.
2) It relies on overriding methods in MethodBase in order to change the
default behavior for the package module. That works because
packageModule embeds ModuleBase but will not work for
DefaultsModuleBase as it does not embed ModuleBase and instead is
embedded alongside it so attempting to override a method in
MethodBase leads to ambiguity.
This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
primary visibility rules, i.e. the ones that affect the module.
2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
to provide information about all the properties that need checking,
and 'primaryVisibilityProperty visibilityProperty' to specify the
property that affects the module.
The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.
The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().
Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.
Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef
2019-07-24 15:24:38 +02:00
|
|
|
base.module = module
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
var _ Defaults = (*DefaultsModuleBase)(nil)
|
2015-11-03 01:43:11 +01:00
|
|
|
|
2017-07-07 23:33:33 +02:00
|
|
|
func (defaultable *DefaultableModuleBase) applyDefaults(ctx TopDownMutatorContext,
|
2016-08-09 21:00:45 +02:00
|
|
|
defaultsList []Defaults) {
|
|
|
|
|
|
|
|
for _, defaults := range defaultsList {
|
|
|
|
for _, prop := range defaultable.defaultableProperties {
|
2020-02-07 02:01:55 +01:00
|
|
|
if prop == defaultable.defaultableVariableProperties {
|
|
|
|
defaultable.applyDefaultVariableProperties(ctx, defaults, prop)
|
|
|
|
} else {
|
|
|
|
defaultable.applyDefaultProperties(ctx, defaults, prop)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Product variable properties need special handling, the type of the filtered product variable
|
|
|
|
// property struct may not be identical between the defaults module and the defaultable module.
|
|
|
|
// Use PrependMatchingProperties to apply whichever properties match.
|
|
|
|
func (defaultable *DefaultableModuleBase) applyDefaultVariableProperties(ctx TopDownMutatorContext,
|
|
|
|
defaults Defaults, defaultableProp interface{}) {
|
|
|
|
if defaultableProp == nil {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
defaultsProp := defaults.productVariableProperties()
|
|
|
|
if defaultsProp == nil {
|
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
dst := []interface{}{
|
|
|
|
defaultableProp,
|
|
|
|
// Put an empty copy of the src properties into dst so that properties in src that are not in dst
|
|
|
|
// don't cause a "failed to find property to extend" error.
|
|
|
|
proptools.CloneEmptyProperties(reflect.ValueOf(defaultsProp)).Interface(),
|
|
|
|
}
|
|
|
|
|
|
|
|
err := proptools.PrependMatchingProperties(dst, defaultsProp, nil)
|
|
|
|
if err != nil {
|
|
|
|
if propertyErr, ok := err.(*proptools.ExtendPropertyError); ok {
|
|
|
|
ctx.PropertyErrorf(propertyErr.Property, "%s", propertyErr.Err.Error())
|
|
|
|
} else {
|
|
|
|
panic(err)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
func (defaultable *DefaultableModuleBase) applyDefaultProperties(ctx TopDownMutatorContext,
|
|
|
|
defaults Defaults, defaultableProp interface{}) {
|
|
|
|
|
|
|
|
for _, def := range defaults.properties() {
|
|
|
|
if proptools.TypeEqual(defaultableProp, def) {
|
|
|
|
err := proptools.PrependProperties(defaultableProp, def, nil)
|
|
|
|
if err != nil {
|
|
|
|
if propertyErr, ok := err.(*proptools.ExtendPropertyError); ok {
|
|
|
|
ctx.PropertyErrorf(propertyErr.Property, "%s", propertyErr.Err.Error())
|
|
|
|
} else {
|
|
|
|
panic(err)
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-07 23:35:50 +02:00
|
|
|
func RegisterDefaultsPreArchMutators(ctx RegisterMutatorsContext) {
|
2017-07-13 23:43:27 +02:00
|
|
|
ctx.BottomUp("defaults_deps", defaultsDepsMutator).Parallel()
|
|
|
|
ctx.TopDown("defaults", defaultsMutator).Parallel()
|
|
|
|
}
|
|
|
|
|
2016-05-19 00:37:25 +02:00
|
|
|
func defaultsDepsMutator(ctx BottomUpMutatorContext) {
|
2015-11-03 01:43:11 +01:00
|
|
|
if defaultable, ok := ctx.Module().(Defaultable); ok {
|
2016-04-12 00:06:20 +02:00
|
|
|
ctx.AddDependency(ctx.Module(), DefaultsDepTag, defaultable.defaults().Defaults...)
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-09 21:00:45 +02:00
|
|
|
func defaultsMutator(ctx TopDownMutatorContext) {
|
|
|
|
if defaultable, ok := ctx.Module().(Defaultable); ok && len(defaultable.defaults().Defaults) > 0 {
|
|
|
|
var defaultsList []Defaults
|
2018-06-21 00:19:39 +02:00
|
|
|
seen := make(map[Defaults]bool)
|
|
|
|
|
2017-10-24 02:59:01 +02:00
|
|
|
ctx.WalkDeps(func(module, parent Module) bool {
|
2016-08-09 21:00:45 +02:00
|
|
|
if ctx.OtherModuleDependencyTag(module) == DefaultsDepTag {
|
|
|
|
if defaults, ok := module.(Defaults); ok {
|
2018-06-21 00:19:39 +02:00
|
|
|
if !seen[defaults] {
|
|
|
|
seen[defaults] = true
|
|
|
|
defaultsList = append(defaultsList, defaults)
|
|
|
|
return len(defaults.defaults().Defaults) > 0
|
|
|
|
}
|
2016-08-09 21:00:45 +02:00
|
|
|
} else {
|
|
|
|
ctx.PropertyErrorf("defaults", "module %s is not an defaults module",
|
|
|
|
ctx.OtherModuleName(module))
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
2016-08-09 21:00:45 +02:00
|
|
|
}
|
|
|
|
return false
|
|
|
|
})
|
|
|
|
defaultable.applyDefaults(ctx, defaultsList)
|
2015-11-03 01:43:11 +01:00
|
|
|
}
|
|
|
|
}
|