It is expected that a GN build configuration include exactly one board GNI
file, and one product GNI file. In fx this pair is the primary argument
fx set command.
In a Fuchsia GN build configuration the board is always included first. The board starts the definition of three dependency lists that are then augmented by the imported product (and later, optional GN inclusions). Those list are Base, Cache and Universe respectively, and are defined below.
A board defines the architecture that the build produces for, as well as key features of the device upon which the build is intended to run. This configuration affects what drivers are included, and may also influence device-specific kernel parameters.
The available boards can be listed using
A product defines the software configuration that a build will produce. Most critically, a product typically defines the kinds of user experiences that are provided for, such as what kind of graphical shell the user might observe, whether or not multimedia support is included, and so on.
The available products can be listed using
Boards define, and products augment three lists of dependencies, Base, Cache and Universe. These dependencies are GN labels that ultimately contribute packages to various system artifacts, such as disk images and signed package metadata, as well as various development artifacts such as host tools and tests.
base dependency list contributes packages to disk images and system
updates as well as the package repository. A package included by the
dependency set takes precedence over a duplicate membership in the
dependency set. Base packages in a system configuration are considered system
and security critical. They are updated as an atomic unit and are never
evicted at runtime regardless of resource pressure.
cache dependency list contributes packages that are pre-cached in the
disk image artifacts of the build, and will also be made available in the
package repository. These packages are not added to the system updates, but
would instead be updated ephemerally. Cached packages can also be evicted
from running systems in order to free resources based on runtime resource
universe dependency list contributes packages to the package repository
only. These packages will be available for runtime caching and updating, but
are not found in system update images nor are they pre-cached in any disk
images. All members of
cache are inherently also members of
Key Product Configurations
There are many more than below, but the following three particularly important configurations to be familiar with:
bringup product is the most minimal viable target for development.
Because it lacks most network capabilities, the
cannot use the
fx commands, such as
fx serve and
that require network connectivity.
For more see Bringup Product Definition
core is a minimal feature set that can install additional software (such as
items added to the "universe" dependency set). It is the starting point for
all higher-level product configurations. It has common network capabilities
and can update a system over-the-air.
As described in RFC-0220, Minimal is intended to be "the smallest thing which can be called Fuchsia." Definitionally, this is a system which can:
- Boot into userspace.
- Run Component Manager and components.
- Update itself using Fuchsia's over-the-air update system. (This implies that storage and networking are working, with drivers provided by the board.)
Workbench is a product configuration for local development, running larger tests which cannot or should not be packaged hermetically, and exercising larger parts of the Fuchsia platform than minimal supports. It is intended to be like a literal workbench in that it supports development tools and allows a developer to poke at the system and make changes. It is not intended to be a product that ships to users, or be a basis for those products.