Project Structure
The build system borrows terminology from the Buck2 build system.
A project:
- has a project directory.
- is a container for cells (more on this shortly)
A cell is:
- a subdivision of the project source code
- there is at least one subdivision called
root - build system implementations define the cells using conventions, project configuration files, and/or command-line options.
- there is at least one subdivision called
Cells exist to make efficient builds and to locating source code even when source code is vendored.
- In small projects the
rootmay be the only cell; all project source code belongs toroot. - In large projects (ex. monorepos), the project tree can be broken into smaller cells. Only parts of the build that depend on smaller cells will be rebuilt when a single project source file changes.
However, since cells must be given on the command line or some other user-specific configuration file, a distributed package for use by other packages should never use cells. Instead workspace scripts have workspace assets that can be used.
Workspace script
Section titled “Workspace script”When a build system command that takes a unified script (for example dk0 test <script> or dk0 distribute <script>) runs, the workspace script is the first unified script — searched in the order below — that contains a ## workspace section:
- The user
<script>itself. - A file named
dk.uin the directory containing<script>, if it exists. - A file named
dk.uin the first ancestor directory of<script>that contains one.
Having a workspace makes available:
- importing third party distributions
- workspace-scoped assets. The workspace script's unified.asset declarations in non-workspace sections are available to the user
<script>.