From 22083287912ebd552e33b79f7c567bc966376d43 Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Fri, 15 Oct 2010 11:55:59 +0100 Subject: handbook: Move into documentation directory Signed-off-by: Richard Purdie --- handbook/extendpoky.xml | 1040 ----------------------------------------------- 1 file changed, 1040 deletions(-) delete mode 100644 handbook/extendpoky.xml (limited to 'handbook/extendpoky.xml') diff --git a/handbook/extendpoky.xml b/handbook/extendpoky.xml deleted file mode 100644 index 662096844..000000000 --- a/handbook/extendpoky.xml +++ /dev/null @@ -1,1040 +0,0 @@ - - - - -Extending Poky - - - This section gives information about how to extend the functionality - already present in Poky, documenting standard tasks such as adding new - software packages, extending or customising images or porting poky to - new hardware (adding a new machine). It also contains advice about how - to manage the process of making changes to Poky to achieve best results. - - -
- Adding a Package - - - To add package into Poky you need to write a recipe for it. - Writing a recipe means creating a .bb file which sets various - variables. The variables - useful for recipes are detailed in the - recipe reference section along with more detailed information - about issues such as recipe naming. - - - - 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 hence a wider range of packages. - Poky aims to be compatible with OpenEmbedded so 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. There are some examples below of how to add - standard types of packages: - - -
- Single .c File Package (Hello World!) - - - To build an application from a single file stored locally (e.g. under "files/") - requires a recipe which has the file listed in the SRC_URI variable. In addition - the do_compile and do_install - tasks need to be manually written. The - S variable defines the directory containing the source - code which in this case is set equal to - WORKDIR, 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} -} - - - - As a result of the build process "helloworld", "helloworld-dbg" and "hellworld-dev" - packages will be built by default. It is possible to - customise the packaging process. - -
- -
- Autotooled Package - - - Applications which use autotools (autoconf, automake) - require a recipe which has a source archive listed in - SRC_URI and - inherit autotools to instruct BitBake to use the - autotools.bbclass which has - definitions of all the steps - needed to build an autotooled application. - The result of the build will be automatically packaged and if - the application uses NLS to localise then packages with - locale information will be generated (one package per - language). Below 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. Autotool based recipe can be quickly - created this way like above example. - - -
- -
- Makefile-Based Package - - - Applications which use GNU make require a recipe which has - the source archive listed in SRC_URI. - Adding a do_compile step - is not needed as by default BitBake will start the "make" - command to compile the application. If there is a need for - additional options to make then they should be stored in the - EXTRA_OEMAKE variable - BitBake - will pass them into the GNU - make invocation. A do_install task is required - - otherwise BitBake will run an empty do_install - task by default. - - - - Some applications may require extra parameters to be passed to - the compiler, for example an additional header path. This can - be done buy adding to the CFLAGS variable, as in the example below: - - - -CFLAGS_prepend = "-I ${S}/include " - - - - mtd-utils is an example as Makefile-based: - - - -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 -} - - -
- -
- Controlling packages content - - - The variables PACKAGES and - FILES are used to split an - application into multiple packages. - - - - Below the "libXpm" recipe (libxpm_3.5.7.bb) is used as an example. By - default the "libXpm" recipe generates one package - which contains the library - and also a few binaries. The recipe can be adapted 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 this example we want to ship the "sxpm" and "cxpm" binaries - in separate packages. Since "bindir" would be packaged into the - main PN - package as standard we prepend the PACKAGES variable so - additional package names are added to the start of list. The - extra FILES_* - variables then contain information to specify which files and - directories goes into which package. Files included by earlier - package are skipped by latter packages, and thus main - PN will not include - above listed files - -
- -
- Post Install Scripts - - - To add a post-installation script to a package, add - a pkg_postinst_PACKAGENAME() - function to the .bb file - where PACKAGENAME is the name of the package to attach - the postinst script to. Normally PN can be used which expands - to PACKAGENAME automatically. 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 - gets 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 will be - executed again on the first boot of the image. - - - - Sometimes it is necessary that the execution of a post-installation - script is delayed until the first boot, because the script - needs to be executed on the device itself. To delay script execution - until boot time, the post-installation function should have the - following structure: - - - -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 structure above delays execution until first boot - 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. - -
- -
- -
- Customising Images - - - Poky images can be customised to satisfy - particular requirements. Several methods are detailed below - along with guidelines of when to use them. - - -
- Customising Images through a custom image .bb files - - - One way to get additional software into an image is by creating a - custom image. The recipe will contain two lines: - - - -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. - The names must be in - the OpenEmbedded notation instead of Debian notation, for example - "glibc-dev" instead of "libc6-dev" etc. - - - - The other method of creating a new image is by modifying - an existing image. For example if a developer wants to add - "strace" into "poky-image-sato" the following recipe can - be used: - - - -require poky-image-sato.bb - -IMAGE_INSTALL += "strace" - - -
- -
- Customising Images through custom tasks - - - For complex custom images, the best approach is to create a custom - task package which is then used to build the image (or images). A good - example of a tasks package is meta/packages/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, - RDEPENDS and - RRECOMMENDS - entries can then be added each containing a list of packages the parent - task package should contain. An example would be: - - - - -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 this example, two task packages are created, task-custom-apps and - task-custom-tools with the dependencies and recommended package dependencies - listed. To build an image using these task packages, you would then 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. - -
- -
- Customising Images through custom <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> - - - Ultimately users may want to add extra image "features" as used by Poky with the - IMAGE_FEATURES - variable. To create these, the best reference is meta/classes/poky-image.bbclass - which illustrates how poky achieves this. In summary, the file looks at the contents of the - IMAGE_FEATURES - variable and then maps this into a set of tasks or packages. Based on this then the - IMAGE_INSTALL - 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. - -
- -
- Customising Images through local.conf - - - 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. - - - - To add an "strace" package into the image the following is - added to local.conf: - - - -DISTRO_EXTRA_RDEPENDS += "strace" - - - - However, since the - DISTRO_EXTRA_RDEPENDS variable is for - distribution maintainers this method does not make - adding packages as simple as a custom .bb file. Using - this method, a few packages will need to be recreated if they have been - created before and then the image is rebuilt. - - -bitbake -c clean task-boot task-base task-poky -bitbake poky-image-sato - - - - Cleaning task-* packages is required because they use the - - DISTRO_EXTRA_RDEPENDS variable. There is no need to - build them by hand as Poky images depend on the packages they contain so - 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 - dependencies - it only rebuilds the specified package. - - -
- -
- -
- Porting Poky to a new machine - - Adding a new machine to Poky is a straightforward process and - this section gives an idea of the changes that are needed. This guide is - meant to cover adding machines similar to those Poky already supports. - Adding a totally new architecture might require gcc/glibc changes as - well as updates to the site information and, whilst well within Poky's - capabilities, is outside the scope of this section. - - -
- Adding the machine configuration file - - A .conf file needs to be added to conf/machine/ with details of the - device being added. The name of the file determines the name Poky will - use to reference this 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"). Other variables - like SERIAL_CONSOLE - (e.g. "115200 ttyS0"), - KERNEL_IMAGETYPE - (e.g. "zImage") and - IMAGE_FSTYPES (e.g. "tar.gz jffs2") might also be - needed. Full details on what these variables do and the meaning of - their contents is available through the links. There're lots of existing - machine .conf files which can be easily leveraged from meta/conf/machine/. - -
- -
- Adding a kernel for the 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. There are plenty of kernel examples in the - meta/recipes-kernel/linux directory which can be used as references. - - - If creating a new recipe the "normal" recipe writing rules apply - for setting up a SRC_URI - including any patches and setting - S to point at the source - code. You will need to create a configure task which configures the - unpacked kernel with a defconfig be that through a "make defconfig" - command or more usually though copying in a suitable defconfig and - running "make oldconfig". By making use of "inherit kernel" and also - maybe some of the linux-*.inc files, most other functionality is - centralised and the the defaults of the class normally work well. - - - If extending an existing kernel it is usually a case of adding a - suitable defconfig file in a location similar to that used by other - machine's defconfig files in a given kernel, possibly listing it in - the SRC_URI and adding the machine to the expression in - COMPATIBLE_MACHINE - : - - -COMPATIBLE_MACHINE = '(qemux86|qemumips)' - -
- -
- Adding a formfactor configuration file - - 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 - -
-
- -
- Making and Maintaining Changes - - - 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. - - -
- Bitbake Layers - - - 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-moblin \ - /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 layers packages, classes and configuration 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 packages directory, add to BBFILES -BBFILES := "${BBFILES} ${LAYERDIR}/packages/*/*.bb \ - ${LAYERDIR}/packages/*/*.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. - -
- -
- Committing Changes - - - 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. - -
- -
- Package Revision Incrementing - - - 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. - -
-
- Using Poky in a Team Environment - - - 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. - -
- -
- Updating Existing Images - - - 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 -
-
- -
- Modifying Package Source Code - - - 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. - - -
- Modifying Package Source Code with quilt - - - 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. - - -
- -
-
- Track license change - - 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. - - -
- Specifying the 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 - - -
- -
- Explanation of syntax - - - 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. - - -
-
-
- Handle package name alias - -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 - - -
- Specifying the DISTRO_PN_ALIAS variable - - -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. - - -
-
- - - -- cgit v1.2.3