This section provides information about how to extend the functionality already present in Poky. The section also documents standard tasks such as adding new software packages, extending or customizing images or porting Poky to new hardware (adding a new machine). Finally, the section contains advice about how to make changes to Poky to achieve the best results.

To add a package into Poky you need to write a recipe for it. Writing a recipe means creating a .bb file that sets some variables. For information on variables that are useful for recipes and for information about recipe naming issues, see Recipe Variables - Required appendix. Before writing a recipe from scratch it is often useful to check whether someone else has written one already. OpenEmbedded is a good place to look as it has a wider scope and range of packages. Because Poky aims to be compatible with OpenEmbedded, most recipes should just work in Poky. For new packages, the simplest way to add a recipe is to base it on a similar pre-existing recipe. Following are some examples showing how to add standard types of packages:

Building an application from a single file that is stored locally (e.g. under files/) requires a recipe that has the file listed in the SRC_URI variable. Additionally, you need to manually write the do_compile and do_install tasks. The S variable defines the directory containing the source code, which is set to WORKDIR in this case - the directory BitBake uses for the build. DESCRIPTION = "Simple helloworld application" SECTION = "examples" LICENSE = "MIT" PR = "r0" SRC_URI = "file://helloworld.c" S = "${WORKDIR}" do_compile() { ${CC} helloworld.c -o helloworld } do_install() { install -d ${D}${bindir} install -m 0755 helloworld ${D}${bindir} } By default, the "helloworld", "helloworld-dbg" and "hellworld-dev" packages are built. For information on how to customize the packaging process, see Controlling Package Content.

Applications that use autotools such as autoconf and automake require a recipe that has a source archive listed in SRC_URI and also inherits autotools, which instructs BitBake to use the autotools.bbclass containing the definitions of all the steps needed to build an autotooled application. The result of the build is automatically packaged. And, if the application uses NLS for localization, packages with local information are generated (one package per language). Following is one example (hello_2.2.bb) DESCRIPTION = "GNU Helloworld application" SECTION = "examples" LICENSE = "GPLv2+" LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe" PR = "r0" SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz" inherit autotools gettext LIC_FILES_CHKSUM is used to track source license change. You can quickly create autotool-based recipes in a manner similar to the previous example.

Applications that use GNU make also require a recipe that has the source archive listed in SRC_URI. You do not need to add a do_compile step since by default BitBake starts the make command to compile the application. If you need additional make options you should store them in the EXTRA_OEMAKE variable. Bitbake passes these options into the make GNU invocation. Note that a do_install task is still required. Otherwise BitBake runs an empty do_install task by default. Some applications might require extra parameters to be passed to the compiler. For example the application might need an additional header path. You can accomplish this by adding to the CFLAGS variable. The following example shows this: CFLAGS_prepend = "-I ${S}/include " In the following example mtd-utils is a Makefile-based package: DESCRIPTION = "Tools for managing memory technology devices." SECTION = "base" DEPENDS = "zlib lzo e2fsprogs util-linux" HOMEPAGE = "http://www.linux-mtd.infradead.org/" LICENSE = "GPLv2" SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=v${PV}" S = "${WORKDIR}/git/" EXTRA_OEMAKE = "'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include -DWITHOUT_XATTR' \ 'BUILDDIR=${S}'" do_install () { oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir} \ INCLUDEDIR=${includedir} install -d ${D}${includedir}/mtd/ for f in ${S}/include/mtd/*.h; do install -m 0644 $f ${D}${includedir}/mtd/ done }

You can use the variables PACKAGES and FILES to split an application into multiple packages. Following is an example that uses the "libXpm" recipe (libxpm_3.5.7.bb). By default, the "libXpm" recipe generates a single package containing the library, along with a few binaries. You can modify the recipe to split the binaries into separate packages: require xorg-lib-common.inc DESCRIPTION = "X11 Pixmap library" LICENSE = "X-BSD" DEPENDS += "libxext libsm libxt" PR = "r3" PE = "1" XORG_PN = "libXpm" PACKAGES =+ "sxpm cxpm" FILES_cxpm = "${bindir}/cxpm" FILES_sxpm = "${bindir}/sxpm" In the previous example we want to ship the "sxpm" and "cxpm" binaries in separate packages. Since "bindir" would be packaged into the main PN package by default, we prepend the PACKAGES variable so additional package names are added to the start of list. This results in the extra FILES_* variables then containing information defining which files and directories go into which package. Files included by earlier packages are skipped by latter packages. Thus, the main PN package does not include the above listed files.

To add a post-installation script to a package, add a pkg_postinst_PACKAGENAME() function to the .bb file and use PACKAGENAME as the name of the package you want to attach to the postinst script. Normally PN can be used, which automatically expands to PACKAGENAME. A post-installation function has the following structure: pkg_postinst_PACKAGENAME () { #!/bin/sh -e # Commands to carry out } The script defined in the post-installation function is called when the rootfs is made. If the script succeeds, the package is marked as installed. If the script fails, the package is marked as unpacked and the script is executed when the image boots again. Sometimes it is necessary for the execution of a post-installation script to be delayed until the first boot. For example, the script might need to be executed on the device itself. To delay script execution until boot time, use the following structure for the post-installation script: pkg_postinst_PACKAGENAME () { #!/bin/sh -e if [ x"$D" = "x" ]; then # Actions to carry out on the device go here else exit 1 fi } The previous example delays execution until the image boots again because the D variable points to the 'image' directory when the rootfs is being made at build time but is unset when executed on the first boot.

You can customize Poky images to satisfy particular requirements. This section describes several methods and provides guidelines for each.

One way to get additional software into an image is to create a custom image. The following example shows the form for the two lines you need: IMAGE_INSTALL = "task-poky-x11-base package1 package2" inherit poky-image By creating a custom image, a developer has total control over the contents of the image. It is important to use the correct names of packages in the IMAGE_INSTALL variable. You must use the OpenEmbedded notation and not the Debian notation for the names (e.g. "glibc-dev" instead of "libc6-dev"). The other method for creating a custom image is to modify an existing image. For example, if a developer wants to add "strace" into "poky-image-sato", they can use the following recipe: require poky-image-sato.bb IMAGE_INSTALL += "strace"

For complex custom images, the best approach is to create a custom task package that is used to build the image or images. A good example of a tasks package is meta/recipes-sato/tasks/task-poky.bb . The PACKAGES variable lists the task packages to build along with the complementary -dbg and -dev packages. For each package added, you can use RDEPENDS and RRECOMMENDS entries to provide a list of packages the parent task package should contain. Following is an example: DESCRIPTION = "My Custom Tasks" PACKAGES = "\ task-custom-apps \ task-custom-apps-dbg \ task-custom-apps-dev \ task-custom-tools \ task-custom-tools-dbg \ task-custom-tools-dev \ " RDEPENDS_task-custom-apps = "\ dropbear \ portmap \ psplash" RDEPENDS_task-custom-tools = "\ oprofile \ oprofileui-server \ lttng-control \ lttng-viewer" RRECOMMENDS_task-custom-tools = "\ kernel-module-oprofile" In the previous example, two task packages are created with their dependencies and their recommended package dependencies listed: task-custom-apps, and task-custom-tools. To build an image using these task packages, you need to add "task-custom-apps" and/or "task-custom-tools" to IMAGE_INSTALL or other forms of image dependencies as described in other areas of this section.

Ultimately users might want to add extra image "features" as used by Poky with the IMAGE_FEATURES variable. To create these features, the best reference is meta/classes/poky-image.bbclass, which shows how poky achieves this. In summary, the file looks at the contents of the IMAGE_FEATURES variable and then maps them into a set of tasks or packages. Based on this information the IMAGE_INSTALL variable is generated automatically. Users can add extra features by extending the class or creating a custom class for use with specialized image .bb files.

It is possible to customise image contents by abusing variables used by distribution maintainers in local.conf. This method only allows the addition of packages and is not recommended. For example, to add the "strace" package into the image the you would add this to the local.conf file: DISTRO_EXTRA_RDEPENDS += "strace" However, since the DISTRO_EXTRA_RDEPENDS variable is for distribution maintainers, adding packages using this method is not as simple as adding them using a custom .bb file. Using the local.conf file method could result in some packages requiring recreation. For example, if packages were previously created and the image was rebuilt then the packages would need to be recreated. Cleaning task-* packages is required because they use the DISTRO_EXTRA_RDEPENDS variable. You do not have to build them by hand because Poky images depend on the packages they contain. This means dependencies are automatically built when the image builds. For this reason we don't use the "rebuild" task. In this case the "rebuild" task does does not care about dependencies - it only rebuilds the specified package. bitbake -c clean task-boot task-base task-poky bitbake poky-image-sato

Adding a new machine to Poky is a straightforward process. This section provides information that gives you an idea of the changes you must make. The information covers adding machines similar to those Poky already supports. Although well within the capabilities of Poky, adding a totally new architecture might require changes to gcc/glibc and to the site information. Consequently, the information is beyond the scope of this manual.

To add a machine configuration you need to add a .conf file with details of the device being added to conf/machine/. The name of the file determines the name Poky uses to reference the new machine. The most important variables to set in this file are TARGET_ARCH (e.g. "arm"), PREFERRED_PROVIDER_virtual/kernel (see below) and MACHINE_FEATURES (e.g. "kernel26 apm screen wifi"). You might also need other variables like SERIAL_CONSOLE (e.g. "115200 ttyS0"), KERNEL_IMAGETYPE (e.g. "zImage") and IMAGE_FSTYPES (e.g. "tar.gz jffs2"). You can find full details on these variables in the reference section. You can leverage many existing machine .conf files from meta/conf/machine/.

Poky needs to be able to build a kernel for the machine. You need to either create a new kernel recipe for this machine, or extend an existing recipe. You can find several kernel examples in the meta/recipes-kernel/linux directory that can be used as references. If you are creating a new recipe, the "normal" recipe-writing rules apply for setting up a SRC_URI. This means specifying any necessary patches and setting S to point at the source code. You need to create a "configure" task that configures the unpacked kernel with a defconfig. You can do this by using a make defconfig command or more commonly by copying in a suitable defconfig and and then running make oldconfig. By making use of "inherit kernel" and potentially some of the linux-*.inc files, most other functionality is centralized and the the defaults of the class normally work well. If you are extending an existing kernel, it is usually a matter of adding a suitable defconfig file. The file needs to be added into a location similar to defconfig files used for other machines in a given kernel. A possible way to do this is by listing the file in the SRC_URI and adding the machine to the expression in COMPATIBLE_MACHINE: COMPATIBLE_MACHINE = '(qemux86|qemumips)'

A formfactor configuration file provides information about the target hardware on which Poky is running, and that Poky cannot obtain from other sources such as the kernel. Some examples of information contained in a formfactor configuration file include framebuffer orientation, whether or not the system has a keyboard, the positioning of the keyboard in relation to the screen, and screen resolution. Sane defaults should be used in most cases, but if customisation is necessary you need to create a machconfig file under meta/packages/formfactor/files/MACHINENAME/ where MACHINENAME is the name for which this infomation applies. For information about the settings available and the defaults, please see meta/packages/formfactor/files/config. Below is one example for qemuarm: HAVE_TOUCHSCREEN=1 HAVE_KEYBOARD=1 DISPLAY_CAN_ROTATE=0 DISPLAY_ORIENTATION=0 #DISPLAY_WIDTH_PIXELS=640 #DISPLAY_HEIGHT_PIXELS=480 #DISPLAY_BPP=16 DISPLAY_DPI=150 DISPLAY_SUBPIXEL_ORDER=vrgb

We recognise that people will want to extend/configure/optimise Poky for their specific uses, especially due to the extreme configurability and flexibility Poky offers. To ensure ease of keeping pace with future changes in Poky we recommend making changes to Poky in a controlled way. Poky supports the idea of "layers" which when used properly can massively ease future upgrades and allow segregation between the Poky core and a given developer's changes. Some other advice on managing changes to Poky is also given in the following section.

Often, people want to extend Poky either through adding packages or overriding files contained within Poky to add their own functionality. Bitbake has a powerful mechanism called layers which provides a way to handle this extension in a fully supported and non-invasive fashion. The Poky tree includes several additional layers which demonstrate this functionality, such as meta-emenlow and meta-extras. The meta-emenlow layer is an example layer enabled by default. The meta-extras repostory is not enabled by default but enabling any layer is as easy as adding the layers path to the BBLAYERS variable in your bblayers.conf. this is how meta-extras are enabled in Poky builds: LCONF_VERSION = "1" BBFILES ?= "" BBLAYERS = " \ /path/to/poky/meta \ /path/to/poky/meta-emenlow \ /path/to/poky/meta-extras \ " Bitbake parses the conf/layer.conf of each of the layers in BBLAYERS to add the recipes, classes and configuration contained within the layer to Poky. To create your own layer, independent of the main Poky repository, you need only create a directory with a conf/layer.conf file and add the directory to your bblayers.conf. The meta-emenlow/conf/layer.conf demonstrates the required syntax: # We have a conf and classes directory, add to BBPATH BBPATH := "${BBPATH}:${LAYERDIR}" # We have a recipes directory containing both .bb and .bbappend files, add to BBFILES BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ ${LAYERDIR}/recipes/*/*.bbappend" BBFILE_COLLECTIONS += "emenlow" BBFILE_PATTERN_emenlow := "^${LAYERDIR}/" BBFILE_PRIORITY_emenlow = "6" As can be seen, the layers recipes are added to BBFILES. The BBFILE_COLLECTIONS variable is then appended to with the layer name. The BBFILE_PATTERN variable is immediately expanded with a regular expression used to match files from BBFILES into a particular layer, in this case by using the base pathname. The BBFILE_PRIORITY variable then assigns different priorities to the files in different layers. This is useful in situations where the same package might appear in multiple layers and allows you to choose which layer should 'win'. Note the use of LAYERDIR with the immediate expansion operator. LAYERDIR expands to the directory of the current layer and requires use of the immediate expansion operator so that Bitbake does not lazily expand the variable when it's parsing a different directory. Additional bbclass and configuration files can be locationed by bitbake through the addition to the BBPATH environment variable. In this case, the first file with the matching name found in BBPATH is the one that is used, just like the PATH variable for binaries. It is therefore recommended that you use unique bbclass and configuration file names in your custom layer. The recommended approach for custom layers is to store them in a git repository of the format meta-prvt-XXXX and have this repository cloned alongside the other meta directories in the Poky tree. This way you can keep your Poky tree and it's configuration entirely inside POKYBASE.

Modifications to Poky are often managed under some kind of source revision control system. The policy for committing to such systems is important as some simple policy can significantly improve usability. The tips below are based on the policy followed for the Poky core. It helps to use a consistent style for commit messages when committing changes. We've found a style where the first line of a commit message summarises the change and starts with the name of any package affected work well. Not all changes are to specific packages so the prefix could also be a machine name or class name instead. If a change needs a longer description this should follow the summary: bitbake/data.py: Add emit_func() and generate_dependencies() functions These functions allow generation of dependency data between funcitons and variables allowing moves to be made towards generating checksums and allowing use of the dependency information in other parts of bitbake. Signed-off-by: Richard Purdie rpurdie@linux.intel.com Any commit should be self contained in that it should leave the metadata in a consistent state, buildable before and after the commit. This helps ensure the autobuilder test results are valid but is good practice regardless.

If a committed change will result in changing the package output then the value of the PR variable needs to be increased (commonly referred to as 'bumped') as part of that commit. Only integer values are used and PR = "r0" should be added into new recipes as, while this is the default value, not having the variable defined in a recipe makes it easy to miss incrementing it when updating the recipe. When upgrading the version of a package (PV), the PR variable should be reset to "r0". The aim is that the package version will only ever increase. If for some reason PV will change and but not increase, the PE (Package Epoch) can be increased (it defaults to '0'). The version numbers aim to follow the Debian Version Field Policy Guidelines which define how versions are compared and hence what "increasing" means. There are two reasons for doing this, the first is to ensure that when a developer updates and rebuilds, they get all the changes to the repository and don't have to remember to rebuild any sections. The second is to ensure that target users are able to upgrade their devices via their package manager such as with the opkg upgrade commands (or similar for dpkg/apt or rpm based systems). The aim is to ensure Poky has upgradable packages in all cases.

It may not be immediately clear how Poky can work in a team environment, or scale to a large team of developers. The specifics of any situation will determine the best solution and poky offers immense flexibility in that aspect but there are some practises that experience has shown to work well. The core component of any development effort with Poky is often an automated build testing framework and image generation process. This can be used to check that the metadata is buildable, highlight when commits break the builds and provide up to date images allowing people to test the end result and use them as a base platform for further development. Experience shows that buildbot is a good fit for this role and that it works well to configure it to make two types of build - incremental builds and 'from scratch'/full builds. The incremental builds can be tied to a commit hook which triggers them each time a commit is made to the metadata and are a useful acid test of whether a given commit breaks the build in some serious way. They catch lots of simple errors and whilst they won't catch 100% of failures, the tests are fast so developers can get feedback on their changes quickly. The full builds are builds that build everything from the ground up and test everything. They usually happen at preset times such as at night when the machine load isn't high from the incremental builds. poky autobuilder is an example implementation with buildbot. Most teams have pieces of software undergoing active development. It is of significant benefit to put these under control of a source control system compatible with Poky such as git or svn. The autobuilder can then be set to pull the latest revisions of these packages so the latest commits get tested by the builds allowing any issues to be highlighted quickly. Poky easily supports configurations where there is both a stable known good revision and a floating revision to test. Poky can also only take changes from specific source control branches giving another way it can be used to track/test only specified changes. Perhaps the hardest part of setting this up is the policy that surrounds the different source control systems, be them software projects or the Poky metadata itself. The circumstances will be different in each case but this is one of Poky's advantages - the system itself doesn't force any particular policy unlike a lot of build systems, allowing the best policy to be chosen for the circumstances.

Often, rather than reflashing a new image you might wish to install updated packages into an existing running system. This can be done by sharing the tmp/deploy/ipk/ directory through a web server and then on the device, changing /etc/opkg/base-feeds.conf to point at this server, for example by adding: src/gz all http://www.mysite.com/somedir/deploy/ipk/all src/gz armv7a http://www.mysite.com/somedir/deploy/ipk/armv7a src/gz beagleboard http://www.mysite.com/somedir/deploy/ipk/beagleboard

Poky is usually used to build software rather than modifying it. However, there are ways Poky can be used to modify software. During building, the sources are available in WORKDIR directory. Where exactly this is depends on the type of package and the architecture of target device. For a standard recipe not related to MACHINE it will be tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/. Target device dependent packages use MACHINE instead of PACKAGE_ARCH in the directory name. Check the package recipe sets the S variable to something other than standard WORKDIR/PN-PV/ value. After building a package, a user can modify the package source code without problem. The easiest way to test changes is by calling the "compile" task: bitbake -c compile -f NAME_OF_PACKAGE "-f" or "--force" is used to force re-execution of the specified task. Other tasks may also be called this way. But note that all the modifications in WORKDIR are gone once you executes "-c clean" for a package.

By default Poky uses quilt to manage patches in do_patch task. It is a powerful tool which can be used to track all modifications done to package sources. Before modifying source code it is important to notify quilt so it will track changes into new patch file: quilt new NAME-OF-PATCH.patch Then add all files which will be modified into that patch: quilt add file1 file2 file3 Now start editing. At the end quilt needs to be used to generate final patch which will contain all modifications: quilt refresh The resulting patch file can be found in the patches/ subdirectory of the source (S) directory. For future builds it should be copied into Poky metadata and added into SRC_URI of a recipe: SRC_URI += "file://NAME-OF-PATCH.patch" This also requires a bump of PR value in the same recipe as we changed resulting packages.

The license of one upstream project may change in the future, and Poky provides one mechanism to track such license change - LIC_FILES_CHKSUM variable.

LIC_FILES_CHKSUM = "file://COPYING; md5=xxxx \ file://licfile1.txt; beginline=5; endline=29;md5=yyyy \ file://licfile2.txt; endline=50;md5=zzzz \ ..." S is the default directory for searching files listed in LIC_FILES_CHKSUM. Relative path could be used too: LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\ md5=bb14ed3c4cda583abc85401304b5cd4e" LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6" The first line locates a file in S/src/ls.c, and the second line refers to a file in WORKDIR, which is the parent of S

This parameter lists all the important files containing the text of licenses for the source code. It is also possible to specify on which line the license text starts and on which line it ends within that file using the "beginline" and "endline" parameters. If the "beginline" parameter is not specified then license text begins from the 1st line is assumed. Similarly if "endline" parameter is not specified then the license text ends at the last line in the file is assumed. So if a file contains only licensing information, then there is no need to specify "beginline" and "endline" parameters. The "md5" parameter stores the md5 checksum of the license text. So if the license text changes in any way from a file, then its md5 sum will differ and will not match with the previously stored md5 checksum. This mismatch will trigger build failure, notifying developer about the license text md5 mismatch, and allowing the developer to review the license text changes. Also note that if md5 checksum is not matched while building, the correct md5 checksum is printed in the build log which can be easily copied to .bb file. There is no limit on how many files can be specified on this parameter. But generally every project would need specifying of just one or two files for license tracking. Many projects would have a "COPYING" file which will store all the license information for all the source code files. If the "COPYING" file is valid then tracking only that file would be enough. 1. If you specify empty or invalid "md5" parameter; then while building the package, bitbake will give md5 not matched error, and also show the correct "md5" parameter value both on the screen and in the build log 2. If the whole file contains only license text, then there is no need to specify "beginline" and "endline" parameters.

Poky implements a distro_check task which automatically connects to major distributions and checks whether they contains same package. Sometimes the same package has different names in different distributions, which results in a mismatch from distro_check task This can be solved by defining per distro recipe name alias - DISTRO_PN_ALIAS

DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \ distro2=package_name_alias2 \ distro3=package_name_alias3 \ ..." Use space as the delimiter if there're multiple distro aliases The current code can check if the src package for a recipe exists in the latest releases of these distributions automatically. Fedora, OpenSuSE, Debian, Ubuntu, Mandriva For example, this command will generate a report, listing which linux distros include the sources for each of the poky recipe. bitbake world -f -c distro_check The results will be stored in the build/tmp/log/distro_check-${DATETIME}.results file.