Documentation
Software
Variables often used in recipes The build system provides the following variables as a convenience for referring to the package name, version, or release in your recipes.
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 strace_4.5.14.bb recipe the PV variable would be set to "4.5.14".
The package name and versions separated by a hyphen. For the strace_4.5.14.bb recipe the P variable would be set to "strace-4.5.14".
The package release. This should be explicitly set in the recipe, if not set it defaults to "r0".
The build system also initializes a set of variables used to refer to key directories utilized in the build process.
The working directory is where the source code is extracted, where files (other than patches) are copied, and where the logs and installation files are created. WORKDIR is initialized to PN-PV-PR, so for example recipe strace_4.5.14.bb, the value of WORKDIR would be set to "strace_4.5.14-r0" (assuming that the recipe set PR to "r0")
This is the unpacked source directory.
Bitbake expects to find the extracted source for a package in a directory called packagename-version in the WORKDIR directory. This is the directory which it will change to before patching, compiling and installing the package.
For example, let's assume we have a package recipe called strace_4.5.14.bb and we are extracting the source from the strace-4.5.14.tar.gz file. Bitbake expects the source to end up in a directory called strace-4.5.14 within the WORKDIR.
If the source does not end up in this directory, then bitbake needs to be told this by explicitly setting S.
This is the destination directory. It specifies where your package should be installed. The packaging system takes the contents of this directory and packages it for installation on the target.
The directory structure beneath D should reflect where the package files are to end up in the target system. For example, if a package file is intended to end up in /usr/bin on the target system, the recipe should install the files into ${D}/usr/bin.
It is considered poor practice to directly specify /usr/bin. The build system provides a set of variables that you should use instead (see table below). So for the example above, the proper installation directory specification would be ${D}${bindir}
| Variable name | Definition | Typical value |
|---|---|---|
| prefix | /usr | /usr |
| base_prefix | (empty) | (empty) |
| exec_prefix | ${base_prefix} | (empty) |
| base_bindir | ${base_prefix}/bin | /bin |
| base_sbindir | ${base_prefix}/sbin | /sbin |
| base_libdir | ${base_prefix}/lib | /lib |
| datadir | ${prefix}/share | /usr/share |
| sysconfdir | /etc | /etc |
| localstatedir | /var | /var |
| infodir | ${datadir}/info | /usr/share/info |
| mandir | ${datadir}/man | /usr/share/man |
| docdir | ${datadir}/doc | /usr/share/doc |
| servicedir | /srv | /srv |
| bindir | ${exec_prefix}/bin | /usr/bin |
| sbindir | ${exec_prefix}/sbin | /usr/sbin |
| libexecdir | ${exec_prefix}/libexec | /usr/libexec |
| libdir | ${exec_prefix}/lib | /usr/lib |
| includedir | ${exec_prefix}/include | /usr/include |
The following table lists the available variables for referring to the staging area:
| Directory | Definition |
|---|---|
| STAGING_DIR | ${TMPDIR}/staging |
| STAGING_BINDIR | ${STAGING_DIR}/${HOST_SYS}/bin |
| STAGING_BINDIR_CROSS | ${STAGING_DIR}/${BUILD_SYS}/bin/${HOST_SYS} |
| STAGING_BINDIR_NATIVE | ${STAGING_DIR}/${BUILD_SYS}/bin |
| STAGING_LIBDIR | ${STAGING_DIR}/${HOST_SYS}/lib |
| STAGING_INCDIR | ${STAGING_DIR}/${HOST_SYS}/include |
| STAGING_DATADIR | ${STAGING_DIR}/${HOST_SYS}/share |
| STAGING_LOADER_DIR | ${STAGING_DIR}/${HOST_SYS}/loader |
| STAGING_FIRMWARE_DIR | ${STAGING_DIR}/${HOST_SYS}/firmware |
| STAGING_PYDIR | ${STAGING_DIR}/lib/python2.4 |
| STAGING_KERNEL_DIR | ${STAGING_DIR}/${HOST_SYS}/kernel |
| PKG_CONFIG_PATH | ${STAGING_LIBDIR}/pkgconfig |