Structured configuration allows developers to package components with different values in different contexts. Product assembly allows developers to define structured configuration values based on high-level platform and product configuration.
To vary your component‘s configuration by product or build type you must declare a schema, identify how values will be derived from a product’s configuration, and generate your component's config.
Warning: this feature is under active development. If you have any questions when following this guide, ask in the Product Assembly chat or schedule a slot in product assembly office hours.
Your component must have a declared configuration schema in its manifest. For example:
config: { enable_foo: { type: "bool" }, },
For more information see the documentation for structured config.
Many configuration options can be represented as the difference between engineering builds and non-engineering builds. If the configuration of your component can‘t be deduced solely from build type, schedule a slot in product assembly office hours and decide on how your component’s configuration will be represented in the product assembly configuration.
Determine your package‘s name and your component’s manifest resource path. Define logic to populate configuration for it in the product assembly tool:
patches .package("configured_by_assembly") .component("meta/to_configure.cm") .field("enable_foo", matches!(self.platform.build_type, BuildType::Eng));
Note: You cannot mix GN and product assembly when producing configuration values for a given component.
Product assembly tools are replacing the existing GN-based method for configuring system images, and during that transition there are a number of consistency checks to ensure that GN and product assembly produce identical outputs.
You must add your package's name to a list of exceptions because using product assembly for configuration results in different package contents.
When producing configuration values for a package, product assembly must write its outputs to a different location in the build directory. There are binary size checks that rely on paths to package manifests that exist in the build directory, so it is important that you update the package's output path in the build configuration rules.
See this diff for an example of changing session_manager's size limit configuration to match the new location.