Yocto Project

Creating Custom Embedded Linux Distribution

 Outline
First dive into the Yocto Project. Recipes and layers details: write, use,
customize
• Overview of an embedded Linux build
• Recipes syntax. Writing a recipe.
systems
• Development work-flow in the
• Organization of the Yocto Project Yocto Project with BitBake.
source tree. • Adding packages to the generated
• Customizing an image. image.
• The Yocto Project layers. Adding a
• Building an image. new layer.
 Build System
What is Build System ?
• Software Tools.
• Designed to automate the process of program compilation.
• Goal: Efficiently create the executables.
• Purpose:
–Compiling or cross-compiling applications.
–Packaging applications.
–Testing output binaries and ecosystem compatibility.
–Deploying generated images.
 Embedded Linux
Build System

• Goal is to build a complete, customized, embedded Linux system

• Root file system, tool chain, kernel, boot loaders
• Build from scratch from source
• Using cross-compilation
• Very actively maintained and developed projects
• Widely used in the industry
• Well documented
• Free software
 Build System
List
• Buildroot, developed by the community.
http://www.buildroot.org
• PTXdist, developed by Pengutronix.
http://pengutronix.de/software/ptxdist/
• OpenWRT, originally a fork of Buildroot for wireless routers, now a more generic project.
http://www.openwrt.org
• OpenEmbedded, based build system.
Poky (from the Yocto Project)
http://www.openembedded.org/
 Build Systems
Comparisons
• Buildroot
• Poky
• Simple to use.
• Part of the Yocto Project.
• Adapted for small embedded devices.
• Using OpenEmbedded.
• Not perfect if you need advanced
functionalities and multiple machines • Suitable for more complex embedded
support. systems.

• OpenWRT • Allows lots of customization.

• Can be used for multiple targets at the same
• Based on Buildroot.
time.
• Primarily used for embedded network
devices like routers.
 Build System
Poky: Benefits
• Automate the process of building image for a target system, including the kernel, and sometimes
the tool chain
• Automatically download, configure, compile and install all the components in the right order.
• Applies patches to fix cross-compiling issues.
• Resolve application dependencies.
• Already contain a large number of packages, that should fit your main requirements and are easily
extensible.
• The build becomes reproducible, which allows to easily change the configuration of some
components, upgrade them, fix bugs.
• Several configurations can be handled in the same project.
• Possible to generate the same root file system for different hardware targets.
 Build System
Building Open Embedded S/W packages

1. Fetch
2. Extract
3. Patch
4. Configure
5. Build
6. Install
7. Package
Building Open Embedded S/W packages

1)Fetch
➔Downloading the s/w packages from the ➔Some projects provides access to
download area Released versions
➔Usually it will be tar files in compressed Development branches through, git, SVN
form. etc
➔Downloads are accessible through ➔Download packages contains,
protocols,
Source code
• HTTP
Patch files
• HTTPS
Auxiliary files
• FTP
• SFTP etc

OE Build System will automate the above process.

Building Open Embedded S/W packages
2) EXTRACT
• Unpacking and copying to the build location.
• If source code obtained from the SCM, then extract refers
to checking them out to the area where bitbake builds
them

OE Build System should automatically select the right tool to extract the SOURCES
Building Open Embedded S/W packages
3) Patch
➔Process of incrementally modifying the How Does the Build System Handle
source code by adding, deleting or changing Patches?
the source files. ➔Build System needs to know where to
➔Why? copy the patch
To fix the bugs. files.
To address the security issues. ➔Order in which patches are applied is
To add the extra features. important.

To provide the configuration information. ➔Quilt management system simplifies the

task by creating patch stack to maintain the
Making adjustment for the Cross Building. order.

Quilt: Series of shell scripts

Building Open Embedded S/W packages
4) Configure
➔Accurate configuration is very important for the cross-build
environment.
➔Many S/W packages uses AUTOTOOLS configuration, these tools are
hard to use.
➔OpenEmbedded BS automates the configuration tasks.
Building Open Embedded S/W packages
5) Build
➔ What Happens in the Build Step?
Source codes are converted into the binary images.
➔ BitBake Does the Heavy Lifting
OE uses bitbake to achieve this job.
Building Open Embedded S/W packages
6) Install
➔ Copying the binaries, libraries, docs, configuration files to the correct location in
the target machines.
➔ Examples,
User programs should be installed in /usr/bin
System programs should be installed in /usr/sbin
Config files to be installed in /etc
Libraries to be installed in /usr/lib
Who Does the Installing?
➔Install target in the Makefile correctly written will do the job of installing.
➔ Install utility also sets file permissions and the file
ownership while copying the files to the target machine.
Building Open Embedded S/W packages
7) Packages
--It the process of bundling the
o Software
o Binaries
o Auxiliary files into the single archive.
--This step is needed for the distribution purpose.
Common Package Formats in Yocto
--RPM (Red hat package manager)
o Dpkg (Debian package manager)
o Opkg (Openmoko for the Embedded projects)
ownership while copying the files to the target machine.
 Build System
Work-flow
●The workflow is determined by the metadata organized
in the metadata files.
●Metadata files
• Config files (.conf)
• Recipes
 Build System
Work-flow
●Config files (.conf)
1. bitbake.conf
2. layer.conf
3. bblayers.conf
4. local.conf
5. <distribution-name>.conf
6. <machine-name>.conf
 Build System
Work-flow
●bitbake.conf
1. Master configuration file
2. Contains default settings.
3. Other configuration files and recipes can override the variable
settings in this file.
4. Part of the OE-Core metadata layer.
 Build System
Work-flow

●layer.conf -Layer Metadata Settings

• Contains the path settings and the file patterns of the recipes of the
layer.

●bblayers.conf -Build Layer Inclusion

• Build environment layer configuration.
• This tells to the bitbake engine to include what layers needed for the
build.
 Build System
Work-flow
●local.conf
1. Local configuration for the build environment.
2. Contains the settings, such as,
-Paths to download locations
-Build output
-Config setting for the target machine.
-Package management system
 Build System
Work-flow
●local.conf
1. Local configuration for the build environment.
2. Contains the settings, such as,
-Paths to download locations
-Build output
-Config setting for the target machine.
-Package management system
 Build System
Work-flow
●<distribution-name>.config
1. Contains variable setting reflecting the policies that apply for the
particular distribution.
2. Distribution policy settings typically include toolchain, C library,
distribution name etc.
3. For Eg., the poky reference distribution, the default image name is
also Poky.
 Build System
Work-flow
●<machine-name>.config
• This file contains machine-dependent settings used by
recipes that need to behave differently for different
hardware.
• Found in conf/machine BSP layer.
 Build System
Work-flow
●Recipes
• Contains the instructions for the bitbake on how to build a
particular software package.
• Identified by the .bb files
• All variable assignments made in this file is local to this
recipe only.
The Yocto Project &
Poky Reference
System
Overview
Yocto Project
Overview
●The Yocto Project is a set of templates, tools and
methods that allow to build custom embedded Linux-
based systems.
●It is an open source project initiated by the Linux
Foundation in 2010
●Managed by one of its fellows: Richard Purdie.
https://www.yoctoproject.org/
Yocto Project
How does it works?
Yocto Project
Core Components
BitBake
–The build engine.
–It is a task scheduler, like make.
–It interprets configuration files and recipes (also called metadata)
to perform a set of tasks, to download, configure and build specified
packages and filesystem images.
Yocto Project
Core Components
● OpenEmbedded-Core
–A set of base layers.
–It is a set of recipes, layers and classes which are shared
between all OpenEmbedded based systems.
● Poky
– The reference system
–It is a collection of projects and tools, used to bootstrap a new
distribution based on the Yocto Project.
Yocto Project
The Poky reference system Source Tree
bitbake/
–Holds all scripts used by the BitBake command.
–Usually matches the stable release of the BitBake project.
documentation/
–All documentation sources for the Yocto Project documentation.
–Can be used to generate PDFs.
meta/
–Contains the OpenEmbedded-Core metadata.
Yocto Project
The Poky reference system Source Tree
meta-skeleton/
–Contains template recipes for BSP and kernel development.
meta-poky/
–Holds the configuration for the Poky reference distribution.
meta-yocto-bsp/
–Configuration for the Yocto Project reference hardware board support package
LICENSE
–The license under which Poky is distributed (a mix of GPLv2 and MIT).
Yocto Project
The Poky reference system Source Tree
●oe-init-build-env
–Script to set up the OpenEmbedded build environment.
–It will create the build directory.
–It takes an optional parameter which is the build directory name. By
default, this is build.
–This script has to be sourced because it changes environment
variables.
● scripts
– Contains scripts used to set up the environment, development tools and tools to flash the generated
images on the target.
Environmental Setup
oe-init-build-env
●Modifies the environment: has to be sourced!
●Adds environment variables, used by the build engine.
●Allows you to use commands provided in Poky.
●source ./oe-init-build-env [builddir]
●Sets up a basic build directory, named builddir if it is not found.
●If not provided, the default name is build.
●All Poky files are left unchanged when building a custom image.

BUILDDIR is Environment Variable which is used to define Absolute path of the build directory.
Environmental Setup
Common Targets
●Core-image-minimal
– A small image to boot a device and have access to core command line commands
and services.
●Core-image-sato
–Image with Sato support. Sato is a GNOME mobile-based user interface.
●Meta-toolchain
–Includes development headers and libraries to develop directly on the target.
●Meta-ide-support
–Generates the cross-toolchain. Useful when working with the SDK.
Environmental Setup
Commands
●bitbake
–The main build engine command.
–Used to perform tasks on available packages (download, configure, compile...).
●bitbake-*
–Various specific commands related to the BitBake build engine.(Eg. bitbake-layers)
●yocto-layer
–Command to create a new generic layer.
●yocto-bsp
–Command to create a new generic BSP.
Build Directory
/build
conf/
Configuration files. Image specific and layer configuration.
downloads/
Downloaded upstream tarballs of the packages used in the builds.
sstate-cache/
Shared state cache. Used by all builds.
tmp/
Holds all the build system outputs.
tmp/buildstats/
Stores performance and timing info for each package built.(e.g., CPU usage, elapsed time, host info).
Build Directory
/build
tmp/deploy/images/
Contains the complete images built by the OpenEmbedded build system.
These images are used to flash the target.
tmp/work/
Set of specific work directories, split by architecture.
They are used to unpack, configure and build the packages.
Contains the patched sources, generated objects and logs.
tmp/sysroots/
Shared libraries and headers used to compile packages for the target but also for the host.
Configuring: Build System
/build/conf/
The conf/ directory in the build one holds build specific configuration.
bblayers.conf
● Explicitly list the available layers.
local.conf
●Set up the configuration variables relative to the current user for the
build.
●Configuration variables can be overridden there.
Configuring: Build System
/build/conf/local.conf
●The conf/local.conf configuration file holds local user configuration variables:
–BB_NUMBER_THREADS
●How many tasks BitBake should perform in parallel.
●Defaults to the number of CPUs on the system.
–PARALLEL_MAKE
●How many processes should be used when compiling.
●Defaults to the number of CPUs on the system.
–MACHINE
●The machine the target is built for, e.g. RaspberryPi.
–PACKAGE_CLASSES
●Packages format (deb, ipk or rpm).
Building an Image
Compilation
●The compilation is handled by the BitBake build engine.
●Usage: bitbake [options] [recipename/target …]
●To build a target: bitbake [target]
●Building a minimal image: bitbake core-image-minimal
–This will run a full build for the selected target.
Building an Image –Lab
●Download the sources
●Set up the environment
●Configure the build
●Build an image
BitBake
How it is different from others
●Its metadata syntax not only enables
–Variables
–But also integrates
●Shell scripts
●Python functions.
BitBake
Running the BitBake
●BitBake always must be called with basename of the recipe or target
as the parameter.
●Example: bitbake core-image-minimal
●Core-image-minimal corresponds to the file core-image-minimal.bb
●BitBake will not automatically looks for the recipe in the current
working directory.
●Bitbake requires to set-up an execution environment before hand.
BitBake
BitBake Execution Environment
●BitBake first searches for the conf/bblayers.conf file.
●Bitbake expects this file to contain the variable, BBLAYERS
●Layers contained in this path is expected to contain conf/layer.conf file
●The purpose of the layer.conf file is to set-up, BBPATH and BBFILES
variables, so that bitbake can find recipes, classes, config files.
●BBPATH : Contains path to classes(.bbclass files) and conf files(.conf
files) in the sub-directories classes and the configuration DIR conf.
●BBFILES : Contains path to recipes files
BitBake
The Flow
●After parsing conf/bblayers.conf, bitbake looks for conf/bitbake.conf
which provides build system set-up.
●After parsing conf/bitbake.conf and other .conf files, it locates and
parses all classes.

Note: Atleast base.bbclass must be present for the bitbake to operate correctly, which provides
Basic functions like build task
BitBake
Common Bitbake Options
●BitBake can be used to run a full build for a given target with bitbake [target].
●But it can be more precise, with optional options:
-c <task> execute the given task
-s list all locally available packages and their versions
-f force the given task to be run by removing its stamp file
world keyword for all packages
-b <recipe> execute tasks from the given recipe (without resolving
dependencies).
BitBake
Bitbake: Examples
●bitbake -c listtasks virtual/kernel
–Gives a list of the available tasks for the package virtual/kernel. Tasks are prefixed with do_.
●bitbake -c menuconfig virtual/kernel
– Execute the task menuconfig on the kernel package.
● bitbake -f dropbear
– Force the dropbear package to be rebuilt from scratch.
● bitbake -c fetchall world
–Download all package sources and their dependencies.
● For a full description: bitbake --help
BitBake
Bitbake: Metadata
● Metadata: It describes how the software packages are built, their relations and dependencies.
● Metadata are classified into
–Variables (SRC_URI, DEPENDS, LICENSE, FILESEXTRAPATHS)
–Executable Metadata (Eg. Tasks: do_fetch, do_compile, do_install, do_package)
●Functions and tasks embedded inside the recipes and classes.
●Categories
.conf
.bb
.bbclass
.bbappend
.inc
BitBake
Bitbake Metadata : It's Catagories
● .conf files
–Metadata in this files is global and affects all recipes referencingthem.
–It contains only variables, no executables metadata.
–If same variable is assigned in multiple conf files, then order established by the
layer priority determines which variable to be evaluated.
– bitbake.conf has lowest priority, local.conf has the highest.
BitBake
Bitbake Metadata : It's Catagories
● .bb files
–Describes a particular s/w packages and how it is built.
–It provides executable metadata in the form of tasks with instructions for
●Downloading
●Unpacking
●Patching
●Compiling
●Packaging
●Installing...
BitBake
Bitbake Metadata : It's Catagories
● .bbclass files
–Provides inheritance mechanism for the recipes to share same build instructions.
– Bitbake searches for class files inside the classes directory of the layer.
–Recipes includes classes by directive inherit
–Classes are global.

What Can be Inherited?

• Common build tasks
• Predefined variables
• Configuration defaults
BitBake
Bitbake Metadata : It's Catagories
● .bbappend files
–Extensions to recipe files.
–Layer uses append files to extend a recipe contained in another layer.
–Will have .bbappend with the same base name.
–Contains additional or Modified metadata.

When Are .bbappend Files Used?

1)Customization per Layer.
2)Layer Priority.
BitBake
Bitbake Metadata : It's Catagories
● .inc files
––Any metadata file can include other files using directives,
●include
●require
–Provides metadata that is commonly shared.
–Content of metadata file is expanded where it is included in the include files.
–Files containing executable metadata may be included only by
●Recipes ●Classes ●Append files
BitBake
Shared State Cache
●BitBake stores the output of each task in a directory, the shared state cache.
–Its location is controlled by the SSTATE_DIR variable.
●This cache is use to speed up compilation. (Task Reuse, Efficiency in Incremental Builds)
●Over time, as you compile more recipes, it can grow quite big.
–It is possible to clean old data with:
$ ./scripts/sstate-cache-management.sh --remove-duplicated -d \ --cache-dir=<SSTATE_DIR>
Recipes
Basics
●Recipes describe how to handle a given package.
●A recipe is a set of instructions to describe how to retrieve, patch, compile, install and
generate binary packages for a given application.
●It also defines what build or runtime dependencies are required.
●The recipes are parsed by the BitBake build engine.
●The format of a recipe file name is
<package-name>_<version>-<revision>.bb
Recipes
Basics: Recipe Filename
●The format of a recipe file name is
<package-name>_<version>-<revision>.bb
–Example:
●linux-yocto_3.14.bb
●Linux-yocto_3.14-r0.bb
●wpa-supplicant_2.2.bb
–The fields package-name, version and revision are assigned to the variables PN, PV, PR
respectively.
Recipes
Basics: Recipe Layout
●Descriptive Metadata
–SUMMARY : One line short description about the package.
–DESCRIPTION: An extended details of the package and what it provides.
–AUTHOR: Name and e-mail address of the author
●Ex: AUTHOR = “Santa Claus <santa@gmail.com>”
–HOMEPAGE: The URL, where the package is hosted.
–BUGTRACKER: The URL, to the project's bug tracking system.
Recipes
Basics: Recipe Layout
●Package Manager Metadata
–SECTION: Example Usage: SECTION = "net"
●The category the software package belongs to.
●Package management tools uses this to organize the packages.
●Examples of common categories:
–app
–audio
–base
–libs etc
Recipes
Basics: Recipe Layout
●Package Manager Metadata
–PRIORITY:
●Use to tell the package management tools whether a software package is required for the system to operate is
–Optional
–Eventually conflicts with other packages
●Priorities are:
–Standard: Packages that are standard for any linux distribution
–Required: Packages necessary for the proper function of the system.
–Optional: Not necessary but for a reasonably usable system
–Extra: Packages that may conflict with other from higher priorities.
Recipes
Basics: Recipe Layout
●Licensing Metadata
–LICENSE:
●The name of the license used for the software packages. LICENSE = "GPLv2"
LICENSE = "MIT & BSD"
●Single or Multiple licenses can be applied. LICENSE = "LGPL-2.1 | Apache-2.0"
●Multiple licenses can be & or | together.
–LIC_FILES_CHEKSUM:
Allows tracking changes to the license file itself.

●Inheritance Directives and Includes

–Contains the inherit directives for the recipe to inherit functionality from classes.
–Can also contain include and / or require statements. Example:
inherit autotools pkgconfig
include recipes-common/custom.inc
require mylayer/custom-settings.inc
Recipes
Basics: Recipe Layout
Build Metadata
–Provides settings to build the software packages
●PROVIDES
●DEPENDS
●PN
●PV
●PR
●SRC_URI
●SRCDATE
●S etc
Recipes
Basics: Recipe Layout
Packaging Metadata
–PACKAGES
Example: PACKAGES = "${PN}-dbg ${PN}-dev ${PN}"

–FILES
Example: FILES_${PN} = "/usr/bin/mypackage"
FILES_${PN}-dev = "/usr/include/mypackage"

–PACKAGE_BEFORE_PN
Example: PACKAGE_BEFORE_PN = "${PN}-dev ${PN}-dbg"
Recipes
Basics: Recipe Layout
● Task Overrides, Prepends and Appends
–This section contains override, prepend or append to the tasks to redefine, change or extend the default
behavior.
Overrides do_install:raspberrypi() {
echo "Installing for
Raspberry Pi" }

Prepend (_prepend)

do_install_prepend() {
echo "Pre-compilation
steps"
}
Recipes
Basics: Recipe Layout
●Run-time Metadata

–RDEPENDS
●List of packages that this package depends at the run-time

●Example: If the package depends on Perl to operate correctly then,

RDEPENDS_${PN}-dev += “perl” should be done.

–RRECOMMENDS
●Similar to the RDEPENDS but have weak dependencies, failure to install will not fail to build, but to extend the functionalit y.

–RSUGGESTS
●Similar to RRECOMMENDS but even weaker in the sense that package managers will not install these packages even if they are
available.
●Only provides the info that installing these will be beneficial.
–RPROVIDES

–RCONFLICTS ● List of names of the conflicting packages.

Recipes
Content
●A recipe contains configuration variables:
–name, license,dependencies, path to retrieve the source code...
●It also contains functions that can be run (fetch, configure, compile...) which are called tasks.
●Tasks provide a set of actions to perform.

bitbake -c <task> <package>

Recipes
Common Variables
● To make it easier to write a recipe, some variables are automatically available:

PN package name, as specified in the recipe file name

PV package version, as specified in the recipe file name
PR package release, defaults to r0

●The recipe name and version usually match the upstream package ones.
●When using the recipe bash_4.2.bb:
${PN} = "bash"
${PV} = "4.2"
Recipes
Organization
poky
meta-custom

meta/recipes-core/init-ifupdown/ recipes-core/init-ifupdown/
init-ifupdown_1.0.bb init-ifupdown_1.0.bbappend

meta-ti

recipes-bsp/u-boot recipes-bsp/u-boot
u-boot-ti.inc u-boot-ti.inc
u-boot_2025.07.bb u-boot_2025.07.bbappend
Recipes
Organization
●Many packages have more than one recipe, to support different versions.
●In that case the common metadata is included in each version specific recipe and is in a .inc file:
<package>.inc: version agnostic metadata.
<package>_<version>.bb: require <package>.inc and version specific metadata.
● We can divide a recipe into three main parts:
–The header: what/who
–The sources: where
–The tasks: how
Recipes
The source locations: overview
●We need to retrieve both the raw sources from an official location and the resources
needed to configure, patch or install the package.
●SRC_URI defines where and how to retrieve the needed elements. It is a set of URI
schemes pointing to the resource locations (local or remote).
●URI scheme syntax: scheme://url;param1;param2
●scheme can describe a local file using file:// or remote locations with https://, git://,
svn://, hg://, ftp://...
●By default, sources are fetched in $BUILDDIR/downloads.
Change it with the DL_DIR variable in conf/local.conf
Recipes
The source locations: remote files
●The git scheme:
–git://<url>;protocol=<protocol>;branch=<branch>
–When using git, it is necessary to also define SRCREV.
●If SRCREV is a hash or a tag not present in master, the branch parameter is mandatory.
●When the tag is not in any branch, it is possible to use nobranch=1
●The http, https and ftp schemes:
–https://example.com/package-1.0.tar.bz2
–A few variables are available to help pointing to remote locations:
●${SOURCEFORGE_MIRROR}, ${GNU_MIRROR}, $KERNELORG_MIRROR}...
–Example: ${SOURCEFORGE_MIRROR}/<project-name>/${PN}- ${PV}.tar.gz
–See meta/conf/bitbake.conf
Recipes
The source locations: remote files
● An md5 or an sha256 sum must be provided when the protocol used to retrieve the file(s) does not guarantee their
integrity. This is the case for https,http or ftp.
–SRC_URI[md5sum] = "97b2c3fb082241ab5c56ab728522622b"
–SRC_URI[sha256sum] = "..."

●It's possible to use checksums for more than one file, using the name parameter:
–SRC_URI = "http://example.com/src.tar.bz2;name=tarball \
http://example.com/fixes.patch;name=patch"
–SRC_URI[tarball.md5sum] = "97b2c3fb082241ab5c56..."
–SRC_URI[patch.md5sum] = "b184acf9eb39df794ffd..."
Recipes
The source locations: local files
●All local files found in SRC_URI are copied into the package's working directory, in build/tmp/work/.
●The searched paths are defined in the FILESPATH variable.
FILESPATH = "${@base_set_filespath([
"${FILE_DIRNAME}/${PN}",
"${FILE_DIRNAME}/${PN}-${PV}",
"${FILE_DIRNAME}/files"], d)}"
FILESOVERRIDES="$MACHINEOVERRIDES}:DISTROOVERRIDES}"
● The base_set_filespath(path) function uses its path parameter, FILESEXTRAPATHS and FILESOVERRIDES to fill the
FILESPATH variable.
●Custom paths and files can be added using FILESEXTRAPATHS and FILESOVERRIDES.
●Prepend the paths, as the order matters, prepend with :=
Recipes
The source locations: tar balls
● When extracting a tar ball, BitBake expects to find the extracted files in a directory
named <package-name>-<version>.
● This is controlled by the S variable. If the directory has another name, you must
explicitly define S.
S = "${WORKDIR}/${PN}-${PV}"
● If the scheme is git, S must be set to ${WORKDIR}/git
Recipes
The source locations: license files
●License files must have their own checksum.
●LIC_FILES_CHKSUM defines the URI pointing to the license file in the source code as well as its
checksum.
–LIC_FILES_CHKSUM = "file://gpl.txt;md5=393a5ca..."
–LIC_FILES_CHKSUM = \
"file://main.c;beginline=3;endline=21;md5=58e..."
– LIC_FILES_CHKSUM = \
"file://${COMMON_LICENSE_DIR}/MIT;md5=083..."
●This allows to track any license update: if the license changes, the build will trigger a failure as the
checksum won't be valid anymore.
Recipes
Dependencies
● Sometimes a package have dependencies on specific versions of another
package.
●BitBake allows to reflect this by using:
–DEPENDS = "package-b (>= 1.2)" (Build Time)
–RDEPENDS_${PN} = "package-b (>= 1.2)" (Run time)
● The following operators are supported: =, >, <, >= and <=.
Recipes
Tasks
● Default tasks already exists, they are defined in classes:
–do_fetch
–do_unpack
–do_patch
–do_configure
–do_compile
–do_install
–do_package
–do_rootfs
●You can get a list of existing tasks for a recipe with:
bitbake <recipe> -c listtasks
Recipes
Writing Tasks
● Functions use the sh shell syntax, with available OpenEmbedded variables and internal functions
available.
D The destination directory (root directory of where the files are installed, before creating the
image).
WORKDIR The package's working directory
● Syntax of a task:
do_task() {
action0
action1
...
}
Recipes
Writing Tasks
●Example
do_compile() {
${CC} ${CFLAGS} ${LDFLAGS} -o hello ${WORKDIR}/hello.c
}
do_install() {
install -d ${D}${bindir}
install -m 0755 hello ${D}${bindir}
}
Recipes
Writing Tasks
●Example: Using Makefile
do_compile() {
oe_runmake
}
do_install() {
install -d ${D}${bindir}
install -m 0755 hello ${D}${bindir}
}
Recipes
Modifying Existing Tasks
●Tasks can be extended with _prepend or _append

do_install_append() {
install -d ${D}${sysconfdir}
install -m 0755 hello.conf ${D}${sysconfdir}
}
Recipes
Adding New Tasks
● Tasks can be added with addtask

do_mkimage () {
uboot-mkimage ...
}

addtask mkimage after do_compile before do_install

Recipes: Applying Patches
Patches Use Cases
●Patches can be applied to resolve build-system problematics:
–To support old versions of a software: bug and security fixes.
–To fix cross-compilation issues.
●In certain simple cases the -e option of make can be used.
●The -e option gives variables taken from the environment precedence over
variables from Makefiles.
●Helps when an upstream Makefile uses hard coded CC and/or CFLAGS.
–To apply patches before they get their way into the upstream version.
Recipes: Applying Patches
The source locations: patches
● Files ending in .patch, .diff or having the apply=yes parameter will be applied after the sources are
retrieved and extracted, during the do_patch task.
SRC_URI += "file://joystick-support.patch \
file://smp-fixes.diff \
"
●Patches are applied in the order they are listed in SRC_URI.
●It is possible to select which tool will be used to apply the patches listed in SRC_URI variable with
PATCHTOOL.
●By default, PATCHTOOL = 'quilt' in Poky.
●Possible values: git, patch and quilt.
Recipes: Applying Patches
Resolving conflicts
● The PATCHRESOLVE variable defines how to handle conflicts when
applying patches.
●It has two valid values:
–noop: the build fails if a patch cannot be successfully applied.
–user: a shell is launched to resolve manually the conflicts.
● By default, PATCHRESOLVE = "noop" in meta-poky.
Recipes:
Example
DESCRIPTION = "Hello world program"
HOMEPAGE = "http://example.net/helloworld/"
PRIORITY = "optional"
SECTION = "examples"
LICENSE = "GPLv2"

SRC_URI = "file://hello.c"
LIC_FILES_CHKSUM = \
"file://hello.c;beginline=3;endline=21;md5=58e..."

do_compile() {
${CC} ${CFLAGS} ${LDFLAGS} -o hello ${WORKDIR}/hello.c
}
do_install() {
install -d ${D}${bindir}
install -m 0755 hello ${D}${bindir}
Recipes:
Example:with a version agnostic part

tar.inc
SUMMARY = "GNU file archiving program"
HOMEPAGE = "http://www.gnu.org/software/tar/"
SECTION = "base"

SRC_URI = "${GNU_MIRROR}/tar/tar-${PV}.tar.bz2"

do_configure() { ... }
do_compile() { ... }
do_install() { ... }
Recipes:
Example:with a version agnostic part

tar_1.17.bb
require tar.inc

LICENSE = "GPLv2"
LIC_FILES_CHKSUM = \
"file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552"

SRC_URI += "file://avoid_heap_overflow.patch"
SRC_URI[md5sum] = "c6c4f1c075dbf0f75c29737faa58f290"
Recipes:
Example:with a version agnostic part

tar_1.27.bb
require tar.inc

LICENSE = "GPLv3"
LIC_FILES_CHKSUM = \
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"

SRC_URI[md5sum] = "2cee42a2ff4f1cd4f9298eeeb2264519"
Classes
Introduction
● Classes provide an abstraction to common code, which can bere-used in
multiple packages.
●Common tasks do not have to be re-developed!
●Any metadata and task which can be put in a recipe can be used in a class.
●Classes extension is .bbclass
●Classes are located in the classes folder of a layer.
●Packages can use this common code by inheriting a class: inherit
inherit <class>
Classes
Common Classes
● Common classes can be found in meta/classes/
–base.bbclass
–kernel.bbclass
–autotools.bbclass
–update-alternatives.bbclass
–useradd.bbclass
...
Classes
Base Class
●Every recipe inherits the base class automatically.
●Contains a set of basic common tasks to fetch, unpack or compile
packages.
● Inherits other common classes, providing:
–Mirrors definitions: DEBIAN_MIRROR, GNU_MIRROR,
KERNELORG_MIRROR...
–The ability to filter patches by SRC_URI
–Some tasks: clean, listtasks or fetchall.
●Defines oe_runmake, using EXTRA_OEMAKE to use custom
arguments.
Classes
Kernel Class
●Used to build Linux kernels.
●Defines tasks to configure, compile and install a kernel and its
modules.
●The kernel is divided into several packages:
–kernel, kernel-base, kernel-dev, kernel-modules...
●Automatically provides the virtual package virtual/kernel.
●Configuration variables are available:
–KERNEL_IMAGETYPE, defaults to zImage
–KERNEL_EXTRA_ARGS
–INITRAMFS_IMAGE
Classes
The autotools Class
●Defines tasks and metadata to handle packages using the autotools
buildsystem (autoconf, automake and libtool):
–do_configure: generates the configure script using autoreconf
and loads it with standard arguments or cross-compilation.
–do_compile: runs make
–do_install: runs make install
●Extra configuration parameters can be passed with EXTRA_OECONF.
●Compilation flags can be added thanks to the EXTRA_OEMAKE
variable.
Classes
The update-alternative class
●Allows to install multiple binaries having the same functionality,
avoiding conflicts by renaming the binaries.
●Four variables are used to configure the class:
–ALTERNATIVE The name of the binary.
–ALTERNATIVE_LINK_NAME The path of the resulting binary.
–ALTERNATIVE_PRIORITY The alternative priority.
●The command with the highest priority will be used
Classes
The useradd class
●This class helps to add users to the resulting image.
●Adding custom users is required by many services to avoid running them as root.
●USERADD_PACKAGES must be defined when the useradd class is
inherited. Defines the list of packages which needs the user.
●Users and groups will be created before the packages using it perform
their do_install.
●At least one of the two following variables must be set:
–USERADD_PARAM: parameters to pass to useradd.
–GROUPADD_PARAM: parameters to pass to groupadd.
Classes
The useradd class : Example
DESCRIPTION = "useradd class usage example"
PRIORITY = "optional"
SECTION = "examples"
LICENSE = "MIT"
SRC_URI = "file://file0"
LIC_FILES_CHKSUM = "file://${COREBASE}/meta/files/common-licenses/MIT;md5=0835ade698e0bc..."
inherit useradd
USERADD_PACKAGES = "${PN}"
USERADD_PARAM = "-u 1000 -d /home/user0 -s /bin/bash user0"
do_install() {
install -m 644 file0 ${D}/home/user0/
chown user0:user0 ${D}/home/user0/file0
}
Binary Packages
●It is possible to install binaries into the generated root filesystem.

●Set the LICENSE to CLOSED.

●Use the do_install task to copy the binaries into the root file system.
Bitbake File Inclusion
Locate files in the build system
●Metadata can be shared using included files.

●BitBake uses the BBPATH to find the files to be included. It also looks into the current directory.

●Three keywords can be used to include files from recipes, classes or other

configuration files:

–inherit

–include

–require
Bitbake File Inclusion
The inherit keyword
● inherit can be used in recipes or classes, to inherit the functionalities of a class.

●To inherit the functionalities of the kernel class, use: inherit kernel

●inherit looks for files ending in .bbclass, in classes directories found in

BBPATH.

● It is possible to include a class conditionally using a variable:

inherit ${FOO}
Bitbake File Inclusion
The include & require keyword
● include and require can be used in all files, to insert the content of another file at
that location.
● If the path specified on the include (or require) path is relative, BitBake will insert
the first file found in BBPATH.
● include does not produce an error when a file cannot be found, whereas require
raises a parsing error.
●To include a local file: include example.inc
●To include a file from another location (which could be in another layer):
include path/to/file.inc
Layers