Table of Contents


extract from the

  • bitbake options:
    • interactive session: -i
    • launch a command: bitbake -c <cmd> <pkgname>
    • debug mode: -D
    • force operation: -f
    • have a devshell: ./bb -b packages/lzo/ -c devshell (need INHERIT += "devshell" in local.conf)
  • The most common actions (used with -c) are:


  Have a shell with the correct environment variable set in order try to build and debug a package


  Try to download all of the required source files, but don't do anything else with them.


  Unpack the source file but don't apply the patches yet. Sometimes you may want to look at the extracted, but not patched source code and that's what just unpacking will give you (some time's handy to get diffs generated against the original source).


  Apply any patches.


  Performs and configuration that is required for the software.


  Perform the actual compilation steps of the software.
 - stage
  If any files, such as header and libraries, will be required by other packages then they need to be installed into the staging area and that's what this task takes care of.


  Install the software in preparation for packaging.


  Package the software. Remember that this moves the files from the installation directory, D, into the packing install area. So to re-package you also need to re-install first.


  Delete the entire directory for this version of the software. Usually done to allow a test build with no chance of old files or changes being left behind.



if you want to choose which mirror to use:

export GNU_MIRROR = ""
export DEBIAN_MIRROR = ""


header var:

Variables used in the header include:

    Describes what the software does. Hopefully this gives enough information to a use to know if it's the right application for them.
    The default description is: "Version ${PV}-${PR} of package ${PN}".

    The URL of the home page of the application where new releases and more information can be found.
    The default homepage is "unknown".

    The section is used to categorise the application into a specific group. Often used by GUI based installers to help users when searching for software.
    See SECTION variable for a list of the available sections.
    The default section is "base".

    The default priority is "optional".

    The license for the application. If it is not one of the standard licenses then the license itself must be included (where?).
    As well as being used in the package meta-data the license is also used by the src_distribute class.
    The default license is "unknown"

usefull var:


    The package name. Determined from the recipe filename - everything up until the first underscore is considered to be the package name. For the recipe the PN variable would be set to "strace".

    The package version. Determined from the recipe filename - everything between the first underscore and the final .bb is considered to be the package version. For the recipe the PV variable would be set to "4.5.14".

    The package release. This is explicitly set in the recipe, or if not set it defaults to "r0" if not set.

    The package name and versions separated by a hyphen.

    P = "${PN}-${PV}"

    For the recipe the P variable would be set to "strace-4.5.14".

    The package name, version and release separated by hyphens.

    PF = "${PN}-${PV}-${PR}"

    For the recipe, with PR set to "r1" in the recipe, the PF variable would be set to "strace-4.5.14-r1".

While some of these variables are not commonly used in recipes (they are used internally though) both PN and PV are used a lot.

In the following example we are instructing the packaging system to include an additional directory in the package. We use PN to refer to the name of the package rather than spelling out the package name:

FILES_${PN} += "${sysconfdir}/myconf"

In the next example we are specifying the URL for the package source, by using PV in place of the actual version number it is possible to duplicate, or rename, the recipe for a new version without having to edit the URL:

SRC_URI = "${PV}.tar.bz2"

Source files:

SRC_URI = "${PV}.tar.gz \
           file://ospfd-no-opaque-lsa-fix.patch;patch=1 \
           file://fix-for-lib-inpath.patch;patch=1 \
           file://quagga.init \
           file://quagga.default \
           file://watchquagga.init \

All source code and files will be placed into the work directory, ${WORKDIR}, for the package. All patches will be placed into a patches subdirectory of the package source directory, ${S}, and then automatically applied to the source.

Before downloading from a remote URI a check will be made to see if what is to be retrieved is already present in the download source directory, ${DL_DIR}, along with an associated md5 sum. If the source is present in the downloaded sources directory and the md5 sum matches that listed in the associated md5 sum file, then that version will be used in preference to retrieving a new version . Any source that is retrieved from a remote URI will be stored in the download source directory and an appropriate md5 sum generated and stored alongside it.

Each URI supports a set of additional options. These options are tag/value pairs of the form "a=b" and are semi-colon separated from each other and from the URI. The follow examples shows two options being included, the patch and pnum options:


The supported methods for fetching source and files are:

http, https, ftps

    Used to download files and source code via the specified URL. These are fetched from the specified location using wget.

    Used for files that are included locally in the meta-data. These may be plain files, such as init scripts to be added to the final package, or they may be patch files to be applied to other source.

    Used to download from a CVS repository.

    Used to download from a subversion repository.

    Used to download from a git repository.

usefull var referring to directory:

The following are some of the directories commonly referred to in recipes and will be described in more detail in the rest of this section:

Working directory: WORKDIR

    This working directory for a recipe is where archive files will be extracted, plain files will be placed, subdirectories for logs, installed files etc will be created.
Unpacked source code directory: S

    This is where patches are applied and where the program is expected to be compiled in.
Destination directory: D

    The destination directory. This is where your package should be installed into. The packaging system will then take the files from directories under here and package them up for installation on the target.
Installation directories: bindir, docdir, ...

    There are a set of variables available to describe all of the paths on the target that you may want to use. Recipes should use these variables rather than hard coding any specific paths.
Staging directories: STAGING_LIBDIR, STAGING_INCDIR, ...

    Staging directories are a special area for headers, libraries and other files that are generated by one recipe that may be needed by another recipe. A library package for example needs to make the library and headers available to other recipes so that they can link against them.

    These directories are used to control where files are found. Understanding these can help you separate patches for different versions or releases of your recipes and/or use the same patch over multiple versions etc.


disable a package temporary:

#in the recipe add:

allow empty package:

#in the recipe add:
#allow to create empty packages

configuration files:

CONFFILES_{PN} = "/etc/fstab"


INITSCRIPT_NAME = "initscriptquitue"
INITSCRIPT_PARAMS = "defaults 58 02"

inherit update-rc.d

do_install () {
  install -d ${D}${sysconfdir}/init.d
  install -m 0755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}

= Svn autorev = set your filename to

SRC_URI = "svn://pkg/trunk;module=truc;proto=http"                                                                                               
S = "${WORKDIR}/truc"                                                                                                                                                                          
SRCREV_pn-pkg ?= "${AUTOREV}"      


* no package to satisfy dependency:

  • pkg not created because he is empty?

* no way to update dependency on a package (previous dependency still present)

  • watch pkgdata in build/tmp/staging/
openembedded.txt · Last modified: 2008/07/02 17:48 by ctaf
Recent changes RSS feed Creative Commons License Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki