devtool

devtool runs on the build host in the build environment, one command at a time per build directory and never during a BitBake build. Every action is on a recipe in the Build Directory view (right-click) and in the command palette.

Change a recipe's source

State: modelled with devtool of poky scarthgap (BitBake 2.8.1) over OpenSSH 9.6p1 on a local machine, offline: modify, a finish refused and then written into a product layer's bbappend, devtool build of a native recipe with a GCC 13.3 error in Problems, deploy-target's dry run, reset, and the running app. Not run: a copy to a board (it needs pseudo-native, and an SFTP server on the board for OpenSSH 9's scp), devtool build of a target recipe, Wind River Linux, Windows, a real build server, realistic size.

1. Modify Recipe Source... runs devtool modify. When the build has no devtool workspace layer, it is created and enabled after a confirmation.
2. Open Recipe Source Tree opens the source tree's files from the build host over SSH.
3. The devtool Workspace group of the Build Directory view shows each modified recipe with its source tree, branch, commits and uncommitted changes, and the attic of trees kept by reset and finish. It is read without running devtool.
4. Commit Source Tree Changes... commits in the source tree; each commit becomes a patch at finish.
5. Build Modified Recipe runs devtool build; failures land in Problems as for BitBake builds.
6. Deploy Recipe to Target... runs devtool deploy-target on the build host to a board of the Targets view, after a confirmation listing every path it writes (from devtool deploy-target -n). Undeploy Recipe from Target... removes them.
7. Finish Recipe into Layer... asks for the product layer, then shows devtool finish's dry run (devtool finish -N): the layer, the patches, every file written and the diff of the bbappend. After you confirm, devtool writes them and resets the recipe; its source tree stays in the attic.
8. Reset Recipe... runs devtool reset after a confirmation.

New recipes

State: modelled with poky scarthgap's devtool and recipetool over OpenSSH: cJSON added from Git (MIT, CMake), a python-can tarball (LGPL-3.0-only, forbidden by the test policy) and a Meson folder, in the running app. devtool build of added recipes was not run (no cross toolchain); the Yocto Git servers were reached through local mirrors.

1. Run New Recipe... and pick where the source is: a Git URL (with branch and SRCREV), a tarball or a folder on the build host.
2. recipetool create writes a preview first, with the build folder unchanged: the proposed name and version (PN, PV), the generated recipe, the build system detected (CMake, Meson, autotools, setuptools, cargo, go, or one recipetool does not handle), and LICENSE and LIC_FILES_CHKSUM checked against the company licence policy (see Licence compliance).
3. After a confirmation, devtool add puts the recipe in the workspace for the build and finish steps above.

Recipe upgrades

State: modelled with poky scarthgap's devtool: cjson 1.7.17 to 1.7.19 with two product patches (one rebased, one conflicting; two CVEs fixed, from real NVD records), rebase, skip and finish into a product layer; python3-six 1.16.0 to 1.17.0 from PyPI with its licence change; the running app.

1. Check Recipe Upgrades... lists the product layer's recipes with their latest upstream version (devtool check-upgrade-status, or devtool latest-version per recipe) and the CVEs each upgrade fixes, from the build's CVE report and NVD database, compared with OE-Core's own version rules. The result appears as Recipe Upgrades in the Build Directory view.
2. Upgrade Recipe... asks the version and SRCREV, confirms the change, and runs devtool upgrade. It shows which product patches rebase and which conflict, and flags a licence change for review with devtool's diff.
3. The rebase preview shows the patches on the new version without touching the source tree.
4. Rebase Patches onto New Version... runs the rebase; each conflicting file opens at its marker, and you continue, skip or abort. Then build and finish as above.

Agent tools

The devtool workspace and the upgrade checks are read-only tools. modify, build, finish (with its dry run in the confirmation), reset, deploy-target, undeploy-target, add, upgrade and each rebase step always ask first.

Next: SDK applications.