Skip to content

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.

Cells exist to make efficient builds and to locating source code even when source code is vendored.

  • In small projects the root may be the only cell; all project source code belongs to root.
  • 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.

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:

  1. The user <script> itself.
  2. A file named dk.u in the directory containing <script>, if it exists.
  3. A file named dk.u in the first ancestor directory of <script> that contains one.

Having a workspace makes available: