Unlike most module types, config variable handling is always namespaced
to the Android.bp file, which limits reuse of the variable definitions.
Additionally multiple of these module types can define a string variable
in the same config namespace, but specify different valid values for the
string.
Previously, we cached the first instance we see of variable + namespace;
however, this caused non-determinism in which defintion would be used
and not migrating all values. Instead, we now only cache within a single
Android.bp file where the variable definitions are re-used.
Test: go tests
Bug: 271481817
Change-Id: Ic327657c508e47a705bacd24712a1916e105c7cd
Previously, the soong_config_module_type (and related module types)
would make a special call to the module factory of the module type
being customized to get the properties from which it created the
conditional properties. That caused problems when trying to customize
a singleton module. See the bug for more details.
This change avoids that special call by deferring the creation of the
conditional properties struct until just after the
soong_config_module_type's factory function calls the customized module
factory to create the module and properties. The properties are then
used to create the conditional properties struct avoiding the extra
factory call.
The conditional properties struct is only created once per module type
that soong_config_module_type (and related module types) creates.
Bug: 264876909
Test: m nothing
Change-Id: I55dc71d2553cb59d921a96c6458d0bc877512bbb
This refactoring prepares for introduction of bazel prod mode, an
alternative mechanism for mixed builds allowlist handling.
* Decide bazel-mode as close to soong_build main as possible
* BazelContext itself decides whether a module is allowlisted
* Separate bp2build and mixed build allowlist
Test: m nothing, manually verified all modules are mixed build disabled
(via metrics)
Test: USE_BAZEL_ANALYSIS=1 m nothing, manually verified that mixed build
disabled/enabled modules are identical before and after change.
Change-Id: I0f55d8b85000cb4a871a099edc6d7d868d7df509
Nameless modules still have to have unique names to avoid collisions
when sorting by name. Give them all pointer suffixes, and rename
NamelessModule to NamespacelessModule
Fixes: 235475711
Test: soong_config_modules_test.go
Change-Id: Ib2d34e8bcbb4f988bf00c1012511494f54d9a53e
Also remove the need to use bp2build_available on
soong_config_module_types as we want to convert every single of them
into the tree for a complete soong_injection soong_config_variables.bzl
file.
The variables are split into their bool, value and string types
respectively, as they all need to be handled differently on the Bazel
product_platform side, as well as for generating constraint values and
settings. For example, value variables need to integrate with
TemplateVariableInfo, and string variables need to include the string
value itself into the select key/constraint value.
Sample soong_config_variables.bzl file: https://gist.github.com/jin/cef700bfb20c8656a931306dd71d47e1
Test: CI
Bug: 198556411
Change-Id: I8665dd1269a507edb37de62407ed3641564bea5c
select statements.
This supports defaults from the same or different namespaces, and
transitively defaults as well.
Test: soong unit tests
Test: CI
Change-Id: I99435bacfcfbfe20ad753b8021a1779531d7595a
Each variable can specify a conditions_default for properties to be used
when the variable is not set, not set to a true value (for bools), or is
set to a value that is not present in the module (for strings).
Test: m nothing
Test: go test soong tests
Change-Id: I76ec026da2369b407f0f530f77760f530e7958fc
blueprint.writeAllModuleActions attemts to sort modules by name, and
sorting them assumes that each module's name is unique. Although
soong_config_module_type_import modules will not generate anything,
their names should be unique, too for that reason.
Fixes: 150421585
Test: m nothing
Change-Id: I6782e42c129dc3b0fc7649ce97d5f94effc63fa7
There are some cases that aren't handled with the existing variable
types for booleans or known lists of strings. Similarly to our
product_variables that uses %s / %d for things like
PLATFORM_SDK_VERSION, allow vendors to define their own config variables
to be substituted into properties.
For example, some of the makefiles that I've attempted to convert had
the option to pass in version numbers from the board, or the default
display size:
-DDISPLAY_VERSION=550
-DDISP_H=1080
These examples happen to be integers, but since our configuration
language (make) doesn't support numbers, %s works just as well.
This change will allow the above to be represented using:
soong_config_module_type {
name: "acme_cc_defaults",
module_type: "cc_defaults",
config_namespace: "acme",
value_variables: [
"DISPLAY_VERSION",
"DISP_H",
],
properties: ["cflags"],
}
acme_cc_defaults {
name: "my_defaults",
soong_config_variables: {
DISPLAY_VERSION: {
cflags: ["-DDISPLAY_VERSION=%s"],
},
DISP_H: {
cflags: ["-DDISP_H=%s"],
}
},
}
Test: built-in tests
Change-Id: I18f35746b5cc39c304a136980249e886d38c6df6
Using a lot of boolean variables can become very verbose without adding
really any new information:
variables: ["a", "b", "c"],
}
soong_config_bool_variable {
name: "a",
}
soong_config_bool_variable {
name: "b",
}
soong_config_bool_variable {
name: "c",
}
Now turns into:
bool_variables: ["a", "b", "c"],
}
Test: built-in tests
Change-Id: If5455a38433431c7ecbce1e5b32cfbb47f42602a
Add a dependency on the Soong config module definition file in case
it wasn't called Android.bp.
Fixes: 148866376
Test: m checkbuild
Change-Id: Ib441881bcee52fd1dc3a8d1c5ae4f5f0b7efe3ce
