We are currently migrating to this source code layout. Some aspects of this document reflect the current reality, but some aspects are still aspirational.
Most first-party, open-source code is in the “fuchsia.git” repository. Most code in this repository is organized into a recursive tree of areas.
Areas have a regular internal and dependency structure. The
fuchsia.git repository itself follows the structure of an area, but also has additional structure unique to the top level.
src top level directory of
fuchsia.git can be considered the root area. It follows the structure required of an area, and is the place where sub areas are located. However, some directories required of an area also exist next to
src rather than inside it, e.g.
third_party. These can be thought of global ones for all areas to depend on. There are also other places outside
src that hold further top-level areas, e.g. in
vendor/*. Being open source code
third_party is available to all areas.
Source repositories, whether open- or closed-source, also follow the conventions for areas and are mapped into subdirectories of
src in fuchsia.git. Currently, we have small number of such “petal” repositories, but we will “promote” areas currently in the
fuchsia.git repository into separate repositories as the system stabilizes.
vendor/* directories contain closed-source code, organized by the vendor of that code. Nothing outside of
//vendor can depend on
//vendor. Dependencies between different vendors is supported,
vendor/A can have a depency on
products directory contains a list of products that you can build. Some products are quite small and build quickly (e.g., the core product), whereas others are more elaborate (e.g., the workstation product).
Most third-party dependencies are stored in separate repositories. These repositories are included in a local checkout only when needed to support one of the following source tree configurations:
Most code is organized into a recursive tree of areas. Each area has a regular internal and dependency structure, which helps people understand code structure across the whole project.
Each area is required to have an OWNERS file as well as documentation and tests. Areas can also include binaries, libraries, drivers, and other source code. In addition, areas can have subareas, which repeat the pattern:
testsbundle with unit tests for the area, but may include other bundles.
Areas may use additional directories for internal organization in addition to the enumerated directories.
A directory inside an area that contains an
OWNERS file is considered a subarea and must adhere to the contract for areas. A directory lacking an
OWNERS file is considered part of the same area.
fuchsia.git repository, there exist directories with
OWNERS that are not considered areas, e.g. the top level
products directory, or subdirectories of the
One exception is the
//src/tests directory where tests from different areas that cover multiple aspects of the system (not just a particular area) are expected to live. Because of this, every area should add OWNERS files for any tests that live in this directory.
In addition to depending on itself, an area can depend only on the top-level
third_party directories, as well as the
lib directories of its ancestors:
Targets in an area that are marked testonly in the build system may additionally depend on the
testing directory in that area and ancestors:
(../)+testing/(testonly=true targets only)
Each area and subarea must define the following canonical targets in their top-level BUILD.gn file:
This section depicts the directory layout for the Fuchsia Source Tree. Non-bold entries are directories or files in the fuchsia.git repository. Bold entries are separate repositories that are mapped into the directory structure using
jiri (except for the prebuilt directory, which is populated from CIPD).
[closed-source code from various vendors]
As the system stabilizes, we can promote areas out of fuchsia.git into separate repositories. Generally, we should promote an area to a separate repository when the interface between the area and the rest of the system is sufficiently stable (requires approval by top-level OWNERS).
New code can be: