---
title: "The build directory and layers"
---

# The build directory and layers

The existing BitBake, kas or Buildroot build directory opened as the project, vendor recognition, and layers managed with bitbake-layers after a preview.

The project is the build directory that already exists on the build host: nothing is imported or converted. The **Build Directory** view in the Embedded Linux side bar reads it over SSH.

## The Build Directory view

For each build host the view shows:

- the product it recognises (Wind River Linux, NXP i.MX BSP, TI, AMD, ST OpenSTLinux, Yocto Project), from names in the vendors' own layers (for Wind River Linux: the `wrlinux*` distributions, the `wrl` layer series and `WRTEMPLATE`);
- **Machine** and **Distribution**, each with the file and line that sets it (click to open it);
- the template the build directory was created from;
- **Build Settings**, the build's main variables (see [Build configuration](https://neuralinverse.com/docs/modules/embedded-linux/build-configuration/));
- **Layers** with collection, priority, release series and dependencies;
- **Images** and **Recipes**, with the layer each comes from;
- the product's kas file when one is set, a Buildroot `.config`, and what BitBake would stop on.

**Refresh Build Directory** reads it again. Right-click entries for the actions of later pages: builds, devtool, configuration, recipe upgrades.

**State:** modelled on Linux with the real `layer.conf` and configuration files of poky, meta-freescale, meta-ti, meta-xilinx, meta-st-stm32mp, Wind River meta-lat and meta-wr-sbom, and kas's example; a Poky build directory over a local sshd; an i.MX build directory in the app (8 layers, 14 recipe files, read in 599 ms). Not compared with `bitbake-layers show-layers` on a real build, not run on a Wind River Linux install or against `setup.sh`, not run at realistic size (40 layers, 4,000 recipes), and the vendors' setup scripts are recognised, not run.

## Layers with bitbake-layers

Expanding **Layers** runs `bitbake-layers show-layers` on the build host (the first run parses every recipe). For each layer you see:

- its path, priority in `layer.conf` and in BitBake, and collection;
- `LAYERSERIES_COMPAT` against the build's release;
- `LAYERDEPENDS`, with missing dependencies flagged;
- its Git remote, branch, revision and uncommitted changes;
- the repo manifest project or kas entry it comes from.

Commands:

- **Show bbappends and Overlayed Recipes** lists `show-appends`, `show-overlayed` and overlayed classes, each opening its file from the build host.
- **Find Recipe in Layers...** searches recipes with `bitbake-layers show-recipes -f`, wildcards allowed (`linux-*`, `u-boot*`).
- **Add Layer to Build...**, **Remove Layer from Build...** and **Create Layer...** run `bitbake-layers` after a confirmation that shows the exact change to `conf/bblayers.conf`, previewed with BitBake's own editing code on a copy. Adding a layer whose dependency is missing says BitBake will refuse it; removing a layer names the layers that depend on it and offers to remove them in the same change.
- When the build was set up from a kas file or a repo manifest, the confirmation says the change also belongs there, so a build directory set up again keeps it. The module does not write kas files.

**State:** modelled with real BitBake 2.8.1 (poky scarthgap, meta-freescale and meta-openembedded) over a local sshd, every parser fixture real captured output; add, remove, create and a refused add in the running app. Not run on Windows, against a real build server or on Wind River Linux.

## kas and Buildroot

A kas file named in `kasFile` is read for its repositories, layers and `local.conf` lines, and each layer is matched to its kas entry. A Buildroot output directory's `.config` is recognised; Buildroot builds are not built (see [What's next](https://neuralinverse.com/docs/modules/embedded-linux/whats-next/)).

Next: [Build configuration](https://neuralinverse.com/docs/modules/embedded-linux/build-configuration/).