Everything you ought to know (and more) about Yocto’s SDK and Extensible SDK (eSDK)

Yocto is so widely used because of the many benefits it provides to engineers that wish to build customised Linux distributions. However, it does have pain points. One such pain point relates to the difficulty of getting a Yocto development environment setup in the first place – this often involves using third-party tools such as repo or kas and then figuring out what commands are needed to setup the environment to the point where you can run ‘bitbake‘. Another pain point relates to the requirements of the build machine and how long it takes to build – whilst building everything from source provides flexibility, it does also requires a powerful machine and plenty of time. These pain points are particularly pronounced for those people that simply want to develop applications that run against the built Yocto distribution.

Fortunately, the Yocto developers have a solution and it’s called a Yocto SDK or Extensible SDK (eSDK). This blog post provides a brief walkthrough of what they are, how to build them and how to use them.

If you’re an application developer and wish to cross-compile an application to run on a Linux distribution, you need a suitable toolchain and access to relevant headers and libraries such that you can compile and link to run against the specific libraries in that distribution. The Yocto SDK (not to be confused with eSDK) provides this, effectively it’s a toolchain and sysroot all bundled into a self installing script with a script that helps you set up suitable environment variables (such as CC and CROSS_COMPILE).

The Extensible SDK (eSDK) is an environment that allows you to run Yocto’s ‘devtool‘ command. This allows you to easily add new packages and modify existing ones, it also allows you to rebuild the final image. It’s effectively a packaged up version of a (encapsulated) Yocto environment. It solves the ‘setup problem’ as the Yocto environment can be installed via a single self-installer script. It also solves the ‘build speed’ problem as it includes a pre-built shared state cache, therefore you can add/modify packages and rebuild the image without building everything from source (it will use the pre-built artifacts from the shared state cache when possible).

Build ‘Mickledore’ Yocto

We can better understand the SDK and eSDK by going through the process of generating and using them. However let’s start by building an ordinary Yocto image for a QEMU 86-64 target, to do this we’ll follow the instructions in the Yocto Documentation which look a bit like this:

$ git clone -b mickledore git://git.yoctoproject.org/poky
$ source oe-init-build-env

To improve the speed of our build, let’s also make use of the Yocto Project’s shared state cache by adding the following to our build/local.conf. This will download pre-built artifacts from the internet rather than build them all from scratch.

BB_SIGNATURE_HANDLER = "OEEquivHash"
BB_HASHSERVE = "auto"
BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"

Finally, let’s build a basic image. Obviously in your case it would be the Yocto distribution for your shinny new piece of kit.

$ bitbake core-image-minimal

Thanks to the shared state cache our clean build took less than 15 minutes. Let’s check it boots in QEMU:

$ runqemu qemux86-64 serialstdio tmp/deploy/images/qemux86-64/
...
INIT: Entering runlevel: 5
 Configuring network interfaces… ip: RTNETLINK answers: File exists
 Starting syslogd/klogd: done
 Poky (Yocto Project Reference Distro) 4.2.3 qemux86-64 /dev/ttyS0
 qemux86-64 login: root
 root@qemux86-64:~# 

As you can see we’ve booted to a root prompt via a serial console in QEMU. Let’s move on to playing with Yocto SDKs.

Build a Yocto SDK

Now that we’ve built Yocto, let’s build an SDK for our distribution. We can do that by running the populate_sdk task on your image as follows:

$ bitbake core-image-minimal -c populate_sdk

The output of the above command is an installer script (.sh) file in the tmp/deploy/sdk directory. In my case it’s named “poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-4.2.3.sh” and is approximately 238MB in size (see this page for information on the naming convention). As this is a single self-contained script you can easily distribute it to others to provide them with everything needed to build against your distribution.

Let’s now install the SDK, as follows:

$ ./poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-4.2.3.sh 
 Poky (Yocto Project Reference Distro) SDK installer version 4.2.3
 Enter target directory for SDK (default: /opt/poky/4.2.3): 
 You are about to install the SDK to "/opt/poky/4.2.3". Proceed [Y/n]? 
 [sudo] password for andy: 
 Extracting SDK……………………………………………………………………..done
 Setting it up…done
 SDK has been successfully set up and is ready to be used.
 Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
$ . /opt/poky/4.2.3/environment-setup-core2-64-poky-linux

Let’s take a closer look at what has been unpacked:

$ ls -1
environment-setup-core2-64-poky-linux
site-config-core2-64-poky-linux
sysroots/core2-64-poky-linux/
sysroots/x86_64-pokysdk-linux/
version-core2-64-poky-linux

As you can see there is a sysroot provided for the target (core2-64) as well as one for the host (x86_64). A version file has also been provided which provides basic information about the distro version and timestamp.

Finally an environment-setup file (accompanied with a site-config file) is also provided. This file sets various environment variables such as CFLAGS and CROSS_COMPILE that may be relied upon by application developers or building tools such as autoconf. Let’s source this file:

$ source /opt/poky/4.2.3/environment-setup-core2-64-poky-linux

At this point a suitable environment is set up for cross-compiling against the Yocto distribution, for example we could build a simple hello world application:

$ echo 'int main() { printf("Hello\n"); }' | $CC -xc - -o helloworld

Please see the Yocto documentation for more information on how to develop applications with the SDK.

Finally, there is some scope for customising the SDK – you can add additional packages to the host or target parts of the SDK via the TOOLCHAIN_HOST_TASK and TOOLCHAIN_TARGET_TASK variables. For example you may wish to add statically built libraries to the target, or add an additional build tool to the host.

Extensible SDK (eSDK)

An Extensible SDK (eSDK) builds upon the SDK by additionally including the devtool environment – this provides the ability to easily add or modify packages (using Yocto recipes) and rebuild the Yocto image to include any changes. The eSDK relies on it’s pre-built shared state cache to prevent long builds by using pre-built artifacts rather than building from source.

Let’s start by building an eSDK installer:

$ bitbake core-image-minimal -c populate_sdk_ext

Unfortunately this resulted in a build failure due to the OOM killer killing a process (exit code 137). We worked around this by adding the following to our build/local.conf:

XZ_MEMLIMIT = "50%"
XZ_THREADS = "4"
XZ_DEFAULTS = "--memlimit=${XZ_MEMLIMIT} --threads=${XZ_THREADS}"
XZ_DEFAULTS[vardepsexclude] += "XZ_MEMLIMIT XZ_THREADS"

Once built, the output is an installer script (.sh) file in the tmp/deploy/sdk directory. In my case it’s named “poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-ext-4.2.3.sh” and is approximately 1.9GB in size (see this page for information on the naming convention). Just like the SDK installer, it’s a single self-contained file so you can easily distribute it to others. Also generated is a second installer script (.sh) named “x86_64-buildtools-nativesdk-standalone-4.2.3.sh” which is 31M in size – this is also an eSDK installer but for developing software for the host rather than the target.

Let’s now install the eSDK, as follows:

$ ./build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-ext-4.2.3.sh 
 Poky (Yocto Project Reference Distro) Extensible SDK installer version 4.2.3
 Enter target directory for SDK (default: ~/poky_sdk): 
 You are about to install the SDK to "/home/andy/poky_sdk". Proceed [Y/n]? y
 Extracting SDK……………………………………………………………………….done
 Setting it up…
 Extracting buildtools…
 Preparing build system…
 Loading cache: 100% |                                                                                                          | ETA:  --:--:--
 Parsing recipes: 100% |#########################################################################################################| Time: 0:00:12
 Initialising tasks: 100% |######################################################################################################| Time: 0:00:00
 Checking sstate mirror object availability: 100% |##############################################################################| Time: 0:00:00
 Loading cache: 100% |###########################################################################################################| Time: 0:00:00
 Initialising tasks: 100% |######################################################################################################| Time: 0:00:01
 done
 SDK has been successfully set up and is ready to be used.
 Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
  $ . /home/andy/poky_sdk/environment-setup-core2-64-poky-linux

Now that it’s installed, let’s take a closer look at what is unpacked:

$ ls -1
bitbake-cookerdaemon.log
buildtools/
cache/
conf/
downloads/
environment-setup-core2-64-poky-linux
layers/
preparing_build_system.log
site-config-core2-64-poky-linux
sstate-cache/
sysroots/
tmp/
version-core2-64-poky-linux
workspace/

The contents of the extracted eSDK are broadly described as:

• The contents of the standard SDK which provide the sysroot directories, the version file and environment setup files
• The contents of a typical Yocto build environment (as typically found in the build/ directory) e.g. bitbake-cookerdaemon.log, as well as the cache, conf, downloads, sstate-cache and tmp directories.
• The Yocto layers (layers/)
• Sysroot for the Yocto build tools (buildtools/)

See this page for a more detailed summary of it’s contents.

Now that the eSDK is installed, we can use it by sourcing the environment set up file as follows:

$ source /home/andy/poky_sdk/environment-setup-core2-64-poky-linux
 SDK environment now set up; additionally you may now run devtool to perform development tasks.
 Run devtool --help for further details.

At this point the devtool command, which is the heart of the eSDK can be used. You may also find that the runqemu command is available. However as this isn’t a normal Yocto environment the bitbake command is unavailable (well unless you really want it).

Using Devtool in the eSDK

Once the eSDK is installed, we can begin using the ‘devtool’ utility. Let’s start by asking devtool to build the Yocto image, as follows:

$ devtool build-image -p i2c-tools
 NOTE: Starting bitbake server…
 NOTE: Reconnecting to bitbake server…
 NOTE: Retrying server connection (#1)… (13:18:50.512268)
 Loading cache: 100% |############################################################################################################################| Time: 0:00:00
 Loaded 1800 entries from dependency cache.
 INFO: Building image core-image-minimal with the following additional packages: i2c-tools
 Loading cache: 100% |############################################################################################################################| Time: 0:00:00
 Loaded 1800 entries from dependency cache.
 Parsing recipes: 100% |##########################################################################################################################| Time: 0:00:00
 Parsing of 899 .bb files complete (898 cached, 1 parsed). 1800 targets, 49 skipped, 0 masked, 0 errors.
 NOTE: Resolving any missing task queue dependencies
 Initialising tasks: 100% |#######################################################################################################################| Time: 0:00:03
 Checking sstate mirror object availability: 100% |###############################################################################################| Time: 0:00:00
 Sstate summary: Wanted 574 Local 121 Mirrors 0 Missed 453 Current 856 (21% match, 68% complete)
 NOTE: Executing Tasks
 NOTE: Tasks Summary: Attempted 3703 tasks of which 3677 didn't need to be rerun and all succeeded.
 INFO: Successfully built core-image-minimal. You can find output files in /home/andy/poky_sdk/tmp/deploy/images/qemux86-64

You’ll notice that we passed ‘-p i2c-tools’ to the build-image command. This tells devtool that we’d like to build the Yocto image but with an additional package (i2c-tools) included. Unlike a traditional Yocto build that takes hours, this took seconds. We can verify it worked by examining the manifest file for the image generated (tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.manifest) and see that i2c-tools is present.

You’ll notice in the output that it says ‘Successfully built core-image-minimal’ – the reason it built this rather than another any other image is because this is the target we originally built the eSDK against. You can build additional targets via arguments to the ‘devtool build-image’ command (though these don’t appear to be documented) – however if the eSDK hasn’t been built to include the associated packages for the image then there is no shared state cache and the eSDK user may have to sit through a long build.

Let’s use devtool to modify an existing package, let’s modify the i2c-tools package. First we need to tell devtool that this is what we want to do:

$ devtool modify i2c-tools
 NOTE: Starting bitbake server…
 NOTE: Reconnecting to bitbake server…
 NOTE: Retrying server connection (#1)… (08:53:35.045464)
 Loading cache: 100% |############################################################################################################################| Time: 0:00:00
 Loaded 1803 entries from dependency cache.
 NOTE: Resolving any missing task queue dependencies
 Initialising tasks: 100% |#######################################################################################################################| Time: 0:00:00
 Sstate summary: Wanted 13 Local 0 Mirrors 4 Missed 9 Current 7 (30% match, 55% complete)
 NOTE: Executing Tasks
 NOTE: Tasks Summary: Attempted 93 tasks of which 90 didn't need to be rerun and all succeeded.
 INFO: Source tree extracted to /home/andy/poky_sdk/workspace/sources/i2c-tools
 INFO: Using source tree as build directory since that would be the default for this recipe
 INFO: Recipe i2c-tools now set up to build from /home/andy/poky_sdk/workspace/sources/i2c-tools

You’ll notice from the above output that devtool has extracted the source for the i2c-tools and placed it in a workspace for us (anything in the workspace will be included in the image). Let’s go there and make a modification:

$ cd ~/poky_sdk/workspace/sources/i2c-tools
$ sed -i 's/4.3/4.3-tgp/g' version.h

We’ve simply updated the version string in a header file. Let’s check it builds:

$ devtool build i2c-tools
 NOTE: Starting bitbake server…
 NOTE: Reconnecting to bitbake server…
 NOTE: Retrying server connection (#1)… (09:00:01.368270)
 Loading cache: 100% |############################################################################################################################| Time: 0:00:00
 Loaded 1803 entries from dependency cache.
 Parsing recipes: 100% |##########################################################################################################################| Time: 0:00:00
 Parsing of 902 .bb files complete (901 cached, 1 parsed). 1803 targets, 49 skipped, 0 masked, 0 errors.
 Loading cache: 100% |############################################################################################################################| Time: 0:00:00
 Loaded 1803 entries from dependency cache.
 Parsing recipes: 100% |##########################################################################################################################| Time: 0:00:00
 Parsing of 902 .bb files complete (901 cached, 1 parsed). 1803 targets, 49 skipped, 0 masked, 0 errors.
 NOTE: Resolving any missing task queue dependencies
 Initialising tasks: 100% |#######################################################################################################################| Time: 0:00:01
 Checking sstate mirror object availability: 100% |###############################################################################################| Time: 0:00:02
 Sstate summary: Wanted 102 Local 0 Mirrors 23 Missed 79 Current 51 (22% match, 48% complete)
 NOTE: Executing Tasks
 NOTE: i2c-tools: compiling from external source tree /home/andy/poky_sdk/workspace/sources/i2c-tools
 NOTE: Tasks Summary: Attempted 635 tasks of which 625 didn't need to be rerun and all succeeded.

That seems to work. At this point we could make use of the ‘devtool deploy’ command which would kindly SSH the package to the target for us to test. However let’s assume our changes are good and finish up as follows:

$ cd ~/poky_sdk/workspace/sources/i2c-tools
$ git commit -am 'update version'
$ devtool finish i2c-tools ../../../layers/poky/meta-yocto-bsp
NOTE: Starting bitbake server…
 Loading cache: 100% |############################################################################################################################| Time: 0:00:00
 Loaded 1803 entries from dependency cache.
 Parsing recipes: 100% |##################################################################################$ devtool finish i2c-tools ../../../layers/poky/meta-yocto-bsp
 NOTE: Starting bitbake server…
 NOTE: Reconnecting to bitbake server…
 NOTE: Retrying server connection (#1)… (13:25:03.868484)
 Loading cache: 100% |############################################################################################################################| Time: 0:00:00
 Loaded 1800 entries from dependency cache.
 Parsing recipes: 100% |##########################################################################################################################| Time: 0:00:00
 Parsing of 899 .bb files complete (898 cached, 1 parsed). 1800 targets, 49 skipped, 0 masked, 0 errors.
 NOTE: Writing append file /home/andy/poky_sdk/layers/poky/meta-yocto-bsp/recipes-devtools/i2c-tools/i2c-tools_%.bbappend
 NOTE: Copying 0001-update-version.patch to /home/andy/poky_sdk/layers/poky/meta-yocto-bsp/recipes-devtools/i2c-tools/i2c-tools/0001-updated-version.patch
 INFO: Cleaning sysroot for recipe i2c-tools…
 INFO: Preserving source tree in /home/andy/poky_sdk/workspace/attic/sources/i2c-tools.20231019132510
 If you no longer need it then please delete it manually.
 It is also possible to reuse it via devtool source tree argument.

First we commited our changes to the i2c-tools repository. Then we ran ‘devtool finish’ which takes those changes and applies them to the Yocto recipe. In our example above we specified the layer that the changes should be applied to, ideally this would be a custom layer, but as an example (and for brevity) we chose meta-yocto-bsp – you’ll see that Yocto has added a recipe with a .bbappend which includes a patch which represents the changes we commited to git.

At this point we could regenerate our Yocto image via the ‘devtool build-image -p i2c-tools’ command and have our modifications included.

Shared state cache in the eSDK

One of the benefits of using the eSDK is that it makes use of the shared state cache which was built by the author of the eSDK and packaged up into the eSDK via the populate_sdk_ext task. This ensures that the eSDK doesn’t have to build code they don’t care about.

You’ll notice in the conf directory two files, one called locked-sigs.inc and one called unlocked-sigs.inc – these files place restrictions on what Yocto will build from source. Any package listed in locked-sigs.inc won’t be built from source, but instead will be obtained via the shared state cache. Any package listed in unlocked-sigs.inc can be built from source. If we take a look at that file you’ll see i2c-tools is now there:

$ cat conf/unlocked-sigs.inc 
 DO NOT MODIFY! YOUR CHANGES WILL BE LOST.
 This layer was created by the OpenEmbedded devtool utility in order to
 contain recipes that are unlocked.
 SIGGEN_UNLOCKED_RECIPES += "\
     i2c-tools"

This isn’t a perfect system and sometimes packages are rebuilt from source when you don’t expect it to. However this is something that the Yocto community are actively working on. For example. one issue we’ve seen is that if modifying an existing package such as bash, anything that depends on it will get rebuilt from source (see layers/poky/meta/lib/oe/sstatesig.py) – this shouldn’t be the case and results in a long build time.

Minimal eSDK Installer and eSDK Updates

As you may have seen by now, the eSDK relies on metadata to know what packages are available, and relies on the shared state cache to obtain pre-built package artifacts to avoid long builds. One of the most interesting features about the eSDK is that it can be configured with a URL to a remote metadata store and a shared state cache – this provides two additional benefits – the first is that the eSDK can be updated (via the ‘devtool sdk-update’ command) allowing it to become aware of new packages and to obtain the shared state for them. And second, as a result of this, initial installer file can be minimal in size relying instead on the remote shared state cache to obtain data as needed. Let’s take a look at these features in more detail.

Let’s take a look at the ‘devtool search’ command, this command looks up the meta data (contents of layers/ directory) to find packages with the given name, let’s search for ‘gptfdisk’:

$ devtool search gptfdisk
 NOTE: Starting bitbake server…
 NOTE: Reconnecting to bitbake server…
 NOTE: Retrying server connection (#1)… (13:33:28.282415)
 Loading cache: 100% |############################################################################################################################| Time: 0:00:00
 Loaded 1800 entries from dependency cache.
 gptfdisk              Utility for modifying GPT disk partitioning
 gptfdisk-native       Utility for modifying GPT disk partitioning

As the above output shows, it knows about a gptfdisk package. It’s not part of the core-image-minimal image, though it is present in one of the meta layers that was available when we built the eSDK. However if we build it via ‘devtool build-image -p gptfdisk’ it will attempt to build gptfdisk and its dependencies from source. This is because there is no shared state cache for this (as the eSDK only included shared state for the core-image-minimal image).

Fortunately, we can update the eSDK to point to a shared state cache hosted online. But first we need to build gptfdisk in our original Yocto distribution to generate some shared state. That’s easy to do:

$ bitbake gptfdisk

That’s enough to put the shared state in the original Yocto distribution’s shared state cache but we need to also share it with the eSDK user. The first step is publishing the shared state online, we did they locally by setting up an Apache server and hosting the contents of Yocto’s build/sstate-cache directory. This resulted in a directory listing at http://127.0.0.1/sstate that contained directory names such as 0a, 0b, 0c, 0d, etc.

The next step is to make this available to the eSDK user, that’s achieved by creating a file named conf/sdk-extra.conf in the original Yocto distribution with the following contents:

SSTATE_MIRRORS = "file://.* http://127.0.0.1/sstate/PATH;downloadfilename=PATH"

As a result, the next time an eSDK is generated, the conf/local.conf in the extracted eSDK will contain the SSTATE_MIRRORS variable (you can add this to the installed eSDK manually if you so wish).

At this point, you can now use the eSDK to add additional packages to the build that weren’t previously part of core-image-minimal (but were part of the initial layers) – and thanks to the shared state cache you won’t have to build them from source (so long as the eSDK author has generated shared state cache for them as we did for gptfdisk).

If you wish to make all packages available to the eSDK user via the shared state cache then you can build them via the ‘bitbake world’ command – but naturally this will take a long time.

In our previous example of gptfdisk we simply added it to the build image. What if this was instead a library that we wanted to link against? Of course in the devtool/bitbake world we simply add dependencies to our recipes and Yocto will take care of making everything work. However if you wanted to manually link again a library you’ve added, you’d need to update the sysroot. Yocto provides a way to do this via the ‘devtool sdk-install’ command. Here is an example:

$ devtool build-image -p libsoup
$ find . -name libsoup-3.0.so
 ./tmp/work/core2-64-poky-linux/libsoup/3.2.2-r0/image/usr/lib/libsoup-3.0.so
 ./tmp/work/core2-64-poky-linux/libsoup/3.2.2-r0/package/usr/lib/libsoup-3.0.so
 ./tmp/work/core2-64-poky-linux/libsoup/3.2.2-r0/packages-split/libsoup-dev/usr/lib/libsoup-3.0.so
 ./tmp/work/core2-64-poky-linux/libsoup/3.2.2-r0/build/libsoup/libsoup-3.0.so
$ devtool sdk-install libsoup
$ find . -name libsoup-3.0.so
 ./tmp/sysroots/qemux86-64/usr/lib/libsoup-3.0.so
 ./tmp/work/core2-64-poky-linux/libsoup/3.2.2-r0/image/usr/lib/libsoup-3.0.so
 ./tmp/work/core2-64-poky-linux/libsoup/3.2.2-r0/package/usr/lib/libsoup-3.0.so
 ./tmp/work/core2-64-poky-linux/libsoup/3.2.2-r0/packages-split/libsoup-dev/usr/lib/libsoup-3.0.so
 ./tmp/work/core2-64-poky-linux/libsoup/3.2.2-r0/sysroot-destdir/usr/lib/libsoup-3.0.so
 ./tmp/work/core2-64-poky-linux/libsoup/3.2.2-r0/build/libsoup/libsoup-3.0.so
 ./tmp/sysroots-components/core2-64/libsoup/usr/lib/libsoup-3.0.so

You can see from the above output that the use of sdk-install resulted in additional files being added to the sysroot. Under the hood Yocto simply runs the ‘bitbake build-sysroots’ command.

We found that the sdk-install command will fail and say the package is ‘unavailable’ if shared state cache cannot be found (which is good) – however it will still allow you to run the ‘bitbake build-image -p’ command to build that same package, and will build it from source (which is not good).

It’s probably also worth pointing out that the locked-sigs.inc file we described earlier doesn’t appear to get updated with new signatures for new packages added, so there is always a risk that these packages may be rebuilt from source.

So far we’ve discussed making use of packages that weren’t present in the original Yocto image but were present in the available meta-layers. So what happens if, as the author of a Yocto distribution, you want to add new packages (or layers) and make those available to your eSDK users? That’s possible, as the eSDK is updateable. To set this up we need to add the following to the local.conf of the original Yocto distribution as follows:

SDK_UPDATE_URL = "http://127.0.0.1/esdk"

Once the eSDK has been build and installed, this variable will tell the eSDK where it can look for updates. The contents of http://127.0.0.1/esdk are populated via the following command:

$ bitbake core-image-minimal -c populate_sdk_ext
$ oe-publish-sdk build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-ext-4.2.3.sh  /var/www/html/esdk/

Finally, given the eSDK now knows where to get updates from (for both shared state and meta data) we can also update our local.conf to set the type of eSDK to be minimal (you’ll have to rebuild the eSDK) as follows. This results in a much smaller installer (42MB in my case) file.

SDK_EXT_TYPE = "minimal"

Let’s install the minimal eSDK and try it out:

$ ./build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-ext-4.2.3.sh
$ cd ~/poky_sdk
$ . ./environment-setup-core2-64-poky-linux
$ devtool build-image

Despite the minimal eSDK install, everything built as expected thanks to its use of the online shared state cache.

Let’s now make a change to our Yocto distribution, rebuild the eSDK, install it to our webserver and see those updates become available to the eSDK user.

To do this we’ve created a very simple helloworld.bb in our Yocto distribution that simply touches a file. Let’s now rebuild and redeploy our SDK:

$ bitbake core-image-minimal -c populate_sdk_ext
$ oe-publish-sdk build/tmp/deploy/sdk/poky-glibc-x86_64-core-image-minimal-core2-64-qemux86-64-toolchain-ext-4.2.3.sh  /var/www/html/esdk/

And now the eSDK user can pull in those changes via the ‘devtool sdk-update’ command:

$ devtool sdk-update
 NOTE: Starting bitbake server…
 NOTE: Reconnecting to bitbake server…
 From http://127.0.0.1/esdk/layers/
    b152ef8297c4..a47c4c9fe81c  master     -> origin/master
 HEAD is now at a47c4c9fe81c init repo
 INFO: Preparing build system… (This may take some time.)

And that should now provide the eSDK user access to our new package:

$ devtool search helloworld
 NOTE: Starting bitbake server…
 NOTE: Reconnecting to bitbake server…
 NOTE: Retrying server connection (#1)… (19:25:02.837902)
 Loading cache: 100% |############################################################################################################################| Time: 0:00:00
 Loaded 1813 entries from dependency cache.
 go-helloworld         
 helloworld            Test Application

Well that looked like it worked – our helloworld package is now available to be installed. For more information on the eSDK and it’s customisation please see Yocto’s documentation.

The Yocto SDK provides a convenient way to allow application developers to develop against a Yocto distribution. The eSDK builds upon this and makes the devtool available resulting in the ability to rebuild the final image and to modify existing packages, but without the slow build times normally associated with Yocto.

For more information on Yocto SDK’s please read the official documentation which can be found here.