20 Using the devtool command-line tool

The devtool command-line tool provides a number of features that help you build, test, and package software. This command is available alongside the bitbake command. Additionally, the devtool command is a key part of the Extensible Software Development Kit (eSDK).

20.1 Use devtool add to Add an Application

The devtool add command generates a new recipe based on existing source code. This command takes advantage of the The Workspace Layer Structure layer that many devtool commands use. The command is flexible enough to allow you to extract source code into both the workspace or a separate local Git repository and to use existing code that does not need to be extracted.

Depending on your particular scenario, the arguments and options you use with devtool add form different combinations. The following diagram shows common development flows you would use with the devtool add command:

../_images/devtool-add-flow.svg

Common development flows of devtool add

  1. Generating the New Recipe: The top part of the flow shows three scenarios by which you could use devtool add to generate a recipe based on existing source code.

    In a shared development environment, it is typical for other developers to be responsible for various areas of source code. As a developer, you are probably interested in using that source code as part of your development within the Yocto Project. All you need is access to the code, a recipe, and a controlled area in which to do your work.

    Within the diagram, three possible scenarios feed into the devtool add workflow:

    • Left: The left scenario in the figure represents a common situation where the source code does not exist locally and needs to be extracted. In this situation, the source code is extracted to the default workspace — you do not want the files in some specific location outside of the workspace. Thus, everything you need will be located in the workspace:

      $ devtool add recipe fetchuri

      With this command, devtool extracts the upstream source files into a local Git repository within the sources folder. The command then creates a recipe named recipe and a corresponding append file in the workspace. If you do not provide recipe, the command makes an attempt to determine the recipe name.

    • Middle: The middle scenario in the figure represents a situation where the srctree has been previously prepared outside of the devtool workspace.

      The following command provides a new recipe name and identifies the existing source tree location:

      $ devtool add recipe srctree

      The command examines the source code and creates a recipe named recipe for the code and places the recipe into the workspace.

      Because the extracted source code already exists, devtool does not try to relocate the source code into the workspace — only the new recipe is placed in the workspace.

      Aside from a recipe folder, the command also creates an associated append folder and places an initial *.bbappend file within.

    • Right: The right scenario in the figure represents a situation where the source code does not exist locally, as in the left scenario. In this case, the code is again upstream and needs to be extracted to some local area — this time outside of the default workspace.

      Note

      If required, devtool always creates a Git repository locally during the extraction.

      Furthermore, the first positional argument srctree in this case identifies where the devtool add command will locate the extracted code outside of the workspace. You need to specify an empty directory:

      $ devtool add recipe srctree fetchuri

      In summary, the source code is pulled from fetchuri and extracted into the location defined by srctree as a local Git repository.

      Within workspace, devtool creates a recipe named recipe along with an associated append file.

  2. Edit the Recipe: You can use devtool edit-recipe to open up the editor as defined by the $EDITOR environment variable and modify the file:

    $ devtool edit-recipe recipe

    From within the editor, you can make modifications to the recipe that take effect when you build it later.

    Note

    As an alternative to the edit-recipe/build/deploy-target loop, you can use devtool ide-sdk configures IDEs and bootstraps SDKs to generate an SDK and an IDE configuration once, and then edit, build and deploy directly from the IDE, without going through devtool or bitbake for every change.

  3. Build the Recipe or Rebuild the Image: The next step you take depends on what you are going to do with the new code.

    If you need to eventually move the build output to the target hardware, use the following devtool command:

    $ devtool build recipe

    On the other hand, if you want an image to contain the recipe’s packages from the workspace for immediate deployment onto a device (e.g. for testing purposes), you can use the devtool build-image command:

    $ devtool build-image image

  4. Deploy the Build Output: When you use the devtool build command to build out your recipe, you probably want to see if the resulting build output works as expected on the target hardware.

    Note

    This step assumes you have a previously built image that is already either running in QEMU or is running on actual hardware. Also, it is assumed that for deployment of the image to the target, SSH is installed in the image and, if the image is running on real hardware, you have network access to and from your development machine.

    You can deploy your build output to that target hardware by using the devtool deploy-target command:

    $ devtool deploy-target recipe target

    The target is a live target machine running as an SSH server. Alternatively, target can be an absolute path to a local pseudo-managed rootfs directory (e.g. one extracted by runqemu-extract-sdk, see Running Under a Network File System (NFS) Server), in which case the files are copied into it directly, without SSH.

    By default, every file installed by the recipe is deployed (except files that only end up in a -staticdev, -dbg or -src package, which are not useful on a live target). Use the --package and/or --file-glob options to deploy only a subset of the installed files instead, for example --package my-recipe-tests or --file-glob "/usr/bin/*". Both options may be given multiple times and combined.

    You can, of course, also deploy the image you build to actual hardware by using the devtool build-image command. However, devtool does not provide a specific command that allows you to deploy the image to actual hardware.

  5. Finish Your Work With the Recipe: The devtool finish command creates any patches corresponding to commits in the local Git repository, moves the new recipe to a more permanent layer, and then resets the recipe so that the recipe is built normally rather than from the workspace:

    $ devtool finish recipe layer

    Note

    Any changes you want to turn into patches must be committed to the Git repository in the source tree.

    As mentioned, the devtool finish command moves the final recipe to its permanent layer.

    As a final process of the devtool finish command, the state of the standard layers and the upstream source is restored so that you can build the recipe from those areas rather than the workspace.

    Note

    You can use the devtool reset command to put things back should you decide you do not want to proceed with your work. If you do use this command, realize that the source tree is preserved.

20.2 Use devtool modify to Modify the Source of an Existing Component

The devtool modify command prepares the way to work on existing code that already has a local recipe in place that is used to build the software. The command is flexible enough to allow you to extract code from an upstream source, specify the existing recipe, and keep track of and gather any patch files from other developers that are associated with the code.

Depending on your particular scenario, the arguments and options you use with devtool modify form different combinations. The following diagram shows common development flows for the devtool modify command:

../_images/devtool-modify-flow.svg

Common development flows of devtool modify

  1. Preparing to Modify the Code: The top part of the flow shows three scenarios by which you could use devtool modify to prepare to work on source files. Each scenario assumes the following:

    • The recipe exists locally in a layer external to the devtool workspace.

    • The source files exist either upstream in an un-extracted state or locally in a previously extracted state.

    The typical situation is where another developer has created a layer for use with the Yocto Project and their recipe already resides in that layer. Furthermore, their source code is readily available either upstream or locally.

    • Left: The left scenario in the figure represents a situation where the source tree (srctree) already exists locally as a previously extracted Git structure outside of the devtool workspace. In this example, the recipe also exists elsewhere locally in its own layer.

      The following command tells devtool the recipe with which to work, uses the “-n” option to indicate source does not need to be extracted, and uses srctree to point to the previously extracted source files:

      $ devtool modify -n recipe srctree

      For a recipe that sets S = "${UNPACKDIR}", non-patch local files are expected to already be present directly in srctree at the same location as the upstream source. If they are missing there and you run the devtool finish command, any non-patch files that might exist next to the recipe are removed because it appears to devtool that you have deleted those files. This does not apply if S is a subdirectory of UNPACKDIR, since in that case the local files never lived in srctree to begin with.

      Once the devtool modify command finishes, it creates only an append file for the recipe in the devtool workspace. The recipe and the source code remain in their original locations.

    • Middle: The middle scenario in the figure represents a common situation where the source code does not exist locally and it needs to be extracted from an upstream source. In this situation, the source is extracted into the default devtool workspace location. The recipe, in this scenario, is in its own layer outside the workspace (i.e. meta-layername).

      The following command identifies the recipe and, by default, extracts the source files:

      $ devtool modify recipe

      Once devtool locates the recipe, devtool uses the recipe’s SRC_URI statements to locate the source code and any local patch files from other developers.

      With this scenario, there is no srctree argument. Consequently, the default behavior of the devtool modify command is to extract the source files pointed to by the SRC_URI statements into a local Git structure. Furthermore, the location for the extracted source is the default area within the devtool workspace. The result is that the command sets up both the source code and an append file within the workspace while the recipe remains in its original location.

      Additionally, any non-patch local files (i.e. files referred to with file:// entries in the recipe’s SRC_URI statement, excluding *.patch or *.diff files) only end up in the extracted source tree if the recipe sets S = "${UNPACKDIR}". In that case, they are unpacked directly into the source tree at the same location as the upstream source, mixed in with the rest of the unpacked source with no separate area to identify them, so you need to check the recipe’s SRC_URI to tell which files came from local file:// entries. You can edit them directly in the source tree, and any changes you make are incorporated into the build the next time you build the software just as are other changes you might have made to the upstream source.

      If instead S is a subdirectory of UNPACKDIR (the traditional default, e.g. S = "${UNPACKDIR}/${BP}"), these local files are unpacked into UNPACKDIR but outside of S, so they never end up in the source tree at all. They remain purely recipe-side, and are unpacked again into the recipe’s real WORKDIR on every subsequent build regardless of devtool modify; edit them next to the recipe instead.

    • Right: The right scenario in the figure represents a situation where the source code also does not exist locally. In this case, the code is again upstream and needs to be extracted to some local area as a Git repository. The recipe, in this scenario, is again local and in its own layer outside the workspace.

      The following command tells devtool the recipe with which to work and, in this case, identifies a local area for the extracted source files that exists outside of the default devtool workspace:

      $ devtool modify recipe srctree

      Note

      You cannot provide a URL for srctree using the devtool command.

      As with all extractions, the command uses the recipe’s SRC_URI statements to locate the source files and any associated patch files. Non-patch files only end up in srctree if the recipe sets S = "${UNPACKDIR}"; otherwise they are unpacked into UNPACKDIR but outside of S and never reach srctree at all.

      Once the files are located, the command by default extracts them into srctree.

      Within workspace, devtool creates an append file for the recipe. The recipe remains in its original location but the source files are extracted to the location you provide with srctree.

  2. Edit the Source: Once you have used the devtool modify command, you are free to make changes to the source files. You can use any editor you like to make and save your source code modifications.

    Note

    As an alternative to the manual edit/build/deploy-target loop, you can use devtool ide-sdk configures IDEs and bootstraps SDKs to generate an SDK and an IDE configuration once, and then edit, build and deploy directly from the IDE, without going through devtool or bitbake for every change.

  3. Build the Recipe or Rebuild the Image: The next step you take depends on what you are going to do with the new code.

    If you need to eventually move the build output to the target hardware, use the following devtool command:

    $ devtool build recipe

    On the other hand, if you want an image to contain the recipe’s packages from the workspace for immediate deployment onto a device (e.g. for testing purposes), you can use the devtool build-image command:

    $ devtool build-image image

  4. Deploy the Build Output: When you use the devtool build command to build out your recipe, you probably want to see if the resulting build output works as expected on target hardware.

    Note

    This step assumes you have a previously built image that is already either running in QEMU or running on actual hardware. Also, it is assumed that for deployment of the image to the target, SSH is installed in the image and if the image is running on real hardware that you have network access to and from your development machine.

    You can deploy your build output to that target hardware by using the devtool deploy-target command:

    $ devtool deploy-target recipe target

    The target is a live target machine running as an SSH server. Alternatively, target can be an absolute path to a local pseudo-managed rootfs directory, in which case the files are copied into it directly, without SSH.

    You can, of course, use other methods to deploy the image you built using the devtool build-image command to actual hardware. devtool does not provide a specific command to deploy the image to actual hardware.

  5. Finish Your Work With the Recipe: The devtool finish command creates any patches corresponding to commits in the local Git repository, updates the recipe to point to them (or creates a .bbappend file to do so, depending on the specified destination layer), and then resets the recipe so that the recipe is built normally rather than from the workspace:

    $ devtool finish recipe layer

    Note

    Any changes you want to turn into patches must be staged and committed within the local Git repository before you use the devtool finish command.

    Because there is no need to move the recipe, devtool finish either updates the original recipe in the original layer or the command creates a .bbappend file in a different layer as provided by layer. If the recipe sets S = "${UNPACKDIR}", any changes you made directly to local files in the source tree are written back to the original files next to the recipe during the devtool finish command.

    As a final process of the devtool finish command, the state of the standard layers and the upstream source is restored so that you can build the recipe from those areas rather than from the workspace.

    Note

    You can use the devtool reset command to put things back should you decide you do not want to proceed with your work. If you do use this command, realize that the source tree is preserved.

20.3 devtool ide-sdk configures IDEs and bootstraps SDKs

The devtool ide-sdk command configures an IDE for working on the source code of one or more recipes. The tools required for cross-development and remote debugging depend on the recipe’s programming language and build system. For example:

  • A C/C++ project usually uses CMake or Meson.

  • A Python project uses setuptools or one of its successors.

  • A Rust project uses Cargo.

The IDE plugins needed to integrate a build system with the IDE, and their corresponding settings, are usually specific to that build system too. To hide these details from the user, devtool ide-sdk does two things:

  • It generates any kind of SDK needed for cross-development and remote debugging of the specified recipes.

  • It generates the configuration for the IDE (and the IDE plugins) for using the cross-toolchain and remote debugging tools provided by the SDK directly from the IDE.

devtool ide-sdk can do this in one of two modes: the default “modified” mode, which uses the devtool workspace created by devtool modify together with BitBake’s per-recipe Sysroots; and “shared” mode (--mode=shared), which instead bootstraps a full SDK/eSDK-like environment with shared Sysroots, for cases where the default devtool/bitbake integration is not suitable. Both modes can also be combined by repeating the --mode option. All of this is covered in more detail below.

20.3.1 Modified mode

20.3.1.1 Design and architecture

A key point of this design is that generating the SDK and the IDE configuration is a separate step from actually working on the code. This is what sets devtool ide-sdk apart from the devtool build based workflow (see Using devtool in Your SDK Workflow), where every edit/build/deploy/test iteration goes through devtool build and devtool deploy-target, and therefore through bitbake, every time. devtool ide-sdk is itself a bitbake tinfoil client, but it drives bitbake only to generate the SDK, i.e. to build the recipe (and the image) so that their WORKDIR is fully populated. Once the SDK is there, editing the source code, building, deploying and debugging all happen directly in the IDE, independently of devtool ide-sdk and without calling bitbake for every change: devtool ide-sdk generates an IDE configuration that points the IDE directly at the build tool, the cross-toolchain and the debugger provided by the SDK. devtool ide-sdk only needs to be re-run later on, e.g. if a recipe’s dependencies or its build configuration change:

../_images/devtool-ide-sdk-workflow.svg

Typical devtool ide-sdk use case

Let’s now take a closer look at how devtool ide-sdk and the generated IDE configuration make use of a regular bitbake environment as a SDK to achieve this, covering both the build and the remote debug session. devtool ide-sdk needs at least one recipe in devtool modify state (i.e. using externalsrc to build from the devtool workspace) and an image recipe that is used for the development. devtool ide-sdk reads all the details of how bitbake builds the recipe via the tinfoil API, and uses this information to:

  • Call bitbake to compile all the parts of the SDK.

  • Replicate bitbake’s exact build configuration into an IDE configuration for working on that recipe’s source; a separate IDE configuration, i.e. a separate recipe workspace instance (see below), is generated for every recipe.

The recipe’s WORKDIR already contains everything needed for cross-development. Let’s briefly recap how bitbake normally builds a recipe, up to do_install:

  • do_configure and do_compile build the sources into B, the build directory, using the native, host-runnable tools in RECIPE_SYSROOT_NATIVE (recipe-sysroot-native) — e.g. the build tool (cmake), the cross-compiler, and the debugger (gdb) — against the target headers and libraries in RECIPE_SYSROOT (recipe-sysroot).

  • do_install installs the compiled output (make install) into D (image), where the unstripped, but relocated binaries, as well as additionally installed files, end up.

The exact same tools and locations are used by an IDE configured by devtool ide-sdk. The source code itself, S, is not part of WORKDIR in this workflow: it is the source tree extracted by devtool modify into the devtool workspace, which is exactly where the IDE opens and edits it. From this, devtool ide-sdk generates an IDE configuration (e.g. a build tool preset and a debugger launch configuration) that simply points the IDE at the existing build tool binary in recipe-sysroot-native. From then on, the IDE calls that build tool directly, without going through devtool ide-sdk or bitbake again, but with the exact same configuration bitbake or devtool build would use, e.g. a generated CMakePreset or Meson cross file that points to the cross-compiler in recipe-sysroot-native and the target sysroot in recipe-sysroot.

For remote debugging, the IDE manages a debugger (e.g. GDB) on the host instead — the debugger itself is one of those native tools in recipe-sysroot-native too. The debugger gets its debug symbols for the recipe’s own binary from D, and for every other shared library on the target from the rootfs-dbg directory in the image recipe’s WORKDIR (see the image settings note). The debugger then connects to a debug-server (e.g. gdbserver) running on the target device, which launches or attaches to the actual application binary there.

The same architecture also allows the IDE to be configured to use further tools beyond the build tool, cross-compiler and debugger, e.g. clang-tidy: any such tool just needs to be added as a native tool in recipe-sysroot-native, in the Yocto reproducible way, for devtool ide-sdk to be able to point the IDE at it:

../_images/devtool-ide-sdk-architecture.svg

Architecture of devtool ide-sdk

To summarize the design described above, for supported build systems modified mode brings two key benefits:

  • The source code of the recipe is in the workspace created by devtool modify or devtool add. Using devtool build, devtool build-image, devtool deploy-target or bitbake is possible. Also devtool ide-sdk can be used to update the SDK and the IDE configuration at any time.

  • devtool ide-sdk aims to support multiple programming languages and multiple IDEs natively, meaning the IDE is configured to call the build tool (e.g. cmake or meson) directly. This has two main advantages: it is usually much faster than calling devtool build, and it lets you benefit from the integration that IDEs like VSCode offer for tools such as CMake or GDB.

    Supporting many programming languages and IDEs is an elaborate, constantly evolving task, so support for IDEs is implemented as plugins. Optional layers can also provide plugins.

    For recipes using a programming language or build system not yet supported by devtool ide-sdk, an IDE configuration which uses the devtool build based workflow described above is generated as a fallback.

devtool ide-sdk is an alternative to using one of the SDK installers, i.e. the standard SDK built by the populate_sdk class (bitbake -c populate_sdk) or the extensible SDK (eSDK) built by the populate_sdk_ext class (bitbake -c populate_sdk_ext): it can create SDKs offering all the functionality of the SDK and eSDK installers, but is much more flexible. For example, it is very easy to change MACHINE in the build/conf/local.conf file, update the layer metadata, and then regenerate the SDK. When a Shared State Cache is available, e.g. shared between developers or with the autobuilder, building an SDK installer becomes less important in the first place, as bitbake-setup can quickly replicate the layers and build configuration, and devtool ide-sdk can then quickly regenerate an equivalent SDK straight from that cache.

Let’s take a look at an example of how to use devtool ide-sdk.

20.3.1.2 Setting up SSH access

In order to use devtool ide-sdk, SSH access to the target is needed, i.e. the image needs an SSH server (ssh-server-dropbear or ssh-server-openssh). See the “Customizing Images Using Custom IMAGE_FEATURES and EXTRA_IMAGE_FEATURES” section for how to add it, and the “Image Features” section of the Yocto Project Reference Manual for the related allow-root-login, allow-empty-password and empty-root-password features. To simplify usage during development, the core/yocto/root-login-with-empty-password configuration fragment enables a passwordless root login over SSH.

Note

devtool ide-sdk automatically adds everything else needed for debugging, e.g. IMAGE_GEN_DEBUGFS, IMAGE_FSTYPES_DEBUGFS, the image-combined-dbg class, gdbserver/lldb-server, and the recipes being worked on. It writes only the settings it still needs into the image recipe’s .bbappend file in the devtool workspace, and removes them again once they are no longer required, so there is no need to add any of this to local.conf manually.

20.3.1.3 Generating the SDK and IDE configuration

Assuming the BitBake environment is set up correctly and a devtool workspace has been created for the recipe using devtool modify my-recipe (or, for a more useful debug build, devtool modify my-recipe --debug-build), the following command can create the SDK and the configuration for VSCode in the recipe’s devtool workspace:

$ devtool ide-sdk my-recipe core-image-minimal --target root@192.168.7.2

VSCode is configured here because it is the default IDE whenever the code executable is found in PATH. Otherwise, the default is --ide=none, see Selecting the IDE.

The command requires an image recipe (core-image-minimal for this example) that is used to create the SDK. This firmware image should also be installed on the target device. It is possible to pass multiple recipes:

$ devtool ide-sdk my-recipe-1 my-recipe-2 core-image-minimal --target root@192.168.7.2

If only an image recipe is passed, all recipes currently modified in the devtool workspace (i.e. everything with a <workspace>/appends/*.bbappend file) are used automatically, so the above is usually equivalent to just:

$ devtool ide-sdk core-image-minimal --target root@192.168.7.2

What exactly this command does depends on the build tool used by the recipe. The basic idea is to configure the IDE to call the build tool exactly as bitbake does.

For example, for a recipe that inherits cmake, a CMake preset is created; VSCode’s CMake Tools plugin supports these presets directly. This shows how the build configuration used by bitbake is exported to an IDE configuration that produces exactly the same build results.

Seamless remote debugging support is important for a cross-SDK. devtool ide-sdk automatically generates the helper scripts needed to deploy compiled artifacts to the target device, as well as the configuration needed for the debugger and the IDE.

Note

To ensure that the debug symbols on the build machine match the binaries running on the target device, it is essential that the image built by devtool ide-sdk is running on the target device.

20.3.1.4 Debugging on a target

The target is selected with --target, which takes an SSH destination ([user@]host, default root@192.168.7.2), and --port if SSH listens on a port other than 22. It can be a real device, a QEMU instance or any other device running the image built by devtool ide-sdk.

Every debug configuration consumes one debug server port on the target, counting up from 1234. Use --gdbserver-port-start to start at a different port, e.g. to run several devtool ide-sdk instances on the same host at the same time. The option applies to all debug servers, i.e. to gdbserver as well as lldb-server.

If the ssh host key of the target changes frequently, e.g. because the target is re-flashed often, use --no-host-check to disable ssh host key checking.

20.3.1.4.1 QEMU target with slirp networking

A QEMU target started with runqemu slirp (see the slirp option in “runqemu Command-Line Options”) needs no root privileges, but is only reachable through forwarded host ports. devtool ide-sdk supports this setup: it adds the port forwards required by the debug servers to QB_SLIRP_OPT in the image’s .bbappend file, so that runqemu reads them from the image’s .qemuboot.conf file:

$ devtool ide-sdk my-recipe core-image-minimal --target root@localhost --port 2222
$ runqemu slirp serialstdio snapshot

QEMU instances reached through slirp get a new ssh host key on every boot. Therefore, ssh host key checking is disabled automatically for the loopback targets localhost, 127.0.0.1 and ::1, and --no-host-check is not needed.

20.3.1.5 Booting the target from an NFS-exported root filesystem

As an alternative to installing the image and deploying build output over SSH for every debug session, devtool ide-sdk can boot the target from an NFS-exported root filesystem, automating the manual Running Under a Network File System (NFS) Server workflow. Passing --nfs=rootfs (or --nfs=rootfs-dbg to also include the debug filesystem) extracts the selected root filesystem below <workspace>/nfs-exports/<image-recipe>/ and generates a runqemu-rootfs/runqemu-rootfs-dbg helper script to boot QEMU with that root filesystem mounted over NFS:

$ devtool ide-sdk my-recipe core-image-minimal --nfs=rootfs-dbg --target root@192.168.7.2
$ build/workspace/nfs-exports/core-image-minimal/runqemu-rootfs-dbg nographic

This changes the relationship between the SDK, the target device and the debug symbols compared to the architecture described above: instead of a separate rootfs booted by the target and a rootfs-dbg only consulted by the debugger on the host, both the target and the debugger now use the same NFS-exported rootfs-dbg:

../_images/devtool-ide-sdk-nfs-architecture.svg

Architecture of devtool ide-sdk --nfs=rootfs-dbg

Use --nfs-extract-dir=DIR to extract below DIR/<image-recipe>/ instead of the default location in the devtool workspace, for example when the NFS server may only export a particular directory. Note that every devtool ide-sdk --nfs run re-extracts the root filesystem from scratch, which discards everything previously deployed into it.

To boot a real hardware target instead of QEMU, devtool ide-sdk --nfs also generates an export-hw-rootfs (or export-hw-rootfs-dbg) helper script next to the runqemu-rootfs (or runqemu-rootfs-dbg) helper in <workspace>/nfs-exports/<image-recipe>/. It exports the root filesystem with runqemu-export-rootfs and serves DEPLOY_DIR_IMAGE over HTTP (port 8080 by default, set the PORT environment variable to change it), so that a boot loader (e.g. U-Boot with its wget command) can fetch the kernel while the root filesystem is mounted over NFS. Since the target hardware and boot loader setup differ widely, this script covers the typical case and is meant to be adapted as needed. It requires the build environment to be sourced.

With --nfs, the deploy scripts generated by devtool ide-sdk (and thus the deploy tasks of the IDE) copy the build output of the recipe directly into the exported root filesystem on the host instead of using SSH. This works because devtool deploy-target accepts the absolute path of a local root filesystem directory as target. The same can be done manually, e.g.:

$ devtool deploy-target my-recipe \
      /path/to/build/workspace/nfs-exports/core-image-minimal/rootfs-dbg

Without --nfs=rootfs-dbg, the debugger looks up the debug symbols and source files of other recipes’ shared libraries (i.e. everything besides the recipe(s) being worked on) inside the rootfs-dbg folder of the image’s build directory, which is only refreshed by rebuilding the whole image. With --nfs=rootfs-dbg, those same lookups are pointed at the NFS-exported rootfs-dbg instead — the same directory the target already boots from and that devtool deploy-target writes into.

Both --nfs=rootfs and --nfs=rootfs-dbg work for debugging with GDB. The difference is where the debug symbols are available, as described above and below.

Since the target is booted directly from rootfs-dbg, the debug symbols are also present on the target itself, not just on the development host. This relies on the image-combined-dbg class (enabled automatically, see the image settings note), which combines the unstripped binaries and their debug symbols into rootfs-dbg, unlike a plain rootfs where symbols are split out into separate -dbg packages that are not installed. Having them together on the target makes tools like perf or trace-cmd, run directly on the target, produce properly symbolicated output. The same debug symbols are also useful to obtain test code coverage.

20.3.1.6 Using VSCode

VSCode is the default IDE if the code executable is found in PATH (see Selecting the IDE). Some hints about using VSCode:

  • VSCode can be used to work on the BitBake recipes or the application source code. Usually there is one instance of VSCode running in the folder where the BitBake recipes are. This instance has the Yocto Project BitBake plugin running.

    Warning

    Some VSCode plugins (Python, BitBake and others) try to index every file in the workspace, which can make your system unusable while it churns through large generated directories. A build environment set up with bitbake-setup avoids this for this “meta” instance: it generates (and keeps updated) a bitbake.code-workspace multi-root workspace file with appropriate excludes for the layers and build/conf. For each per-recipe workspace instance (see below), devtool ide-sdk generates its own settings.json with a similar ignore list, excluding directories such as oe-workdir and oe-logs.

    The BitBake plugin also offers to create devtool workspaces and run devtool ide-sdk with a few mouse clicks. Of course, issuing commands in the terminal works as well.

  • To work on the source code of a recipe another instance of VSCode is started in the recipe’s workspace. Example:

    $ code build/workspace/sources/my-recipe

    This instance of VSCode uses plugins that are useful for the development of the application. devtool ide-sdk generates the necessary extensions.json, settings.json, tasks.json and launch.json configuration files for all the involved plugins.

    When the source code folder present in the workspace folder is opened in VSCode for the first time, a pop-up message recommends installing the required plugins. After accepting the installation of the plugins, working with the source code or some debugging tasks should work as usual with VSCode.

    Starting the VSCode instances in the recipe workspace folders can also be done by a mouse click on the recipe workspaces in the first VSCode instance.

  • To work with CMake press Ctrl + Shift + p, type cmake. This will show some possible commands like selecting a CMake preset, compiling or running CTest.

    For recipes inheriting cmake-qemu rather than cmake, executing cross-compiled unit tests on the host can be supported transparently with QEMU user-mode.

  • To work with Meson press Ctrl + Shift + p, type meson. This will show some possible commands like compiling or executing the unit tests.

    A note on running cross-compiled unit tests on the host: Meson enables support for QEMU user mode by default. It is expected that the execution of the unit tests from the IDE will work without any additional steps, given that the code is suitable for the execution on the host machine.

  • For C/C++ IntelliSense (code completion, navigation and diagnostics), devtool ide-sdk configures either the clangd language server or Microsoft’s C/C++ extension (cpptools), matched to the recipe’s real cross-compiler via the generated compile_commands.json. clangd is used automatically for recipes built with the LLVM/clang toolchain; other recipes default to cpptools, but can opt into clangd too by setting the recipe’s IDE_SDK_INTELLISENSE variable to “clangd”. When clangd is used and the recipe’s source tree contains a .clang-format file, devtool ide-sdk also configures VSCode to format C/C++ files with clangd on save, honoring that style file.

  • For the deployment to the target device, just press Ctrl + Shift + p, type task. Select install && deploy-target. This runs only do_install through BitBake, so that the build results produced by the IDE are kept, and then deploys its output.

    By default, every file installed by the recipe is deployed (except files that only end up in a -staticdev, -dbg or -src package, which are not useful on a live target). Use the --package and/or --file-glob options of devtool ide-sdk (or devtool deploy-target) to deploy only a subset of the installed files, for example --package my-recipe-tests or --file-glob "/usr/bin/*". Both options may be given multiple times and combined, and may be prefixed with RECIPE: (e.g. --package "RECIPE:,-doc") to scope the option to one of several recipes being processed by a single devtool ide-sdk invocation.

  • For remote debugging, switch to the debugging view by pressing the “play” button with the bug icon on the left side. This will provide a green play button with a drop-down list where a debug configuration can be selected. After selecting one of the generated configurations, press the “play” button.

    Starting a remote debugging session automatically initiates the deployment to the target device. If this is not desired, the "dependsOn": ["install && deploy-target...] parameter of the tasks with "label": "gdbserver start... can be removed from the tasks.json file.

    VSCode supports GDB in many different setups and configurations for many different use cases. However, most of these have limitations for cross-development: they support only a few target architectures, or require a high performance target device. devtool ide-sdk therefore uses the classic, generic setup: GDB on the development host and gdbserver on the target device.

    For recipes built with the LLVM/clang toolchain (TOOLCHAIN set to “clang”), devtool ide-sdk automatically uses LLDB and lldb-server instead of GDB and gdbserver, with no extra command-line option needed. GDB and LLDB can be used side by side when several recipes using different toolchains are processed by the same devtool ide-sdk invocation.

    Roughly summarized, this means:

    • The binaries are copied via SSH to the remote target device by a script referred by tasks.json.

    • gdbserver is started on the remote target device via SSH by a script referred by tasks.json.

      Changing the parameters that are passed to the debugging executable requires modifying the generated script. The script is located at oe-scripts/gdbserver_*. Defining the parameters in the args field in the launch.json file does not work.

    • VSCode connects to gdbserver as documented in Remote debugging or debugging with a local debugger server.

  • For a recipe whose binary is started by systemd or a SysV init script (i.e. it runs as a persistent service rather than being started directly by the debugger), an additional “Attach” debug configuration is generated alongside the regular one. Selecting it attaches the debugger to the already-running instance of the service on the target instead of starting a new one.

20.3.1.7 Selecting the IDE

The --ide option selects the IDE plugin. If it is omitted, VSCode is configured when the code executable is found in PATH, and no IDE (--ide=none) otherwise. The option can be given multiple times to configure several IDEs in one invocation, and --ide=all configures every supported IDE:

$ devtool ide-sdk my-recipe core-image-minimal --ide=code --ide=none
$ devtool ide-sdk my-recipe core-image-minimal --ide=all

Support for further IDEs is implemented as plugins, which optional layers can provide as well.

20.3.1.8 Debugging without an IDE

Additionally --ide=none is supported. With the none IDE parameter, some generic configuration files like gdbinit files and some helper scripts starting gdbserver remotely on the target device as well as the GDB client on the host are generated.

20.3.1.9 Example: cmake-example walkthrough

Here is a usage example for the cmake-example recipe from the meta-selftest layer which inherits cmake-qemu:

# Create the SDK
$ devtool modify cmake-example --debug-build
$ devtool ide-sdk cmake-example core-image-minimal -c --ide=none

# Install the firmware on a target device or start QEMU
$ runqemu

# From exploring the workspace of cmake-example
$ cd build/workspace/sources/cmake-example

# Find cmake-native and save the path into a variable
# Note: using just cmake instead of $CMAKE_NATIVE would work in many cases
$ CMAKE_NATIVE="$(jq -r '.configurePresets[0] | "\(.cmakeExecutable)"' CMakeUserPresets.json)"

# List available CMake presets
$ "$CMAKE_NATIVE" --list-presets
Available configure presets:

  "cmake-example-cortexa57" - cmake-example: cortexa57

# Re-compile the already compiled sources
$ "$CMAKE_NATIVE" --build --preset cmake-example-cortexa57
ninja: no work to do.
# Do a clean re-build
$ "$CMAKE_NATIVE" --build --preset cmake-example-cortexa57 --target clean
[1/1] Cleaning all built files...
Cleaning... 8 files.
$ "$CMAKE_NATIVE" --build --preset cmake-example-cortexa57 --target all
[7/7] Linking CXX executable cmake-example

# Run the cross-compiled unit tests with QEMU user-mode
$ "$CMAKE_NATIVE" --build --preset cmake-example-cortexa57 --target test
[0/1] Running tests...
Test project .../build/tmp/work/cortexa57-poky-linux/cmake-example/1.0/cmake-example-1.0
    Start 1: test-cmake-example
1/1 Test #1: test-cmake-example ...............   Passed    0.03 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   0.03 sec

# Using CTest directly is possible as well
$ CTEST_NATIVE="$(dirname "$CMAKE_NATIVE")/ctest"

# List available CMake presets
$ "$CTEST_NATIVE" --list-presets
Available test presets:

  "cmake-example-cortexa57" - cmake-example: cortexa57

# Run the cross-compiled unit tests with QEMU user-mode
$ "$CTEST_NATIVE" --preset "cmake-example-cortexa57"
Test project ...build/tmp/work/cortexa57-poky-linux/cmake-example/1.0/cmake-example-1.0
    Start 1: test-cmake-example
1/1 Test #1: test-cmake-example ...............   Passed    0.03 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   0.03 sec

# Deploy the new build to the target device (default is QEMU at 192.168.7.2)
$ oe-scripts/install_and_deploy_cmake-example-cortexa57

# Start a remote debugging session with gdbserver on the target and GDB on the host
$ oe-scripts/gdbserver_1234_usr-bin-cmake-example_m
$ oe-scripts/gdb_1234_usr-bin-cmake-example
(gdb) break main
(gdb) run
(gdb) step
(gdb) stepi
(gdb) continue
(gdb) quit

# Stop gdbserver on the target device
$ oe-scripts/gdbserver_1234_usr-bin-cmake-example_m stop

20.3.2 Shared sysroots mode

20.3.2.1 Concept

For some recipes and use cases, modified mode’s full devtool/bitbake integration might not be suitable. To offer full feature parity with the SDK and the eSDK instead, --mode=shared bootstraps an SDK directly from the BitBake environment, offering the same Environment Setup script as described in Running the Extensible SDK Environment Setup Script. The IDE is then configured to use the shared Sysroots and tools from that SDK. devtool ide-sdk --mode=shared is basically a wrapper around the setup of the extensible SDK as described in Setting up the Extensible SDK environment directly in a Yocto build.

Shared mode can also be given an image recipe. The image is then built as part of the SDK, and IDE plugins can use it to generate image-based configurations, e.g. for debugging with the debug symbols and sources of the image’s rootfs-dbg. As in modified mode, --nfs exports the image’s root filesystem (see Booting the target from an NFS-exported root filesystem), which requires an image recipe:

$ devtool ide-sdk --mode=shared core-image-minimal --nfs=rootfs-dbg --target root@192.168.7.2

20.3.2.2 Example

Creating an SDK with shared Sysroots that contains all the dependencies needed to work with my-recipe is possible with the following example command:

$ devtool ide-sdk --mode=shared my-recipe

For VSCode the cross-toolchain is exposed as a CMake kit. CMake kits are defined in ~/.local/share/CMakeTools/cmake-tools-kits.json. The following example shows how the cross-toolchain can be selected in VSCode. First of all we need a folder containing a CMake project. For this example, let’s create a CMake project and start VSCode:

$ mkdir kit-test
$ echo "project(foo VERSION 1.0)" > kit-test/CMakeLists.txt
$ code kit-test

If there is a CMake project in the workspace, cross-compilation is supported:

  • Press Ctrl + Shift + P, type CMake: Scan for Kits

  • Press Ctrl + Shift + P, type CMake: Select a Kit

Finally most of the features provided by CMake and the IDE should be available.

Other IDEs than VSCode are supported as well. However, devtool ide-sdk --mode=shared --ide=none my-recipe is currently just a simple wrapper for the setup of the extensible SDK, as described in Setting up the Extensible SDK environment directly in a Yocto build.

20.3.3 Combining modified and shared mode

Modified mode configures the IDE for recipes in devtool modify state, while shared mode provides a standalone cross-toolchain and shared Sysroots for working on other source code. Repeating the --mode option runs both workflows in a single invocation, so the image is built only once:

$ devtool modify my-recipe
$ devtool ide-sdk --mode=modified --mode=shared my-recipe other-recipe core-image-minimal

In this example:

  • my-recipe is in devtool modify state and gets its recipe-specific IDE configuration in its devtool workspace, as described in Modified mode.

  • other-recipe is not in devtool modify state. It is added to the shared sysroots, which provide the environment setup script to build other source code with the cross-toolchain, as described in Shared sysroots mode.

  • core-image-minimal provides the root filesystem for the remote debugging of both. Its rootfs-dbg provides the debug symbols and sources, and --nfs can export its root filesystem for the target.

Without --mode=modified in the invocation, modified recipes are rejected, and without --mode=shared in the invocation, recipes that are not modified are rejected. If --mode is omitted, modified mode is used.

20.4 Use devtool upgrade to Create a Version of the Recipe that Supports a Newer Version of the Software

The devtool upgrade command upgrades an existing recipe to that of a more up-to-date version found upstream. Throughout the life of software, recipes continually undergo version upgrades by their upstream publishers. You can use the devtool upgrade workflow to make sure your recipes you are using for builds are up-to-date with their upstream counterparts.

Note

Several methods exist by which you can upgrade recipes — devtool upgrade happens to be one. You can read about all the methods by which you can upgrade recipes in the Upgrading Recipes section of the Yocto Project Development Tasks Manual.

The devtool upgrade command is flexible enough to allow you to specify source code revision and versioning schemes, extract code into or out of the devtool The Workspace Layer Structure, and work with any source file forms that the Fetchers support.

The following diagram shows the common development flow used with the devtool upgrade command:

../_images/devtool-upgrade-flow.svg

Common development flow of devtool upgrade

  1. Initiate the Upgrade: The top part of the flow shows the typical scenario by which you use the devtool upgrade command. The following conditions exist:

    • The recipe exists in a local layer external to the devtool workspace.

    • The source files for the new release exist in the same location pointed to by SRC_URI in the recipe (e.g. a tarball with the new version number in the name, or as a different revision in the upstream Git repository).

    A common situation is where third-party software has undergone a revision so that it has been upgraded. The recipe you have access to is likely in your own layer. Thus, you need to upgrade the recipe to use the newer version of the software:

    $ devtool upgrade -V version recipe

    By default, the devtool upgrade command extracts source code into the sources directory in the The Workspace Layer Structure. If you want the code extracted to any other location, you need to provide the srctree positional argument with the command as follows:

    $ devtool upgrade -V version recipe srctree

    Note

    In this example, the “-V” option specifies the new version. If you don’t use “-V”, the command upgrades the recipe to the latest version.

    If the source files pointed to by the SRC_URI statement in the recipe are in a Git repository, you must provide the “-S” option and specify a revision for the software.

    Once devtool locates the recipe, it uses the SRC_URI variable to locate the source code and any local patch files from other developers. The result is that the command sets up the source code, the new version of the recipe, and an append file all within the workspace.

    Additionally, any non-patch local files (i.e. files referred to with file:// entries in the recipe’s SRC_URI statement, excluding *.patch or *.diff files) only end up in the extracted source tree if the recipe sets S = "${UNPACKDIR}". In that case, they are unpacked directly into the source tree at the same location as the upstream source, mixed in with the rest of the unpacked source with no separate area to identify them, so you need to check the recipe’s SRC_URI to tell which files came from local file:// entries. You can edit them directly in the source tree, and any changes you make are incorporated into the build the next time you build the software just as are other changes you might have made to the upstream source.

    If instead S is a subdirectory of UNPACKDIR (the traditional default, e.g. S = "${UNPACKDIR}/${BP}"), these local files are unpacked into UNPACKDIR but outside of S, so they never end up in the source tree at all. They remain purely recipe-side, and are unpacked again into the recipe’s real WORKDIR on every subsequent build regardless of devtool upgrade; edit them next to the recipe instead.

  2. Resolve any Conflicts created by the Upgrade: Conflicts could happen after upgrading the software to a new version. Conflicts occur if your recipe specifies some patch files in SRC_URI that conflict with changes made in the new version of the software. For such cases, you need to resolve the conflicts by editing the source and following the normal git rebase conflict resolution process.

    Before moving onto the next step, be sure to resolve any such conflicts created through use of a newer or different version of the software.

  3. Build the Recipe or Rebuild the Image: The next step you take depends on what you are going to do with the new code.

    If you need to eventually move the build output to the target hardware, use the following devtool command:

    $ devtool build recipe

    On the other hand, if you want an image to contain the recipe’s packages from the workspace for immediate deployment onto a device (e.g. for testing purposes), you can use the devtool build-image command:

    $ devtool build-image image

  4. Deploy the Build Output: When you use the devtool build command or bitbake to build your recipe, you probably want to see if the resulting build output works as expected on target hardware.

    Note

    This step assumes you have a previously built image that is already either running in QEMU or running on actual hardware. Also, it is assumed that for deployment of the image to the target, SSH is installed in the image and if the image is running on real hardware that you have network access to and from your development machine.

    You can deploy your build output to that target hardware by using the devtool deploy-target command:

    $ devtool deploy-target recipe target

    The target is a live target machine running as an SSH server. Alternatively, target can be an absolute path to a local pseudo-managed rootfs directory, in which case the files are copied into it directly, without SSH.

    You can, of course, also deploy the image you build using the devtool build-image command to actual hardware. However, devtool does not provide a specific command that allows you to do this.

  5. Finish Your Work With the Recipe: The devtool finish command creates any patches corresponding to commits in the local Git repository, moves the new recipe to a more permanent layer, and then resets the recipe so that the recipe is built normally rather than from the workspace.

    If the recipe sets S = "${UNPACKDIR}", any changes you made directly to local files in the source tree are written back to the original files next to the recipe during the devtool finish command.

    If you specify a destination layer that is the same as the original source, then the old version of the recipe and associated files are removed prior to adding the new version:

    $ devtool finish recipe layer

    Note

    Any changes you want to turn into patches must be committed to the Git repository in the source tree.

    As a final process of the devtool finish command, the state of the standard layers and the upstream source is restored so that you can build the recipe from those areas rather than the workspace.

    Note

    You can use the devtool reset command to put things back should you decide you do not want to proceed with your work. If you do use this command, realize that the source tree is preserved.

20.5 A Closer Look at devtool add

The devtool add command automatically creates a recipe based on the source tree you provide with the command. Currently, the command has support for the following:

  • Autotools (autoconf and automake)

  • CMake

  • Scons

  • qmake

  • Plain Makefile

  • Out-of-tree kernel module

  • Binary package (i.e. “-b” option)

  • Node.js module

  • Python modules that use setuptools or distutils

Apart from binary packages, the determination of how a source tree should be treated is automatic based on the files present within that source tree. For example, if a CMakeLists.txt file is found, then the source tree is assumed to be using CMake and is treated accordingly.

Note

In most cases, you need to edit the automatically generated recipe in order to make it build properly. Typically, you would go through several edit and build cycles until the recipe successfully builds. Once the recipe builds, you could use possible further iterations to test the recipe on the target device.

The remainder of this section covers specifics regarding how parts of the recipe are generated.

20.5.1 Name and Version

If you do not specify a name and version on the command line, devtool add uses various metadata within the source tree in an attempt to determine the name and version of the software being built. Based on what the tool determines, devtool sets the name of the created recipe file accordingly.

If devtool cannot determine the name and version, the command prints an error. For such cases, you must re-run the command and provide the name and version, just the name, or just the version as part of the command line.

Sometimes the name or version determined from the source tree might be incorrect. For such a case, you must reset the recipe:

$ devtool reset -n recipename

After running the devtool reset command, you need to run devtool add again and provide the name or the version.

20.5.2 Dependency Detection and Mapping

The devtool add command attempts to detect build-time dependencies and map them to other recipes in the system. During this mapping, the command fills in the names of those recipes as part of the DEPENDS variable within the recipe. If a dependency cannot be mapped, devtool places a comment in the recipe indicating such. The inability to map a dependency can result from naming not being recognized or because the dependency simply is not available. For cases where the dependency is not available, you must use the devtool add command to add an additional recipe that satisfies the dependency. Once you add that recipe, you need to update the DEPENDS variable in the original recipe to include the new recipe.

If you need to add runtime dependencies, you can do so by adding the following to your recipe:

RDEPENDS:${PN} += "dependency1 dependency2 ..."

Note

The devtool add command often cannot distinguish between mandatory and optional dependencies. Consequently, some of the detected dependencies might in fact be optional. When in doubt, consult the documentation or the configure script for the software the recipe is building for further details. In some cases, you might find you can substitute the dependency with an option that disables the associated functionality passed to the configure script.

20.5.3 License Detection

The devtool add command attempts to determine if the software you are adding is able to be distributed under a common, open-source license. If so, the command sets the LICENSE value accordingly. You should double-check the value added by the command against the documentation or source files for the software you are building and, if necessary, update that LICENSE value.

The devtool add command also sets the LIC_FILES_CHKSUM value to point to all files that appear to be license-related. Realize that license statements often appear in comments at the top of source files or within the documentation. In such cases, the command does not recognize those license statements. Consequently, you might need to amend the LIC_FILES_CHKSUM variable to point to one or more of those comments if present. Setting LIC_FILES_CHKSUM is particularly important for third-party software. The mechanism attempts to ensure correct licensing should you upgrade the recipe to a newer upstream version in future. Any change in licensing is detected and you receive an error prompting you to check the license text again.

If the devtool add command cannot determine licensing information, devtool sets the LICENSE value to “CLOSED” and leaves the LIC_FILES_CHKSUM value unset. This behavior allows you to continue with development even though the settings are unlikely to be correct in all cases. You should check the documentation or source files for the software you are building to determine the actual license.

20.5.4 Adding Makefile-Only Software

The use of Make by itself is very common in both proprietary and open-source software. Unfortunately, Makefiles are often not written with cross-compilation in mind. Thus, devtool add often cannot do very much to ensure that these Makefiles build correctly. It is very common, for example, to explicitly call gcc instead of using the CC variable. Usually, in a cross-compilation environment, gcc is the compiler for the build host and the cross-compiler is named something similar to arm-poky-linux-gnueabi-gcc and might require arguments (e.g. to point to the associated sysroot for the target machine).

When writing a recipe for Makefile-only software, keep the following in mind:

  • You probably need to patch the Makefile to use variables instead of hardcoding tools within the toolchain such as gcc and g++.

  • The environment in which Make runs is set up with various standard variables for compilation (e.g. CC, CXX, and so forth) in a similar manner to the environment set up by an SDK’s environment setup script. One easy way to see these variables is to run the devtool build command on the recipe and then look in oe-logs/run.do_compile. Towards the top of this file, there is a list of environment variables that are set. You can take advantage of these variables within the Makefile.

  • If the Makefile sets a default for a variable using “=”, that default overrides the value set in the environment, which is usually not desirable. For this case, you can either patch the Makefile so it sets the default using the “?=” operator, or you can alternatively force the value on the make command line. To force the value on the command line, add the variable setting to EXTRA_OEMAKE or PACKAGECONFIG_CONFARGS within the recipe. Here is an example using EXTRA_OEMAKE:

    EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"

    In the above example, single quotes are used around the variable settings as the values are likely to contain spaces because required default options are passed to the compiler.

  • Hardcoding paths inside Makefiles is often problematic in a cross-compilation environment. This is particularly true because those hardcoded paths often point to locations on the build host and thus will either be read-only or will introduce contamination into the cross-compilation because they are specific to the build host rather than the target. Patching the Makefile to use prefix variables or other path variables is usually the way to handle this situation.

  • Sometimes a Makefile runs target-specific commands such as ldconfig. For such cases, you might be able to apply patches that remove these commands from the Makefile.

20.5.5 Adding Native Tools

Often, you need to build additional tools that run on the Build Host as opposed to the target. You should indicate this requirement by using one of the following methods when you run devtool add:

  • Specify the name of the recipe such that it ends with “-native”. Specifying the name like this produces a recipe that only builds for the build host.

  • Specify the “–also-native” option with the devtool add command. Specifying this option creates a recipe file that still builds for the target but also creates a variant with a “-native” suffix that builds for the build host.

Note

If you need to add a tool that is shipped as part of a source tree that builds code for the target, you can typically accomplish this by building the native and target parts separately rather than within the same compilation process. Realize though that with the “–also-native” option, you can add the tool using just one recipe file.

20.5.6 Adding Node.js Modules

Warning

The NPM fetcher is currently disabled due to security concerns. See 355cd22 for more information.

You can use the devtool add command two different ways to add Node.js modules: through npm or from a repository or local source.

Use the following form to add Node.js modules through npm:

$ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1"

The name and version parameters are mandatory. Lockdown and shrinkwrap files are generated and pointed to by the recipe in order to freeze the version that is fetched for the dependencies according to the first time. This also saves checksums that are verified on future fetches. Together, these behaviors ensure the reproducibility and integrity of the build.

Note

  • You must use quotes around the URL. devtool add does not require the quotes, but the shell considers “;” as a splitter between multiple commands. Thus, without the quotes, devtool add does not receive the other parts, which results in several “command not found” errors.

As mentioned earlier, you can also add Node.js modules directly from a repository or local source tree. To add modules this way, use devtool add in the following form:

$ devtool add https://github.com/diversario/node-ssdp

In this example, devtool fetches the specified Git repository, detects the code as Node.js code, fetches dependencies using npm, and sets SRC_URI accordingly.

20.6 Working With Recipes

When building a recipe using the devtool build command, the typical build progresses as follows:

  1. Fetch the source

  2. Unpack the source

  3. Configure the source

  4. Compile the source

  5. Install the build output

  6. Package the installed output

For recipes in the workspace, fetching and unpacking is disabled as the source tree has already been prepared and is persistent. Each of these build steps is defined as a function (task), usually with a “do_” prefix (e.g. do_fetch, do_unpack, and so forth). These functions are typically shell scripts but can instead be written in Python.

If you look at the contents of a recipe, you will see that the recipe does not include complete instructions for building the software. Instead, common functionality is encapsulated in classes inherited with the inherit directive. This technique leaves the recipe to describe just the things that are specific to the software being built. There is a base class that is implicitly inherited by all recipes and provides the functionality that most recipes typically need.

The remainder of this section presents information useful when working with recipes.

20.6.1 Finding Logs and Work Files

After the first run of the devtool build command, recipes that were previously created using the devtool add command or whose sources were modified using the devtool modify command contain symbolic links created within the source tree:

  • oe-logs: This link points to the directory in which log files and run scripts for each build step are created.

  • oe-workdir: This link points to the temporary work area for the recipe. The following locations under oe-workdir are particularly useful:

    • image/: Contains all of the files installed during the do_install stage. Within a recipe, this directory is referred to by the expression ${D}.

    • sysroot-destdir/: Contains a subset of files installed within do_install that have been put into the shared sysroot. For more information, see the “Sharing Files Between Recipes” section.

    • packages-split/: Contains subdirectories for each package produced by the recipe. For more information, see the “Packaging” section.

You can use these links to get more information on what is happening at each build step.

20.6.2 Setting Configure Arguments

If the software your recipe is building uses GNU autoconf, then a fixed set of arguments is passed to it to enable cross-compilation plus any extras specified by EXTRA_OECONF or PACKAGECONFIG_CONFARGS set within the recipe. If you wish to pass additional options, add them to EXTRA_OECONF or PACKAGECONFIG_CONFARGS. Other supported build tools have similar variables (e.g. EXTRA_OECMAKE for CMake, EXTRA_OESCONS for Scons, and so forth). If you need to pass anything on the make command line, you can use EXTRA_OEMAKE or the PACKAGECONFIG_CONFARGS variables to do so.

You can use the devtool configure-help command to help you set the arguments listed in the previous paragraph. The command determines the exact options being passed, and shows them to you along with any custom arguments specified through EXTRA_OECONF or PACKAGECONFIG_CONFARGS. If applicable, the command also shows you the output of the configure script’s “–help” option as a reference.

20.6.3 Sharing Files Between Recipes

Recipes often need to use files provided by other recipes on the Build Host. For example, an application linking to a common library needs access to the library itself and its associated headers. The way this access is accomplished is through the Sysroot. There is a sysroot for the target machine, and a sysroot for the build host.

Recipes should never write files directly into the sysroot. Instead, files should be installed into standard locations during the do_install task within the ${D} directory. A subset of these files automatically goes into the sysroot. The reason for this limitation is that almost all files that go into the sysroot are cataloged in manifests in order to ensure they can be removed later when a recipe is modified or removed. Thus, the sysroot is able to remain free from stale files.

20.6.4 Packaging

If you examine how build output gets into the final image on the target device, it is important to understand packaging because the contents of the image are expressed in terms of packages and not recipes.

During the do_package task, files installed during the do_install task are split into one main package, which is almost always named the same as the recipe, and into several other packages. This separation exists because not all of those installed files are useful in every image. For example, you probably do not need any of the documentation installed in a production image. Consequently, for each recipe the documentation files are separated into a -doc package. Recipes that package software containing optional modules or plugins might undergo additional package splitting as well.

After building a recipe, you can see where files have gone by looking in the oe-workdir/packages-split directory, which contains a subdirectory for each package. Apart from some advanced cases, the PACKAGES and FILES variables controls splitting. The PACKAGES variable lists all of the packages to be produced, while the FILES variable specifies which files to include in each package by using an override to specify the package. For example, FILES:${PN} specifies the files to go into the main package (i.e. the main package has the same name as the recipe and ${PN} evaluates to the recipe name). The order of the PACKAGES value is significant. For each installed file, the first package whose FILES value matches the file is the package into which the file goes. Both the PACKAGES and FILES variables have default values. Consequently, you might find you do not even need to set these variables in your recipe unless the software the recipe is building installs files into non-standard locations.

20.7 Restoring the Target Device to its Original State

If you use the devtool deploy-target command to write a recipe’s build output to the target, and you are working on an existing component of the system, then you might find yourself in a situation where you need to restore the original files that existed prior to running the devtool deploy-target command. Because the devtool deploy-target command backs up any files it overwrites, you can use the devtool undeploy-target command to restore those files and remove any other files the recipe deployed. Consider the following example:

$ devtool undeploy-target lighttpd root@192.168.7.2

If you have deployed multiple applications, you can remove them all using the “-a” option thus restoring the target device to its original state:

$ devtool undeploy-target -a root@192.168.7.2

Information about files deployed to the target as well as any backed up files are stored on the target itself. This storage, of course, requires some additional space on the target machine.

Note

The devtool deploy-target and devtool undeploy-target commands do not currently interact with any package management system on the target device (e.g. RPM or OPKG). Consequently, you should not intermingle devtool deploy-target and package manager operations on the target device. Doing so could result in a conflicting set of files.