blob: 5b2a8c7cd77c40da207ecc41c957934f37de1be1 [file] [log] [blame] [view]
# Build inputs
This directory contains targets which represent the various GN arguments used to
alter the build graph.
Instead of directly using a given GN argument in a build file, add a dependency
on the matching target defined in this directory.
## Structure
The `board`, `product`, and `dev` subdirectories host targets for GN arguments
declared respectively in `//build/board.gni`, `//build/product.gni`, and
`//build/dev.gni`.
In addition, the build file in the root directory contains targets which
aggregate targets from subdirectories.
## Benefits
### Traceability
This is most obvious when using tools such as `gn path` which will show the
targets in the output paths instead of jumping from the target that needs the
GN argument straight to the labels listed in that argument.
Compare:
```
//i/am:foo --[private]-->
//this/is:bar
```
to:
```
//i/am:foo --[private]-->
//build/input/board:bootfs_deps --[public]-->
//this/is:bar
```
The latter output makes it very clear how `//this/is:bar` is introduced in the
build graph.
### Indirection
The targets defined in the root directory may combine targets from multiple
subdirectories.
This level of indirection makes it easier to introduce or remove GN arguments
without having to modifying all call sites.
For example, an aggregation target will expose all dependencies for the main
zbi; currently these dependencies are sourced from GN arguments from the board
and the product files, but in the future we may add an argument to let
developers manually add to the zbi.
Thanks to the aggregation target, this change would be invisible to the targets
actually declaring the zbi itself.