The build directory and layers

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);
• 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).

Next: Build configuration.