diff options
Diffstat (limited to 'handbook/extendpoky.xml')
| -rw-r--r-- | handbook/extendpoky.xml | 814 |
1 files changed, 0 insertions, 814 deletions
diff --git a/handbook/extendpoky.xml b/handbook/extendpoky.xml deleted file mode 100644 index fa789d4af..000000000 --- a/handbook/extendpoky.xml +++ /dev/null @@ -1,814 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<chapter id='extendpoky'> - -<title>Extending Poky</title> - - <para> - 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. - </para> - - <section id='usingpoky-extend-addpkg'> - <title>Adding a Package</title> - - <para> - 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 <link linkend='ref-varlocality-recipe-required'> - recipe reference</link> section along with more detailed information - about issues such as recipe naming. - </para> - - <para> - Before writing a recipe from scratch it is often useful to check - someone else hasn't 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. - </para> - - <para> - 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: - </para> - - <section id='usingpoky-extend-addpkg-singlec'> - <title>Single .c File Package (Hello World!)</title> - - <para> - To build an application from a single file stored locally requires a - recipe which has the file listed in the <glossterm><link - linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable. In addition - the <function>do_compile</function> and <function>do_install</function> - tasks need to be manually written. The <glossterm><link linkend='var-S'> - S</link></glossterm> variable defines the directory containing the source - code which in this case is set equal to <glossterm><link linkend='var-WORKDIR'> - WORKDIR</link></glossterm>, the directory BitBake uses for the build. - </para> - <programlisting> -DESCRIPTION = "Simple helloworld application" -SECTION = "examples" -LICENSE = "MIT" - -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} -} - </programlisting> - - <para> - As a result of the build process "helloworld" and "helloworld-dbg" - packages will be built. - </para> - </section> - - <section id='usingpoky-extend-addpkg-autotools'> - <title>Autotooled Package</title> - - <para> - Applications which use autotools (autoconf, automake) - require a recipe which has a source archive listed in - <glossterm><link - linkend='var-SRC_URI'>SRC_URI</link></glossterm> and - <command>inherit autotools</command> to instruct BitBake to use the - <filename>autotools.bbclass</filename> 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). - </para> - - <programlisting> -DESCRIPTION = "GNU Helloworld application" -SECTION = "examples" -LICENSE = "GPLv2" - -SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2" - -inherit autotools - </programlisting> - - </section> - - <section id='usingpoky-extend-addpkg-makefile'> - <title>Makefile-Based Package</title> - - <para> - Applications which use GNU make require a recipe which has - the source archive listed in <glossterm><link - linkend='var-SRC_URI'>SRC_URI</link></glossterm>. - Adding a <function>do_compile</function> 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 - <glossterm><link - linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></glossterm> variable - BitBake - will pass them into the GNU - make invocation. A <function>do_install</function> task is required - - otherwise BitBake will run an empty <function>do_install</function> - task by default. - </para> - - <para> - 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 <glossterm><link - linkend='var-CFLAGS'>CFLAGS</link></glossterm> variable, as in the example below. - </para> - - <programlisting> -DESCRIPTION = "Tools for managing memory technology devices." -SECTION = "base" -DEPENDS = "zlib" -HOMEPAGE = "http://www.linux-mtd.infradead.org/" -LICENSE = "GPLv2" - -SRC_URI = "ftp://ftp.infradead.org/pub/mtd-utils/mtd-utils-${PV}.tar.gz" - -CFLAGS_prepend = "-I ${S}/include " - -do_install() { - oe_runmake install DESTDIR=${D} -} - </programlisting> - - </section> - - <section id='usingpoky-extend-addpkg-files'> - <title>Controlling packages content</title> - - <para> - The variables <glossterm><link - linkend='var-PACKAGES'>PACKAGES</link></glossterm> and - <glossterm><link linkend='var-FILES'>FILES</link></glossterm> are used to split an - application into multiple packages. - </para> - - <para> - Below the "libXpm" recipe 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. - </para> - - <programlisting> -require xorg-lib-common.inc - -DESCRIPTION = "X11 Pixmap library" -LICENSE = "X-BSD" -DEPENDS += "libxext" - -XORG_PN = "libXpm" - -PACKAGES =+ "sxpm cxpm" -FILES_cxpm = "${bindir}/cxpm" -FILES_sxpm = "${bindir}/sxpm" - </programlisting> - - <para> - In this example we want to ship the "sxpm" and "cxpm" binaries - in separate packages. Since "bindir" would be packaged into the - main <glossterm><link linkend='var-PN'>PN</link></glossterm> - package as standard we prepend the <glossterm><link - linkend='var-PACKAGES'>PACKAGES</link></glossterm> variable so - additional package names are added to the start of list. The - extra <glossterm><link linkend='var-PN'>FILES</link></glossterm>_* - variables then contain information to specify which files and - directories goes into which package. - </para> - </section> - - <section id='usingpoky-extend-addpkg-postinstalls'> - <title>Post Install Scripts</title> - - <para> - To add a post-installation script to a package, add - a <function>pkg_postinst_PACKAGENAME()</function> - function to the .bb file - where PACKAGENAME is the name of the package to attach - the postinst script to. A post-installation function has the following structure: - </para> - <programlisting> -pkg_postinst_PACKAGENAME () { -#!/bin/sh -e -# Commands to carry out -} - </programlisting> - <para> - 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. - </para> - - <para> - 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: - </para> - - <programlisting> -pkg_postinst_PACKAGENAME () { -#!/bin/sh -e -if [ x"$D" = "x" ]; then -# Actions to carry out on the device go here -else -exit 1 -fi -} - </programlisting> - - <para> - The structure above delays execution until first boot - because the <glossterm><link - linkend='var-D'>D</link></glossterm> variable points - to the 'image' - directory when the rootfs is being made at build time but - is unset when executed on the first boot. - </para> - </section> - - </section> - - <section id='usingpoky-extend-customimage'> - <title>Customising Images</title> - - <para> - Poky images can be customised to satisfy - particular requirements. Several methods are detailed below - along with guidelines of when to use them. - </para> - - <section id='usingpoky-extend-customimage-custombb'> - <title>Customising Images through a custom image .bb files</title> - - <para> - One way to get additional software into an image is by creating a - custom image. The recipe will contain two lines: - </para> - - <programlisting> -IMAGE_INSTALL = "task-poky-x11-base package1 package2" - -inherit poky-image - </programlisting> - - <para> - 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 <glossterm><link - linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></glossterm> variable. - The names must be in - the OpenEmbedded notation instead of Debian notation, for example - "glibc-dev" instead of "libc6-dev" etc. - </para> - - <para> - 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: - </para> - - <programlisting> -require poky-image-sato.bb - -IMAGE_INSTALL += "strace" - </programlisting> - - </section> - - <section id='usingpoky-extend-customimage-customtasks'> - <title>Customising Images through custom tasks</title> - - <para> - 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 <filename>meta/packages/tasks/task-poky.bb - </filename>. The <glossterm><link linkend='var-PACKAGES'>PACKAGES</link></glossterm> - variable lists the task packages to build (along with the complementary - -dbg and -dev packages). For each package added, - <glossterm><link linkend='var-PACKAGES'>RDEPENDS</link></glossterm> and - <glossterm><link linkend='var-PACKAGES'>RRECOMMENDS</link></glossterm> - entries can then be added each containing a list of packages the parent - task package should contain. An example would be: - </para> - - <para> - <programlisting> -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" -</programlisting> - </para> - - <para> - In this example, two tasks 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 <glossterm><link - linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></glossterm> or other forms - of image dependencies as described in other areas of this section. - </para> - </section> - - <section id='usingpoky-extend-customimage-imagefeatures'> - <title>Customising Images through custom <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm></title> - - <para> - Ultimately users may want to add extra image "features" as used by Poky with the - <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> - 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 - <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> - variable and based on this generates the <glossterm><link linkend='var-IMAGE_INSTALL'> - IMAGE_INSTALL</link></glossterm> variable automatically. Extra features can be added by - extending the class or creating a custom class for use with specialised image .bb files. - </para> - </section> - - <section id='usingpoky-extend-customimage-localconf'> - <title>Customising Images through local.conf</title> - - <para> - 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. - </para> - - <para> - To add an "strace" package into the image the following is - added to local.conf: - </para> - - <programlisting> -DISTRO_EXTRA_RDEPENDS += "strace" - </programlisting> - - <para> - However, since the <glossterm><link linkend='var-DISTRO_EXTRA_RDEPENDS'> - DISTRO_EXTRA_RDEPENDS</link></glossterm> 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 - and the the image built. - </para> - <programlisting> -bitbake -cclean task-boot task-base task-poky -bitbake poky-image-sato - </programlisting> - - <para> - Cleaning task-* packages is required because they use the - <glossterm><link linkend='var-DISTRO_EXTRA_RDEPENDS'> - 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 - dependencies will be built automatically. 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. - </para> - - </section> - - </section> - -<section id="platdev-newmachine"> - <title>Porting Poky to a new machine</title> - <para> - 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. - </para> - - <section id="platdev-newmachine-conffile"> - <title>Adding the machine configuration file</title> - <para> - 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. - </para> - - <para> - The most important variables to set in this file are <glossterm> - <link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></glossterm> - (e.g. "arm"), <glossterm><link linkend='var-PREFERRED_PROVIDER'> - PREFERRED_PROVIDER</link></glossterm>_virtual/kernel (see below) and - <glossterm><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES - </link></glossterm> (e.g. "kernel26 apm screen wifi"). Other variables - like <glossterm><link linkend='var-SERIAL_CONSOLE'>SERIAL_CONSOLE - </link></glossterm> (e.g. "115200 ttyS0"), <glossterm> - <link linkend='var-KERNEL_IMAGETYPE'>KERNEL_IMAGETYPE</link> - </glossterm> (e.g. "zImage") and <glossterm><link linkend='var-IMAGE_FSTYPES'> - IMAGE_FSTYPES</link></glossterm> (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. - </para> - </section> - - <section id="platdev-newmachine-kernel"> - <title>Adding a kernel for the machine</title> - <para> - 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 - packages/linux directory which can be used as references. - </para> - <para> - If creating a new recipe the "normal" recipe writing rules apply - for setting up a <glossterm><link linkend='var-SRC_URI'>SRC_URI - </link></glossterm> including any patches and setting <glossterm> - <link linkend='var-S'>S</link></glossterm> 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. - </para> - <para> - 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 <glossterm> - <link linkend='var-COMPATIBLE_MACHINE'>COMPATIBLE_MACHINE</link> - </glossterm>. - </para> - </section> - - <section id="platdev-newmachine-formfactor"> - <title>Adding a formfactor configuration file</title> - <para> - 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. - </para> - <para> - Sane defaults should be used in most cases, but if customisation is - necessary you need to create a <filename>machconfig</filename> file - under <filename>meta/packages/formfactor/files/MACHINENAME/</filename> - where <literal>MACHINENAME</literal> is the name for which this infomation - applies. For information about the settings available and the defaults, please see - <filename>meta/packages/formfactor/files/config</filename>. - </para> - </section> -</section> - -<section id='usingpoky-changes'> - <title>Making and Maintaining Changes</title> - - <para> - 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. - </para> - <para> - Poky supports the idea of <link - linkend='usingpoky-changes-collections'>"collections"</link> 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. - </para> - - <section id="usingpoky-changes-collections"> - <title>Bitbake Collections</title> - - <para> - 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 - collections which provide a way to handle this which is fully - supported and actively encouraged within Poky. - </para> - <para> - In the standard tree, meta-extras is an example of how you can - do this. As standard the data in meta-extras is not used on a - Poky build but local.conf.sample shows how to enable it: - </para> - <para> - <literallayout class='monospaced'> -BBFILES := "${OEROOT}/meta/packages/*/*.bb ${OEROOT}/meta-extras/packages/*/*.bb" -BBFILE_COLLECTIONS = "normal extras" -BBFILE_PATTERN_normal = "^${OEROOT}/meta/" -BBFILE_PATTERN_extras = "^${OEROOT}/meta-extras/" -BBFILE_PRIORITY_normal = "5" -BBFILE_PRIORITY_extras = "5"</literallayout> - </para> - <para> - As can be seen, the extra recipes are added to BBFILES. The - BBFILE_COLLECTIONS variable is then set to contain a list of - collection names. The BBFILE_PATTERN variables are regular - expressions used to match files from BBFILES into a particular - collection in this case by using the base pathname. - The BBFILE_PRIORITY variable then assigns the different - priorities to the files in different collections. This is useful - in situations where the same package might appear in both - repositories and allows you to choose which collection should - 'win'. - </para> - <para> - This works well for recipes. For bbclasses and configuration - files, you can use 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. - </para> - </section> - - <section id="usingpoky-changes-supplement"> - <title>Supplementry Metadata Repositories</title> - - <para> - Often when developing a project based on Poky there will be components - that are not ready for public consumption for whatever reason. By making - use of the collections mechanism and other functionality within Poky, it - is possible to have a public repository which is supplemented by a private - one just containing the pieces that need to be kept private. - </para> - <para> - The usual approach with these is to create a separate git repository called - "meta-prvt-XXX" which is checked out alongside the other meta-* - directories included in Poky. Under this directory there can be several - different directories such as classes, conf and packages which all - function as per the usual Poky directory structure. - </para> - <para> - If extra meta-* directories are found, Poky will automatically add them - into the BBPATH variable so the conf and class files contained there - are found. If a file called poky-extra-environment is found within the - meta-* directory, this will be sourced as the environment is setup, - allowing certain configuration to be overridden such as the location of the - local.conf.sample file that is used. - </para> - <para> - Note that at present, BBFILES is not automatically changed and this needs - to be adjusted to find files in the packages/ directory. Usually a custom - local.conf.sample file will be used to handle this instead. - </para> - </section> - - <section id='usingpoky-changes-commits'> - <title>Committing Changes</title> - - <para> - 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. - </para> - - <para> - 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. - </para> - - <para> - 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. - </para> - </section> - - <section id='usingpoky-changes-prbump'> - <title>Package Revision Incrementing</title> - - <para> - If a committed change will result in changing the package output - then the value of the <glossterm><link linkend='var-PR'>PR</link> - </glossterm> variable needs to be increased (commonly referred to - as 'bumped') as part of that commit. Only integer values are used - and <glossterm><link linkend='var-PR'>PR</link></glossterm> = - "r0" should not be added into new recipes as this is default value. - When upgrading the version of a package (<glossterm><link - linkend='var-PV'>PV</link></glossterm>), the <glossterm><link - linkend='var-PR'>PR</link></glossterm> variable should be removed. - </para> - - <para> - The aim is that the package version will only ever increase. If - for some reason <glossterm><link linkend='var-PV'>PV</link></glossterm> - will change and but not increase, the <glossterm><link - linkend='var-PE'>PE</link></glossterm> (Package Epoch) can - be increased (it defaults to '0'). The version numbers aim to - follow the <ulink url='http://www.debian.org/doc/debian-policy/ch-controlfields.html'> - Debian Version Field Policy Guidelines</ulink> which define how - versions are compared and hence what "increasing" means. - </para> - - <para> - 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 <command> - opkg update;opkg upgrade</command> commands (or similar for - dpkg/apt or rpm based systems). The aim is to ensure Poky has - upgradable packages in all cases. - </para> - </section> - <section id='usingpoky-changes-collaborate'> - <title>Using Poky in a Team Environment</title> - - <para> - 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. - </para> - - <para> - 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. - </para> - - <para> - 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. - </para> - <para> - 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. - </para> - </section> - </section> - - <section id='usingpoky-modifing-packages'> - <title>Modifying Package Source Code</title> - - <para> - Poky is usually used to build software rather than modifying - it. However, there are ways Poky can be used to modify software. - </para> - - <para> - During building, the sources are available in <glossterm><link - linkend='var-WORKDIR'>WORKDIR</link></glossterm> directory. - Where exactly this is depends on the type of package and the - architecture of target device. For a standard recipe not - related to <glossterm><link - linkend='var-MACHINE'>MACHINE</link></glossterm> it will be - <filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>. - Target device dependent packages use <glossterm><link - linkend='var-MACHINE'>MACHINE - </link></glossterm> - instead of <glossterm><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH - </link></glossterm> - in the directory name. - </para> - - <tip> - <para> - Check the package recipe sets the <glossterm><link - linkend='var-S'>S</link></glossterm> variable to something - other than standard <filename>WORKDIR/PN-PV/</filename> value. - </para> - </tip> - <para> - 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: - </para> - - <programlisting> -bitbake --cmd compile --force NAME_OF_PACKAGE - </programlisting> - - <para> - Other tasks may also be called this way. - </para> - - <section id='usingpoky-modifying-packages-quilt'> - <title>Modifying Package Source Code with quilt</title> - - <para> - By default Poky uses <ulink - url='http://savannah.nongnu.org/projects/quilt'>quilt</ulink> - to manage patches in <function>do_patch</function> task. - It is a powerful tool which can be used to track all - modifications done to package sources. - </para> - - <para> - Before modifying source code it is important to - notify quilt so it will track changes into new patch - file: - <programlisting> -quilt new NAME-OF-PATCH.patch - </programlisting> - - Then add all files which will be modified into that - patch: - <programlisting> -quilt add file1 file2 file3 - </programlisting> - - Now start editing. At the end quilt needs to be used - to generate final patch which will contain all - modifications: - <programlisting> -quilt refresh - </programlisting> - - The resulting patch file can be found in the - <filename class="directory">patches/</filename> subdirectory of the source - (<glossterm><link linkend='var-S'>S</link></glossterm>) directory. For future builds it - should be copied into - Poky metadata and added into <glossterm><link - linkend='var-SRC_URI'>SRC_URI</link></glossterm> of a recipe: - <programlisting> -SRC_URI += "file://NAME-OF-PATCH.patch;patch=1" - </programlisting> - - This also requires a bump of <glossterm><link - linkend='var-PR'>PR</link></glossterm> value in the same recipe as we changed resulting packages. - </para> - - </section> - -</section> - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> |