sysmo-bts
/
generic-poky
9
0
Fork 0
Code Pull Requests Releases Activity

handbook: review and correct CH3(extend poky) in handbook 

Fix inaccurate descriptions.
Update recipe examples to make sure they do build
Add some examples for better guidance

Signed-off-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Ke Yu <ke.yu@intel.com>
This commit is contained in:
Kevin Tian 2010-09-09 17:00:31 +08:00 committed by Richard Purdie
parent 7ef8658402
commit 3c6e1d7c62
1 changed files with 172 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

253
handbook/extendpoky.xml
View File

@ -27,7 +27,7 @@
<para> <para>
Before writing a recipe from scratch it is often useful to check Before writing a recipe from scratch it is often useful to check
someone else hasn't written one already. OpenEmbedded is a good place whether someone else has written one already. OpenEmbedded is a good place
to look as it has a wider scope and hence a wider range of packages. to look as it has a wider scope and hence a wider range of packages.
Poky aims to be compatible with OpenEmbedded so most recipes should Poky aims to be compatible with OpenEmbedded so most recipes should
just work in Poky. just work in Poky.
@ -43,8 +43,8 @@
<title>Single .c File Package (Hello World!)</title> <title>Single .c File Package (Hello World!)</title>
<para> <para>
To build an application from a single file stored locally requires a To build an application from a single file stored locally (e.g. under "files/")
recipe which has the file listed in the <glossterm><link requires a recipe which has the file listed in the <glossterm><link
linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable. In addition linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable. In addition
the <function>do_compile</function> and <function>do_install</function> the <function>do_compile</function> and <function>do_install</function>
tasks need to be manually written. The <glossterm><link linkend='var-S'> tasks need to be manually written. The <glossterm><link linkend='var-S'>
@ -56,7 +56,7 @@
DESCRIPTION = "Simple helloworld application" DESCRIPTION = "Simple helloworld application"
SECTION = "examples" SECTION = "examples"
LICENSE = "MIT" LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=ae764cfda68da96df20af9fbf9fe49bd" PR = "r0"
SRC_URI = "file://helloworld.c" SRC_URI = "file://helloworld.c"
@ -73,8 +73,9 @@ do_install() {
</programlisting> </programlisting>
<para> <para>
As a result of the build process "helloworld" and "helloworld-dbg" As a result of the build process "helloworld", "helloworld-dbg" and "hellworld-dev"
packages will be built. packages will be built by default. You can <link linkend='usingpoky-extend-addpkg-files'>
control package process</link> yourself.
</para> </para>
</section> </section>
@ -93,20 +94,28 @@ do_install() {
The result of the build will be automatically packaged and if The result of the build will be automatically packaged and if
the application uses NLS to localise then packages with the application uses NLS to localise then packages with
locale information will be generated (one package per locale information will be generated (one package per
language). language). Below is one example (hello_2.2.bb)
</para> </para>
<programlisting> <programlisting>
DESCRIPTION = "GNU Helloworld application" DESCRIPTION = "GNU Helloworld application"
SECTION = "examples" SECTION = "examples"
LICENSE = "GPLv2" LICENSE = "GPLv2+"
LIC_FILES_CHKSUM = "file://COPYING;md5=ae764cfda68da96df20af9fbf9fe49bd" LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
PR = "r0"
SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2" SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
inherit autotools inherit autotools gettext
</programlisting> </programlisting>
<para>
<glossterm><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link>
</glossterm> is used to <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
track source license change</link>. Autotool based recipe can be quickly
created this way like above example.
</para>
</section> </section>
<section id='usingpoky-extend-addpkg-makefile'> <section id='usingpoky-extend-addpkg-makefile'>
@ -132,23 +141,38 @@ inherit autotools
Some applications may require extra parameters to be passed to Some applications may require extra parameters to be passed to
the compiler, for example an additional header path. This can the compiler, for example an additional header path. This can
be done buy adding to the <glossterm><link be done buy adding to the <glossterm><link
linkend='var-CFLAGS'>CFLAGS</link></glossterm> variable, as in the example below. linkend='var-CFLAGS'>CFLAGS</link></glossterm> variable, as in the example below:
</para>
<programlisting>
CFLAGS_prepend = "-I ${S}/include "
</programlisting>
<para>
mtd-utils is an example as Makefile-based:
</para> </para>
<programlisting> <programlisting>
DESCRIPTION = "Tools for managing memory technology devices." DESCRIPTION = "Tools for managing memory technology devices."
SECTION = "base" SECTION = "base"
DEPENDS = "zlib" DEPENDS = "zlib lzo e2fsprogs util-linux"
HOMEPAGE = "http://www.linux-mtd.infradead.org/" HOMEPAGE = "http://www.linux-mtd.infradead.org/"
LICENSE = "GPLv2" LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=ae764cfda68da96df20af9fbf9fe49bd"
SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz" SRC_URI = "git://git.infradead.org/mtd-utils.git;protocol=git;tag=v${PV}"
CFLAGS_prepend = "-I ${S}/include " S = "${WORKDIR}/git/"
do_install() { EXTRA_OEMAKE = "'CC=${CC}' 'CFLAGS=${CFLAGS} -I${S}/include -DWITHOUT_XATTR' \
oe_runmake install DESTDIR=${D} '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
} }
</programlisting> </programlisting>
@ -165,7 +189,7 @@ do_install() {
</para> </para>
<para> <para>
Below the "libXpm" recipe is used as an example. By Below the "libXpm" recipe (libxpm_3.5.7.bb) is used as an example. By
default the "libXpm" recipe generates one package default the "libXpm" recipe generates one package
which contains the library which contains the library
and also a few binaries. The recipe can be adapted to and also a few binaries. The recipe can be adapted to
@ -177,8 +201,9 @@ require xorg-lib-common.inc
DESCRIPTION = "X11 Pixmap library" DESCRIPTION = "X11 Pixmap library"
LICENSE = "X-BSD" LICENSE = "X-BSD"
LIC_FILES_CHKSUM = "file://COPYING;md5=ae764cfda68da96df20af9fbf9fe49bd" DEPENDS += "libxext libsm libxt"
DEPENDS += "libxext" PR = "r3"
PE = "1"
XORG_PN = "libXpm" XORG_PN = "libXpm"
@ -194,9 +219,12 @@ FILES_sxpm = "${bindir}/sxpm"
package as standard we prepend the <glossterm><link package as standard we prepend the <glossterm><link
linkend='var-PACKAGES'>PACKAGES</link></glossterm> variable so linkend='var-PACKAGES'>PACKAGES</link></glossterm> variable so
additional package names are added to the start of list. The additional package names are added to the start of list. The
extra <glossterm><link linkend='var-PN'>FILES</link></glossterm>_* extra <glossterm><link linkend='var-FILES'>FILES</link></glossterm>_*
variables then contain information to specify which files and variables then contain information to specify which files and
directories goes into which package. directories goes into which package. Files included by earlier
package are skipped by latter packages, and thus main <glossterm>
<link linkend='var-PN'>PN</link></glossterm> will not include
above listed files
</para> </para>
</section> </section>
@ -208,12 +236,15 @@ FILES_sxpm = "${bindir}/sxpm"
a <function>pkg_postinst_PACKAGENAME()</function> a <function>pkg_postinst_PACKAGENAME()</function>
function to the .bb file function to the .bb file
where PACKAGENAME is the name of the package to attach where PACKAGENAME is the name of the package to attach
the postinst script to. A post-installation function has the following structure: the postinst script to. Normally <glossterm><link
linkend='var-PN'>PN</link></glossterm> can be used which expands
to PACKAGENAME automatically. A post-installation function has the
following structure:
</para> </para>
<programlisting> <programlisting>
pkg_postinst_PACKAGENAME () { pkg_postinst_PACKAGENAME () {
#!/bin/sh -e #!/bin/sh -e
# Commands to carry out # Commands to carry out
} }
</programlisting> </programlisting>
<para> <para>
@ -234,12 +265,12 @@ pkg_postinst_PACKAGENAME () {
<programlisting> <programlisting>
pkg_postinst_PACKAGENAME () { pkg_postinst_PACKAGENAME () {
#!/bin/sh -e #!/bin/sh -e
if [ x"$D" = "x" ]; then if [ x"$D" = "x" ]; then
# Actions to carry out on the device go here # Actions to carry out on the device go here
else else
exit 1 exit 1
fi fi
} }
</programlisting> </programlisting>
@ -349,7 +380,7 @@ RRECOMMENDS_task-custom-tools = "\
</para> </para>
<para> <para>
In this example, two tasks packages are created, task-custom-apps and In this example, two task packages are created, task-custom-apps and
task-custom-tools with the dependencies and recommended package dependencies task-custom-tools with the dependencies and recommended package dependencies
listed. To build an image using these task packages, you would then add listed. To build an image using these task packages, you would then add
"task-custom-apps" and/or "task-custom-tools" to <glossterm><link "task-custom-apps" and/or "task-custom-tools" to <glossterm><link
@ -367,8 +398,9 @@ RRECOMMENDS_task-custom-tools = "\
variable. To create these, the best reference is <filename>meta/classes/poky-image.bbclass</filename> variable. To create these, the best reference is <filename>meta/classes/poky-image.bbclass</filename>
which illustrates how poky achieves this. In summary, the file looks at the contents of the which illustrates how poky achieves this. In summary, the file looks at the contents of the
<glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>
variable and based on this generates the <glossterm><link linkend='var-IMAGE_INSTALL'> variable and then map into a set of tasks or packages. Based on this then the
IMAGE_INSTALL</link></glossterm> variable automatically. Extra features can be added by <glossterm><link linkend='var-IMAGE_INSTALL'> IMAGE_INSTALL</link></glossterm>
variable is generated automatically. Extra features can be added by
extending the class or creating a custom class for use with specialised image .bb files. extending the class or creating a custom class for use with specialised image .bb files.
</para> </para>
</section> </section>
@ -397,11 +429,11 @@ DISTRO_EXTRA_RDEPENDS += "strace"
DISTRO_EXTRA_RDEPENDS</link></glossterm> variable is for DISTRO_EXTRA_RDEPENDS</link></glossterm> variable is for
distribution maintainers this method does not make distribution maintainers this method does not make
adding packages as simple as a custom .bb file. Using adding packages as simple as a custom .bb file. Using
this method, a few packages will need to be recreated this method, a few packages will need to be recreated if they have been
and the the image built. created before and then the image is rebuilt.
</para> </para>
<programlisting> <programlisting>
bitbake -cclean task-boot task-base task-poky bitbake -c clean task-boot task-base task-poky
bitbake poky-image-sato bitbake poky-image-sato
</programlisting> </programlisting>
@ -410,7 +442,7 @@ bitbake poky-image-sato
<glossterm><link linkend='var-DISTRO_EXTRA_RDEPENDS'> <glossterm><link linkend='var-DISTRO_EXTRA_RDEPENDS'>
DISTRO_EXTRA_RDEPENDS</link></glossterm> variable. There is no need to DISTRO_EXTRA_RDEPENDS</link></glossterm> variable. There is no need to
build them by hand as Poky images depend on the packages they contain so build them by hand as Poky images depend on the packages they contain so
dependencies will be built automatically. For this reason we don't use the dependencies will be built automatically when building the image. For this reason we don't use the
"rebuild" task in this case since "rebuild" does not care about "rebuild" task in this case since "rebuild" does not care about
dependencies - it only rebuilds the specified package. dependencies - it only rebuilds the specified package.
</para> </para>
@ -451,7 +483,8 @@ bitbake poky-image-sato
</glossterm> (e.g. "zImage") and <glossterm><link linkend='var-IMAGE_FSTYPES'> </glossterm> (e.g. "zImage") and <glossterm><link linkend='var-IMAGE_FSTYPES'>
IMAGE_FSTYPES</link></glossterm> (e.g. "tar.gz jffs2") might also be IMAGE_FSTYPES</link></glossterm> (e.g. "tar.gz jffs2") might also be
needed. Full details on what these variables do and the meaning of needed. Full details on what these variables do and the meaning of
their contents is available through the links. their contents is available through the links. There're lots of existing
machine .conf files which can be easily leveraged from meta/conf/machine/.
</para> </para>
</section> </section>
@ -461,10 +494,10 @@ bitbake poky-image-sato
Poky needs to be able to build a kernel for the machine. You need 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 to either create a new kernel recipe for this machine or extend an
existing recipe. There are plenty of kernel examples in the existing recipe. There are plenty of kernel examples in the
packages/linux directory which can be used as references. meta/recipes-kernel/linux directory which can be used as references.
</para> </para>
<para> <para>
If creating a new recipe the "normal" recipe writing rules apply If creating a new recipe the "normal" recipe writing rules apply
for setting up a <glossterm><link linkend='var-SRC_URI'>SRC_URI for setting up a <glossterm><link linkend='var-SRC_URI'>SRC_URI
</link></glossterm> including any patches and setting <glossterm> </link></glossterm> including any patches and setting <glossterm>
<link linkend='var-S'>S</link></glossterm> to point at the source <link linkend='var-S'>S</link></glossterm> to point at the source
@ -481,8 +514,11 @@ bitbake poky-image-sato
machine's defconfig files in a given kernel, possibly listing it in machine's defconfig files in a given kernel, possibly listing it in
the SRC_URI and adding the machine to the expression in <glossterm> the SRC_URI and adding the machine to the expression in <glossterm>
<link linkend='var-COMPATIBLE_MACHINE'>COMPATIBLE_MACHINE</link> <link linkend='var-COMPATIBLE_MACHINE'>COMPATIBLE_MACHINE</link>
</glossterm>. </glossterm>:
</para> </para>
<programlisting>
COMPATIBLE_MACHINE = '(qemux86|qemumips)'
</programlisting>
</section> </section>
<section id="platdev-newmachine-formfactor"> <section id="platdev-newmachine-formfactor">
@ -502,8 +538,21 @@ bitbake poky-image-sato
under <filename>meta/packages/formfactor/files/MACHINENAME/</filename> under <filename>meta/packages/formfactor/files/MACHINENAME/</filename>
where <literal>MACHINENAME</literal> is the name for which this infomation where <literal>MACHINENAME</literal> is the name for which this infomation
applies. For information about the settings available and the defaults, please see applies. For information about the settings available and the defaults, please see
<filename>meta/packages/formfactor/files/config</filename>. <filename>meta/packages/formfactor/files/config</filename>. Below is one
example for qemuarm:
</para> </para>
<programlisting>
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
</programlisting>
</section> </section>
</section> </section>
@ -536,11 +585,13 @@ bitbake poky-image-sato
</para> </para>
<para> <para>
The Poky tree includes two additional layers which demonstrate The Poky tree includes several additional layers which demonstrate
this functionality, meta-moblin and meta-extras. this functionality, such as meta-moblin, meta-emenlow, meta-extras.
The meta-extras repostory is not enabled by default but enabling Default layers enabled are meta-moblin and meta-emenlow, which may
it is as easy as adding the layers path to the BBLAYERS variable in suffer from future changes. The meta-extras repostory is not enabled
your bblayers.conf, this is how all layers are enabled in Poky builds: 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:
</para> </para>
<para> <para>
<literallayout class='monospaced'>LCONF_VERSION = "1" <literallayout class='monospaced'>LCONF_VERSION = "1"
@ -549,6 +600,7 @@ BBFILES ?= ""
BBLAYERS = " \ BBLAYERS = " \
/path/to/poky/meta \ /path/to/poky/meta \
/path/to/poky/meta-moblin \ /path/to/poky/meta-moblin \
/path/to/poky/meta-emenlow \
/path/to/poky/meta-extras \ /path/to/poky/meta-extras \
" "
</literallayout> </literallayout>
@ -563,23 +615,23 @@ BBLAYERS = " \
</para> </para>
<para> <para>
The meta-extras layer.conf demonstrates the required syntax: The meta-emenlow/conf/layer.conf demonstrates the required syntax:
<literallayout class='monospaced'># We have a conf and classes directory, add to BBPATH <literallayout class='monospaced'># We have a conf and classes directory, add to BBPATH
BBPATH := "${BBPATH}${LAYERDIR}" BBPATH := "${BBPATH}:${LAYERDIR}"
# We have a packages directory, add to BBFILES # We have a packages directory, add to BBFILES
BBFILES := "${BBFILES} ${LAYERDIR}/packages/*/*.bb" BBFILES := "${BBFILES} ${LAYERDIR}/packages/*/*.bb \
${LAYERDIR}/packages/*/*.bbappend"
BBFILE_COLLECTIONS += "extras" BBFILE_COLLECTIONS += "emenlow"
BBFILE_PATTERN_extras := "^${LAYERDIR}/" BBFILE_PATTERN_emenlow := "^${LAYERDIR}/"
BBFILE_PRIORITY_extras = "5" BBFILE_PRIORITY_emenlow = "6"
require conf/distro/include/poky-extras-src-revisions.inc
</literallayout> </literallayout>
</para> </para>
<para> <para>
As can be seen, the layers recipes are added to BBFILES. The As can be seen, the layers recipes are added to
<glossterm> <link linkend='var-BBFILES'>BBFILES</link></glossterm>. The
BBFILE_COLLECTIONS variable is then appended to with the BBFILE_COLLECTIONS variable is then appended to with the
layer name. The BBFILE_PATTERN variable is immediately expanded layer name. The BBFILE_PATTERN variable is immediately expanded
with a regular expression used to match files from BBFILES into with a regular expression used to match files from BBFILES into
@ -588,15 +640,17 @@ require conf/distro/include/poky-extras-src-revisions.inc
priorities to the files in different layers. This is useful priorities to the files in different layers. This is useful
in situations where the same package might appear in multiple in situations where the same package might appear in multiple
layers and allows you to choose which layer should 'win'. layers and allows you to choose which layer should 'win'.
Note the use of LAYERDIR with the immediate expansion operator. Note the use of <glossterm><link linkend='var-LAYERDIR'>
LAYERDIR expands to the directory of the current layer and LAYERDIR</link></glossterm> with the immediate expansion operator.
<glossterm><link linkend='var-LAYERDIR'>LAYERDIR</link></glossterm>
expands to the directory of the current layer and
requires use of the immediate expansion operator so that Bitbake requires use of the immediate expansion operator so that Bitbake
does not lazily expand the variable when it's parsing a does not lazily expand the variable when it's parsing a
different directory. different directory.
</para> </para>
<para> <para>
Extra bbclasses and configuration are added to the BBPATH Emenlow bbclasses and configuration are added to the BBPATH
environment variable. In this case, the first file with the environment variable. In this case, the first file with the
matching name found in BBPATH is the one that is used, just matching name found in BBPATH is the one that is used, just
like the PATH variable for binaries. It is therefore recommended like the PATH variable for binaries. It is therefore recommended
@ -630,9 +684,19 @@ require conf/distro/include/poky-extras-src-revisions.inc
summarises the change and starts with the name of any package affected 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 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 also be a machine name or class name instead. If a change needs a longer
description this should follow the summary. description this should follow the summary:
</para> </para>
<literallayout class='monospaced'>
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
</literallayout>
<para> <para>
Any commit should be self contained in that it should leave the Any commit should be self contained in that it should leave the
metadata in a consistent state, buildable before and after the metadata in a consistent state, buildable before and after the
@ -655,7 +719,7 @@ require conf/distro/include/poky-extras-src-revisions.inc
it easy to miss incrementing it when updating the recipe. it easy to miss incrementing it when updating the recipe.
When upgrading the version of a package (<glossterm><link When upgrading the version of a package (<glossterm><link
linkend='var-PV'>PV</link></glossterm>), the <glossterm><link linkend='var-PV'>PV</link></glossterm>), the <glossterm><link
linkend='var-PR'>PR</link></glossterm> variable should be removed. linkend='var-PR'>PR</link></glossterm> variable should be reset to "r0".
</para> </para>
<para> <para>
@ -675,7 +739,7 @@ require conf/distro/include/poky-extras-src-revisions.inc
the repository and don't have to remember to rebuild any sections. 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 The second is to ensure that target users are able to upgrade their
devices via their package manager such as with the <command> devices via their package manager such as with the <command>
opkg update;opkg upgrade</command> commands (or similar for opkg upgrade</command> commands (or similar for
dpkg/apt or rpm based systems). The aim is to ensure Poky has dpkg/apt or rpm based systems). The aim is to ensure Poky has
upgradable packages in all cases. upgradable packages in all cases.
</para> </para>
@ -708,6 +772,8 @@ require conf/distro/include/poky-extras-src-revisions.inc
are builds that build everything from the ground up and test everything. 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 They usually happen at preset times such as at night when the machine
load isn't high from the incremental builds. load isn't high from the incremental builds.
<ulink url='http://autobuilder.pokylinux.org:8010'>poky autobuilder</ulink>
is an example implementation with buildrot.
</para> </para>
<para> <para>
@ -783,11 +849,14 @@ src/gz beagleboard http://www.mysite.com/somedir/deploy/ipk/beagleboard</literal
</para> </para>
<programlisting> <programlisting>
bitbake --cmd compile --force NAME_OF_PACKAGE bitbake -c compile -f NAME_OF_PACKAGE
</programlisting> </programlisting>
<para> <para>
Other tasks may also be called this way. "-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 <glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>
are gone once you executes "-c clean" for a pacakge.
</para> </para>
<section id='usingpoky-modifying-packages-quilt'> <section id='usingpoky-modifying-packages-quilt'>
@ -840,10 +909,11 @@ SRC_URI += "file://NAME-OF-PATCH.patch"
</section> </section>
<section id='usingpoky-configuring-LIC_FILES_CHKSUM'> <section id='usingpoky-configuring-LIC_FILES_CHKSUM'>
<title>Configuring the LIC_FILES_CHKSUM variable</title> <title>Track license change</title>
<para> <para>
The changes in the license text inside source code files is tracked The license of one upstream project may change in the future, and Poky provides
using the LIC_FILES_CHKSUM metadata variable. one mechanism to track such license change - <glossterm>
<link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></glossterm> variable.
</para> </para>
<section id='usingpoky-specifying-LIC_FILES_CHKSUM'> <section id='usingpoky-specifying-LIC_FILES_CHKSUM'>
@ -855,6 +925,26 @@ LIC_FILES_CHKSUM = "file://COPYING; md5=xxxx \
file://licfile2.txt; endline=50;md5=zzzz \ file://licfile2.txt; endline=50;md5=zzzz \
..." ..."
</programlisting> </programlisting>
<para>
<glossterm><link linkend='var-S'>S</link></glossterm> is the default directory
for searching files listed in <glossterm><link linkend='var-LIC_FILES_CHKSUM'>
LIC_FILES_CHKSUM</link></glossterm>. Relative path could be used too:
</para>
<programlisting>
LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
md5=bb14ed3c4cda583abc85401304b5cd4e"
LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
</programlisting>
<para>
The first line locates a file in <glossterm><link linkend='var-S'>
S</link></glossterm>/src/ls.c, and the second line refers to a file in
<glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>, which is the parent
of <glossterm><link linkend='var-S'>S</link></glossterm>
</para>
</section> </section>
<section id='usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax'> <section id='usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax'>
@ -873,12 +963,12 @@ to specify "beginline" and "endline" parameters.
</para> </para>
<para> <para>
The "md5" parameter stores the md5 checksum of the license text. So if The "md5" parameter stores the md5 checksum of the license text. So if
the license text changes in any way from a file, then it's md5 sum will differ and will not 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 match with the previously stored md5 checksum. This mismatch will trigger build
failure, notifying developer about the license text md5 mismatch, and allowing 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 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 is not matched while building, the correct md5 checksum is printed in the build
log. log which can be easily copied to .bb file.
</para> </para>
<para> <para>
There is no limit on how many files can be specified on this parameter. But generally every There is no limit on how many files can be specified on this parameter. But generally every
@ -891,7 +981,7 @@ is valid then tracking only that file would be enough.
<para> <para>
1. If you specify empty or invalid "md5" parameter; then while building 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 the package, bitbake will give md5 not matched error, and also show the correct
"md5" parameter value in the build log "md5" parameter value both on the screen and in the build log
</para> </para>
<para> <para>
2. If the whole file contains only license text, then there is no need to 2. If the whole file contains only license text, then there is no need to
@ -901,22 +991,23 @@ specify "beginline" and "endline" parameters.
</section> </section>
</section> </section>
<section id='usingpoky-configuring-DISTRO_PN_ALIAS'> <section id='usingpoky-configuring-DISTRO_PN_ALIAS'>
<title>Configuring the DISTRO_PN_ALIAS variable</title> <title>Handle package name alias</title>
<para> <para>
Sometimes the names of the same packages are different in different Poky implements a distro_check task which automatically connects to major distributions
linux distributions; and that can becomes an issue for the distro_check and checks whether they contains same package. Sometimes the same package has different
task to check if the given recipe package exists in other linux distros. names in different distributions, which results in a mismatch from distro_check task
This issue is avoided by defining per distro recipe name alias: This can be solved by defining per distro recipe name alias -
DISTRO_PN_ALIAS <glossterm><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></glossterm>
</para> </para>
<section id='usingpoky-specifying-DISTRO_PN_ALIAS'> <section id='usingpoky-specifying-DISTRO_PN_ALIAS'>
<title>Specifying the DISTRO_PN_ALIAS variable </title> <title>Specifying the DISTRO_PN_ALIAS variable </title>
<programlisting> <programlisting>
DISTRO_PN_ALIAS_pn = "distro1=package_name_alias1 distro2=package_name_alias2 \ DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
distro3=package_name_alias3 \ distro2=package_name_alias2 \
..." distro3=package_name_alias3 \
..."
</programlisting> </programlisting>
<para> <para>
Use space as the delimiter if there're multiple distro aliases Use space as the delimiter if there're multiple distro aliases