diff options
Diffstat (limited to 'documentation/poky-ref-manual')
33 files changed, 0 insertions, 7611 deletions
diff --git a/documentation/poky-ref-manual/Makefile b/documentation/poky-ref-manual/Makefile deleted file mode 100644 index 2ed7cd423..000000000 --- a/documentation/poky-ref-manual/Makefile +++ /dev/null @@ -1,36 +0,0 @@ -XSLTOPTS = --stringparam html.stylesheet style.css \ - --stringparam chapter.autolabel 1 \ - --stringparam appendix.autolabel A \ - --stringparam section.autolabel 1 \ - --stringparam section.label.includes.component.label 1 \ - --xinclude - -## -# These URI should be rewritten by your distribution's xml catalog to -# match your localy installed XSL stylesheets. -XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current -XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl - -all: html pdf tarball - -pdf: - ../tools/poky-docbook-to-pdf poky-ref-manual.xml ../template - -html: -# See http://www.sagehill.net/docbookxsl/HtmlOutput.html - xsltproc $(XSLTOPTS) -o poky-ref-manual.html poky-ref-manual-customization.xsl poky-ref-manual.xml - -tarball: html - tar -cvzf poky-ref-manual.tgz poky-ref-manual.html style.css figures/yocto-project-transp.png figures/poky-ref-manual.png screenshots/ss-sato.png - -validate: - xmllint --postvalid --xinclude --noout poky-ref-manual.xml - -OUTPUTS = poky-ref-manual.tgz poky-ref-manual.html poky-ref-manual.pdf -SOURCES = *.png *.xml *.css *.svg - -publish: - scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/ - -clean: - rm -f $(OUTPUTS) diff --git a/documentation/poky-ref-manual/TODO b/documentation/poky-ref-manual/TODO deleted file mode 100644 index ee0db977c..000000000 --- a/documentation/poky-ref-manual/TODO +++ /dev/null @@ -1,11 +0,0 @@ -Handbook Todo List: - - * Document adding a new IMAGE_FEATURE to the customising images section - * Add instructions about using zaurus/openmoko emulation - * Add component overview/block diagrams - * Software Deevelopment intro should mention its software development for - intended target and could be a different arch etc and thus special case. - * Expand insane.bbclass documentation to cover tests - * Document remaining classes (see list in ref-classes) - * Document formfactor - diff --git a/documentation/poky-ref-manual/development.xml b/documentation/poky-ref-manual/development.xml deleted file mode 100644 index 45df028f8..000000000 --- a/documentation/poky-ref-manual/development.xml +++ /dev/null @@ -1,1125 +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="platdev"> -<title>Platform Development with Poky</title> - - <section id="platdev-appdev"> - <title>Software development</title> - <para> - Poky supports several methods of software development. You can use the method that is - best for you. This chapter describes each development method. - </para> - - <section id="platdev-appdev-external-sdk"> - <title>External Development Using the Application Development Toolkit (ADT)</title> - <para> - The meta-toolchain and meta-toolchain-sdk targets build tarballs that contain toolchains and - libraries suitable for application development outside of Poky. - For information on these targets see the <ulink linkend='ref-images'>Reference: Images</ulink> - appendix. - </para> - <para> - These tarballs unpack into the - <filename class="directory">/opt/poky</filename> directory and contain - a setup script (e.g. - <filename>/opt/poky/environment-setup-i586-poky-linux</filename>), from which - you can source to initialize a suitable environment. Sourcing these files adds the - compiler, QEMU scripts, QEMU binary, a special version of pkgconfig and other - useful utilities to the PATH variable. Variables to assist pkgconfig and - autotools are also defined so that, for example, configure can find pre-generated test - results for tests that need target hardware on which to run. - </para> - <para> - Using the toolchain with autotool-enabled packages is straightforward - just pass the - appropriate host option to configure. - Following is an example: - <literallayout class='monospaced'> - $ ./configure --host=arm-poky-linux-gnueabi - </literallayout> - For other projects it is usually a case of ensuring the cross tools are used: - <literallayout class='monospaced'> - CC=arm-poky-linux-gnueabi-gcc and LD=arm-poky-linux-gnueabi-ld - </literallayout> - </para> - </section> - - <section id="using-the-eclipse-and-anjuta-plug-ins"> - <title>Using the Eclipse Plug-in</title> - <para> - The current release of the Yocto Project supports the Eclipse IDE plug-in - to make developing software easier for the application developer. - The plug-in provides capability extensions to the graphical IDE to allow - for cross compilation, deployment and execution of the output in a QEMU - emulation session. - Support of the Eclipse plug-in also allows for cross debugging and - profiling. - Additionally, the Eclipse plug-in provides a suite of tools - that allows the developer to perform remote profiling, tracing, collection of - power data, collection of latency data and collection of performance data. - </para> - <note> - The current release of the Yocto Project no longer supports the Anjuta plug-in. - However, the Poky Anjuta Plug-in is available to download directly from the Poky - Git repository located through the web interface at - <ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins. - The community is free to continue supporting it beyond the Yocto Project 0.9 - Release. - </note> - <para> - To use the Eclipse plug-in you need the Eclipse Framework (Helios 3.6.1) along - with other plug-ins installed into the Eclipse IDE. - Once you have your environment setup you need to configure the Eclipse plug-in. - For information on how to install and configure the Eclipse plug-in, see the - <ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html#adt-eclipse'> - "Working Within Eclipse"</ulink> chapter in the - <ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html'> - "Application Development Toolkit (ADT) User's Guide."</ulink> - </para> - - - -<!-- - - <section id="the-eclipse-plug-in"> - <title>The Eclipse Plug-in</title> - <para> - To use the Eclipse plug-in, a toolchain and SDK built by Poky is required along with - the Eclipse Framework (Helios 3.6.1). - To install the plug-in you need to be in the Eclipse IDE and select - the following menu: - <literallayout class='monospaced'> - Help -> Install New Software - </literallayout> - Specify the target URL as - <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink>. - </para> - <para> - If you want to download the source code for the plug-in you can find it in the Poky - git repository, which has a web interface, and is located at - <ulink url="http://git.yoctoproject.org"></ulink> under IDE Plugins. - </para> - - <section id="installing-and-setting-up-the-eclipse-ide"> - <title>Installing and Setting up the Eclipse IDE</title> - <para> - If you don't have the Eclipse IDE (Helios 3.6.1) on your system you need to - download and install it from <ulink url="http://www.eclipse.org/downloads"></ulink>. - Choose the Eclipse Classic, which contains the Eclipse Platform, Java Development - Tools (JDT), and the Plug-in Development Environment. - </para> - <note> - <para> - Due to the Java Virtual Machine's garbage collection (GC) process the - permanent generation space (PermGen) is not cleaned up. This space stores - meta-data descriptions of classes. The default value is set too small - and it could trigger an out-of-memory error like the following: - <literallayout class='monospaced'> - Java.lang.OutOfMemoryError: PermGen space - </literallayout> - This error causes the applications to hang. - </para> - </note> - <para> - To fix this issue you can use the <filename>-vmargs</filename> - option when you start Eclipse to increase the size of the permanent generation space: - <literallayout class='monospaced'> - Eclipse -vmargs -XX:PermSize=256M - </literallayout> - </para> - </section> - - <section id="installing-the-yocto-plug-in"> - <title>Installing the Yocto Plug-in</title> - <para> - Once you have the Eclipse IDE installed and configured you need to install the - Yocto plug-in. You do this similar to installing the Eclipse plug-ins in the - previous section. - </para> - <para> - Do the following to install the Yocto plug-in into the Eclipse IDE: - <orderedlist> - <listitem><para>Select the "Help -> Install New Software" item.</para></listitem> - <listitem><para>In the "Work with:" area click "Add..." and enter the URL for - the Yocto plug-in, which is - <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/'></ulink></para></listitem> - <listitem><para>Finish out the installation of the update similar to any other - Eclipse plug-in.</para></listitem> - </orderedlist> - </para> - </section> - - <section id="configuring-yocto-eclipse-plug-in"> - <title>Configuring Yocto Eclipse plug-in</title> - <para> - To configure the Yocto Eclipse plug-in you need to select the mode and the - architecture with which you will be working. Start by selecting "Preferences" - from the "Window" menu and then select "Yocto SDK". - </para> - <para> - If you normally will use an installed Yocto - SDK (under <filename>/opt/poky</filename>) select “SDK Root Mode”. Otherwise, if your crosstool chain - and sysroot are within your poky tree, select “Poky Tree Mode”. - If you are in SDK Root Mode you need to provide your poky tree path, for - example, <filename>$<Poky_tree>/build/</filename>. - </para> - <para> - Next, you need to select the architecture. - Use the drop down list and select the architecture that you’ll be primarily - working against. - For target option, select your typical target QEMU vs External hardware. If you - choose QEMU, you’ll need to specify your QEMU kernel file with full path and the - rootfs mount point. Yocto QEMU boots off user mode NFS. - See the <link linkend='platdev-appdev-qemu'>Developing Externally in QEMU</link> section for - how to set it up. - </para> - <para> - To make your settings the defaults for every new Yocto project created using - the Eclipse IDE, simply save the settings. - </para> - </section> - - <section id="using-the-yocto-eclipse-plug-in"> - <title>Using the Yocto Eclipse Plug-in</title> - <para> - As an example, this section shows you how to cross-compile a Yocto C project that - is autotools-based, deploy the project into QEMU, and then run the debugger against it. - You need to configure the project, trigger the <filename> autogen.sh</filename>, build - the image, start QEMU, and then debug. - </para> - <para> - The following steps show how to create a Yocto autotools-based project using a given template: - </para> - <orderedlist> - <listitem><para>Select "File -> New -> Project" to start the wizard.</para></listitem> - <listitem><para>Expand "C/C++" and select "C Project".</para></listitem> - <listitem><para>Click "Next" and select a template (e.g. "Hello World ANSI C Project").</para></listitem> - <listitem><para>Complete the steps to create the new Yocto autotools-based project using - your chosen template.</para></listitem> - </orderedlist> - <para> - By default, the project uses the Yocto preferences settings as defined using the procedure in - <link linkend="configuring-yocto-eclipse-plug-in">the previous section</link>. - If there are any specific setup requirements for the newly created project - you need to reconfigure the Yocto plug-in through the menu selection by doing the following: - </para> - <orderedlist> - <listitem><para>Select the "Project -> Invoke Yocto Tools -> Reconfigure Yocto" menu item.</para></listitem> - <listitem><para>Complete the dialogue to specify the specific toolchain and QEMU setup information.</para></listitem> - </orderedlist> - <para> - To build the project follow these steps: - </para> - <orderedlist> - <listitem><para>Select "Project -> Reconfigure Project" to trigger the - <filename>autogen.sh</filename> command.</para></listitem> - <listitem><para>Select "Project -> Build" to build the project.</para></listitem> - </orderedlist> - <para> - To start QEMU follow these steps: - </para> - <orderedlist> - <listitem><para>Select "Run -> External Tools" and see if there is - a QEMU instance for the desired target. - If one exists, click on the instance to start QEMU. - If your target does not exist, click "External Tools Configuration" and - you should find an instance of QEMU for your architecture - under the entry under "Program".</para></listitem> - <listitem><para>Wait for the boot to complete.</para></listitem> - </orderedlist> - <para> - To deploy your project and start debugging follow these steps: - </para> - <orderedlist> - <listitem><para>Highlight your project in the project explorer.</para></listitem> - <listitem><para>Select "Run -> Debug Configurations" to bring up your remote debugging configuration - in the right-hand window.</para></listitem> - <listitem><para>Expand “C/C++ Remote Application”.</para></listitem> - <listitem><para>Select "projectname_ gdb_target-poky-linux". - You need to be sure there is an entry for the remote target. - If no entry exists, click "New..." to bring up the wizard. - Use the wizard to select TCF and enter the IP address of you remote target in the - “Host name:” field. - Back in the Remote Debug Configure window, specify in the - “Remote Absolute File Path for C/C++ Application” field the absolute path for the program on - the remote target. - By default, the program deploys into the remote target. - If you don't want this behavior then check “Skip download to target path”.</para></listitem> - <listitem><para>Click "Debug” to start the remote debugging session.</para></listitem> - </orderedlist> - </section> - - <section id="using-yocto-eclipse-plug-in-remote-tools-suite"> - <title>Using Yocto Eclipse plug-in Remote Tools Suite</title> - <para> - Remote tools allow you to perform system profiling, kernel tracing, - examine power consumption, and so forth. To see and access the remote tools use the - "Window -> YoctoTools" menu. - </para> - <para> - Once you pick a tool you need to configure it for the remote target. Every tool - needs to have the connection configured. You must select an existing TCF-based - RSE connection to the remote target. If one does not exist, click "New" to create one. - </para> - <para> - Here are some specifics about the remote tools: - <itemizedlist> - <listitem><para>OProfile: Selecting this tool causes the oprofile-server on the remote - target to launch on the local host machine. The oprofile-viewer - must be installed on the local host machine and the oprofile-server must be - installed on the remote target, respectively, in order to use .</para></listitem> - <listitem><para>lttng: Selecting this tool runs "usttrace" on the remote target, transfers - the output data back to the local host machine and uses "lttv-gui" to graphically - display the output. The "lttv-gui" must be installed on the - local host machine to use this tool. - For information on how to use "lttng" to trace an - application, see <ulink url="http://lttng.org/files/ust/manual/ust.html"></ulink>. - <para> - For "Application" you must supply the absolute path name of the application to - be traced by user mode lttng. For example, typing <filename>/path/to/foo" - </filename> triggers "usttrace /path/to/foo" on the - remote target to trace the program <filename>/path/to/foo</filename>. - </para> - <para> - "Argument" is passed to "usttrace" running on the remote target. - </para></para> - </listitem> - <listitem><para>powertop: Selecting this tool runs "powertop" on the - remote target machine and displays the results in a new view called "powertop". - <para> - "Time to gather data(sec):" is the time passed in seconds before data is - gathered from the remote target for analysis. - </para> - <para> - "show pids in wakeups list:" corresponds to the <filename>-p</filename> - argument passed to "powertop". - </para></para> - </listitem> - <listitem><para>latencytop and perf: "latencytop" identifies - system latency, while "perf" monitors the system's performance - counter registers. Selecting either of these tools causes an RSE - terminal view to appear from which you can run the tools. Both tools refresh the - entire screen to display results while they run.</para></listitem> - </itemizedlist> - </para> - </section> - </section> - - <section id="the-anjuta-plug-in"> - <title>The Anjuta Plug-in</title> - <note> - <para> - Support for the Anjuta plug-in ends after Yocto project 0.9 Release. - However, the source code can be downloaded from the git repository listed later in - this section. - The community is free to continue supporting it post 0.9 Release. - </para> - </note> - <para> - An Anjuta IDE plug-in exists to make developing software within the Poky framework - easier for the application developer familiar with that environment. - The plug-in presents a graphical IDE that allows you to cross-compile, cross-debug, - profile, deploy, and execute an application. - </para> - <para> - To use the plug-in, a toolchain and SDK built by Poky, Anjuta, its development headers and the Anjuta - Plug-in are all required. - The Poky Anjuta Plug-in is available to download as a tarball at the OpenedHand - labs <ulink url="http://labs.o-hand.com/anjuta-poky-sdk-plugin/"></ulink> page or - directly from the Poky Git repository located at git://git.yoctoproject.org/anjuta-poky. - You can access the source code from a web interface to the repository at - <ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins. - </para> - <para> - See the README file contained in the project for more information on - Anjuta dependencies and building the plug-in. - If you want to disable remote gdb debugging, pass the "‐‐disable-gdb-integration" switch when - you configure the plug-in. - </para> - <section id="setting-up-the-anjuta-plugin"> - <title>Setting Up the Anjuta Plug-in</title> - <para> - Follow these steps to set up the plug-in: - <orderedlist> - <listitem><para>Extract the tarball for the toolchain into / as root. - The toolchain will be installed into <filename>/opt/poky</filename>.</para></listitem> - <listitem><para>To use the plug-in, first open or create an existing project. - If you are creating a new project, the "C GTK+" - project type will allow itself to be cross-compiled. - However, you should be aware that this type uses "glade" for the UI.</para></listitem> - <listitem><para>To activate the plug-in, select "Edit -> Preferences" and then choose - "General" from the left hand side. - Choose the "Installed plug-ins" tab, scroll down to "Poky SDK" and - check the box.</para></listitem> - </orderedlist> - The plug-in is now activated but not configured. - </para> - </section> - <section id="configuring-the-anjuta-plugin"> - <title>Configuring the Anjuta Plug-in</title> - <para> - You can find the configuration options for the SDK by choosing the Poky - SDK icon from the left hand side. - You need to define the following options: - <itemizedlist> - <listitem><para>SDK root: If you use an external toolchain you need to set - SDK root, which is the root directory of the SDK's sysroot. - For an i586 SDK directory is <filename>/opt/poky/</filename>. - This directory will contain "bin", "include", "var" and so forth under your - selected target architecture subdirectory - <filename>/opt/poky/sysroot/i586-poky-linux/</filename>. - The cross-compile tools you need are in - <filename>/opt/poky/sysroot/i586-pokysdk-linux/</filename>.</para></listitem> - <listitem><para>Poky root: If you have a local Poky build tree, you need to - set the Poky root, which is the root directory of the poky build tree. - If you build your i586 target architecture under the subdirectory of - <filename>build_x86</filename> within your Poky tree, the Poky root directory - should be <filename>$<poky_tree>/build_x86/</filename>.</para></listitem> - <listitem><para>Target Architecture: This is the cross compile triplet, - for example, "i586-poky-linux". - This target triplet is the prefix extracted from the set up script file's name. - For example, if the script file name is - <filename>/opt/poky/environment-setup-i586-poky-linux</filename> then the extracted target - triplet is "i586-poky-linux".</para></listitem> - <listitem><para>Kernel: Use the file chooser to select the kernel used with QEMU.</para></listitem> - <listitem><para>Root filesystem: Use the file chooser to select the root - filesystem directory. This directory is where you use "poky-extract-sdk" to extract the - poky-image-sdk tarball.</para></listitem> - </itemizedlist> - </para> - </section> - <section id="using-the-anjuta-plug-in"> - <title>Using the Anjuta Plug-in</title> - <para> - The steps in this section show how to cross-compile a project, deploy it into - QEMU, run a debugger against it and then perform a system-wide profile. - <orderedlist> - <listitem><para>Choose "Build -> Run Configure" or "Build -> Run Autogenerate" to run - "configure" or "autogen", respectively for the project. - Either command passes command-line arguments to instruct the - cross-compile.</para></listitem> - <listitem><para>Choose "Build -> Build Project" to build and compile the project. - If you have previously built the project in the same tree without using - the cross-compiler you might find that your project fails to link. - If this is the case, simply select "Build -> Clean Project" to remove the - old binaries. - After you clean the project you can then try building it again.</para></listitem> - <listitem><para>Choose "Tools -> Start QEMU" to start QEMU. - After QEMU starts any error messages will appear in the message view. - Once Poky has fully booted within QEMU you can deploy the project - into it.</para></listitem> - <listitem><para>Once the project is built and you have QEMU running choose - "Tools -> Deploy" to install the package into a temporary - directory and then copy it using "rsync" over SSH into the target. - A progress bar and appropriate messages appear in the message view.</para></listitem> - <listitem><para>To debug a program installed onto the target choose - "Tools -> Debug remote". - Choosing this menu item causes prompts to appear to define the local binary - for debugging and also for the command line used to run on the target. - When you provide the command line be sure to include the full path to the to binary - installed in the target. - When the command line runs a "gdbserver" over SSH is started on the target and - an instance of "cross-gdb" starts in a local terminal. - The instance of "cross-gdb" will be preloaded to connect to the server and use the SDK root to - find symbols. - It also connects to the target and loads in various libraries as well as the - target program. - You should define any breakpoints or watchpoints at this point in the process since you might not - be able to interrupt the execution later. - To stop the debugger on the target choose "Tools -> Stop debugger".</para></listitem> - <listitem><para>It is also possible to execute a command in the target over SSH. - Doing so causes the appropriate environment to be established for execution. - To execute a command choose "Choose Tools -> Run remote". - This selection opens a terminal with the SSH command inside.</para></listitem> - <listitem><para>To perform a system-wide profile against the system running in QEMU choose - "Tools -> Profile remote". - This choice starts up "OProfileUI" with the appropriate parameters to - connect to the server running inside QEMU and also supplies the path - for debug information necessary to get a useful profile.</para></listitem> - </orderedlist> - </para> - </section> - </section> - - ---> - - </section> - - <section id="platdev-appdev-qemu"> - <title>Developing Externally in QEMU</title> - <para> - Running Poky QEMU images is covered in the - <ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html"> - Yocto Project Quick Start</ulink> in the "A Quick Test Run" section. - </para> - <para> - Poky's QEMU images contain a complete native toolchain. This means - you can develop applications within QEMU similar to the way you would in a normal system. - Using qemux86 on an x86 machine is fast since the - guest and host architectures match. - On the other hand, using qemuarm can be slower but gives - faithful emulation of ARM-specific issues. To speed things up, these - images support using "distcc" to call a cross-compiler outside the - emulated system. If "runqemu" was used to start - QEMU, and "distccd" is present on the host system, any Bitbake cross-compiling - toolchain available from the build system is automatically - used from within QEMU simply by calling "distcc". You can accomplish this by defining the - cross-compiler variable (e.g. <filename>export CC="distcc"</filename>). - Alternatively, if a suitable SDK/toolchain is present in - <filename>/opt/poky</filename> it is also - automatically be used. - </para> - - <para> - There are several options for connecting into the emulated system. - QEMU provides a framebuffer interface that has standard consoles - available. There is also a serial connection available that has a - console to the system running on it and uses standard IP networking. - The images have a dropbear ssh server running with the root password - disabled to allow standard ssh and scp commands to work. The images - also contain an NFS server that exports the guest's root filesystem, which - allows it to be made available to the host. - </para> - </section> - - <section id="platdev-appdev-insitu"> - <title>Developing in Poky Directly</title> - <para> - Working directly in Poky is a fast and effective development technique. - The idea is that you can directly edit files in - <glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm> - or the source directory <glossterm><link linkend='var-S'>S</link></glossterm> - and then force specific tasks to rerun in order to test the changes. - An example session working on the matchbox-desktop package might - look like this: - </para> - - <para> - <literallayout class='monospaced'> - $ bitbake matchbox-desktop - $ sh - $ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/ - $ cd matchbox-desktop-2 - $ vi src/main.c - $ exit - $ bitbake matchbox-desktop -c compile -f - $ bitbake matchbox-desktop - </literallayout> - </para> - - <para> - This example builds the package, changes into the work directory for the package, - changes a file, then recompiles the package. Instead of using "sh" as it is in the example, - you can also use two different terminals. However, the risk of using two terminals - is that a command like "unpack" could destroy the changes you've made to the - work directory. Consequently, you need to work carefully. - </para> - - <para> - It is useful when making changes directly to the work directory files to do - so using "quilt" as detailed in the <link linkend='usingpoky-modifying-packages-quilt'> - modifying packages with quilt</link> section. You can copy the resulting patches - into the recipe directory and use them directly in the <glossterm><link - linkend='var-SRC_URI'>SRC_URI</link></glossterm>. - </para> - <para> - For a review of the skills used in this section see the <link - linkend="usingpoky-components-bitbake">Bitbake</link> and <link - linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> Sections. - </para> - </section> - - <section id="platdev-appdev-devshell"> - <title>Developing with 'devshell'</title> - - <para> - When debugging certain commands or even when just editing packages, the - 'devshell' can be a useful tool. - Use a command like the following to start this tool. - </para> - - <para> - <literallayout class='monospaced'> - $ bitbake matchbox-desktop -c devshell - </literallayout> - </para> - - <para> - This command opens a terminal with a shell prompt within the Poky - environment. Consequently, the following occurs: - <itemizedlist> - <listitem><para>The PATH variable includes the cross toolchain.</para></listitem> - <listitem><para>The pkgconfig variables find the correct <filename>.pc</filename> files.</para></listitem> - <listitem><para>"configure" finds the Poky site files as well as any other necessary files.</para></listitem> - </itemizedlist> - Within this environment, you can run "configure" or "compile" commands as if they - were being run by Poky itself. - The working directory also automatically changes to the (<glossterm><link linkend='var-S'>S</link></glossterm>) - directory. - When you are finished, you just exit the shell or close the terminal window. - </para> - - <para> - The default shell used by "devshell" is the gnome-terminal. - You can use other forms of terminal can by setting the <glossterm> - <link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and <glossterm> - <link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables - in <filename>local.conf</filename>. - For examples of the other options available, see - <filename>meta/conf/bitbake.conf</filename>. - </para> - <para> - An external shell is launched rather than opening directly into the original terminal - window. - This allows easier interaction with Bitbake's multiple threads as well as - for a future client/server split. - Note that "devshell" will still work over X11 forwarding or similar situations. - </para> - - <para> - It is worth remembering that inside "devshell" you need to use the full - compiler name such as <filename>arm-poky-linux-gnueabi-gcc</filename> - instead of just <filename>gcc</filename>. - The same applies to other applications such as gcc, bintuils, libtool and so forth. - Poky will have setup environmental variables such as CC to assist applications, such as make, - find the correct tools. - </para> - </section> - - <section id="platdev-appdev-srcrev"> - <title>Developing within Poky with an External SCM-based Package</title> - - <para> - If you're working on a recipe that pulls from an external SCM it - is possible to have Poky notice new changes added to the - SCM and then build the latest version using them. - This only works for SCMs from which it is possible to get a sensible revision number for changes. - Currently it works for svn, git and bzr repositories. - </para> - - <para> - To enable this behavior simply add <glossterm> - <link linkend='var-SRCREV'>SRCREV</link></glossterm>_pn-<glossterm> - <link linkend='var-PN'>PN</link></glossterm> = "${AUTOREV}" to - <filename>local.conf</filename>, where <glossterm><link linkend='var-PN'>PN</link></glossterm> - is the name of the package for which you want to enable automatic source - revision updating. - </para> - </section> - </section> - -<section id="platdev-gdb-remotedebug"> - <title>Debugging with GDB Remotely</title> - - <para> - GNU Project Debugger (GDB) - allows you to examine running programs to understand and fix problems and - also to perform post-mortem style analysis of program crashes. - GDB is available as a package within Poky and by default is installed in sdk images. - See <ulink url="http://sourceware.org/gdb/"/> for the GDB source. - </para> - <tip><para> - For best results install <filename>-dbg</filename> packages for the applications - you are going to debug. - Doing so makes available extra debug symbols that will give you more meaningful output. - </para></tip> - - <para> - Sometimes, due to memory or disk space constraints, it is not possible - to use GDB directly on the remote target to debug applications. - These constraints arise because GDB needs to load the debugging information and the - binaries of the process being debugged. - Additionally, GDB needs to perform many computations to locate information such as function - names, variable names and values, stack traces and so forth - even before starting the - debugging process. - These extra computations place more load on the target system and can alter the - characteristics of the program being debugged. - </para> - <para> - To help get past these constraints you can use GDBSERVER. - It runs on the remote target and does not load any debugging information - from the debugged process. - Instead, a GDB instance processes the debugging information that is run on a - remote computer - the host GDB. - The host GDB then sends control commands to GDBSERVER to make it stop or start the debugged - program, as well as read or write memory regions of that debugged - program. - All the debugging information loaded and processed as well - as all the heavy debugging is done by the host GDB. - Offloading these processes gives the GDBSERVER running on the target a chance to remain - small and fast. - </para> - <para> - Because the host GDB is responsible for loading the debugging information and - for doing the necessary processing to make actual debugging happen, the - user has to make sure the host can access the unstripped binaries complete - with their debugging information and also compiled with no optimizations. - The host GDB must also have local access to all the libraries used by the - debugged program. - Because GDBSERVER does not need any local debugging information the binaries on - the remote target can remain stripped. - However, the binaries must also be compiled without optimization - so they match the host's binaries. - </para> - - <para> - To remain consistent with GDB documentation and terminology the binary being debugged - on the remote target machine is referred to as the 'inferior' binary. - For documentation on GDB see the GDB site at - <ulink url="http://sourceware.org/gdb/documentation/">on their site</ulink>. - </para> - - <section id="platdev-gdb-remotedebug-launch-gdbserver"> - <title>Launching GDBSERVER on the Target</title> - <para> - First, make sure GDBSERVER is installed on the target. If not, - install the package <filename>gdbserver</filename>, which needs the - <filename>libthread-db1</filename> package. - </para> - <para> - As an example, to launch GDBSERVER on the target and make it ready to "debug" a - program located at <filename>/path/to/inferior</filename>, connect - to the target and launch: - <literallayout class='monospaced'> - $ gdbserver localhost:2345 /path/to/inferior - </literallayout> - GDBSERVER should now be listening on port 2345 for debugging - commands coming from a remote GDB process that is running on the host computer. - Communication between GDBSERVER and the host GDB are done using TCP. - To use other communication protocols please refer to the GDBSERVER documentation. - </para> - </section> - - <section id="platdev-gdb-remotedebug-launch-gdb"> - <title>Launching GDB on the Host Computer</title> - - <para> - Running GDB on the host computer takes a number of stages. - This section describes those stages. - </para> - - <section id="platdev-gdb-remotedebug-launch-gdb-buildcross"> - <title>Building the Cross-GDB Package</title> - <para> - A suitable GDB cross-binary is required that runs on your host computer but - also knows about the the ABI of the remote target. - You can get this binary from the the Poky toolchain - for example: - <programlisting> -/usr/local/poky/eabi-glibc/arm/bin/arm-poky-linux-gnueabi-gdb - </programlisting> - where "arm" is the target architecture and "linux-gnueabi" the target ABI. - </para> - - <para> - Alternatively, Poky can build the <filename>gdb-cross</filename> binary. - For example, the following command builds it: - <literallayout class='monospaced'> - $ bitbake gdb-cross - </literallayout> - Once the binary is built you can find it here: - <programlisting> -tmp/sysroots/<host-arch>/usr/bin/<target-abi>-gdb - </programlisting> - </para> - - </section> - <section id="platdev-gdb-remotedebug-launch-gdb-inferiorbins"> - - <title>Making the Inferior Binaries Available</title> - - <para> - The inferior binary (complete with all debugging symbols) as well as any - libraries (and their debugging symbols) on which the inferior binary depends - need to be available. - There are a number of ways you can make these available. - </para> - - <para> - Perhaps the easiest is to have an 'sdk' image that corresponds to the plain - image installed on the device. - In the case of 'poky-image-sato', 'poky-image-sdk' would contain suitable symbols. - Because the sdk images already have the debugging symbols installed it is just a - question of expanding the archive to some location and then informing GDB. - </para> - - <para> - Alternatively, Poky can build a custom directory of files for a specific - debugging purpose by reusing its <filename>tmp/rootfs</filename> directory. - This directory contains the contents of the last built image. - This process assumes two things: - <itemizedlist> - <listitem><para>The image running on the target was the last image to - be built by Poky.</para></listitem> - <listitem><para>The package (<filename>foo</filename> in the following - example) that contains the inferior binary to be debugged has been built - without optimization and has debugging information available.</para></listitem> - </itemizedlist> - </para> - <para> - These steps show how to build the custom directory of files: - </para> - <orderedlist> - <listitem><para>Install the package (<filename>foo</filename> in this case) to - <filename>tmp/rootfs</filename>: - <programlisting> -tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ -tmp/work/<target-abi>/poky-image-sato-1.0-r0/temp/opkg.conf -o \ -tmp/rootfs/ update - </programlisting></para></listitem> - <listitem><para>Install the debugging information: - <programlisting> -tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ -tmp/work/<target-abi>/poky-image-sato-1.0-r0/temp/opkg.conf \ --o tmp/rootfs install foo - -tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \ -tmp/work/<target-abi>/poky-image-sato-1.0-r0/temp/opkg.conf \ --o tmp/rootfs install foo-dbg - </programlisting></para></listitem> - </orderedlist> - - </section> - <section id="platdev-gdb-remotedebug-launch-gdb-launchhost"> - - <title>Launch the Host GDB</title> - <para> - To launch the host GDB, you run the cross-gdb binary and provide the inferior - binary as part of the command line. - For example, the following command form continues with the example used in - the previous section. - This command form loads the <filename>foo</filename> binary - as well as the debugging information: - <literallayout class='monospaced'> - $ <target-abi>-gdb rootfs/usr/bin/foo - </literallayout> - Once the GDB prompt appears, you must instruct GDB to load all the libraries - of the inferior binary from <filename>tmp/rootfs</filename> as follows: - <literallayout class='monospaced'> - $ set solib-absolute-prefix /path/to/tmp/rootfs - </literallayout> - The pathname <filename>/path/to/tmp/rootfs</filename> must either be - the absolute path to <filename>tmp/rootfs</filename> or the location at which - binaries with debugging information reside. - </para> - <para> - At this point you can have GDB connect to the GDBSERVER that is running - on the remote target by using the following command form: - <literallayout class='monospaced'> - $ target remote remote-target-ip-address:2345 - </literallayout> - The <filename>remote-target-ip-address</filename> is the IP address of the - remote target where the GDBSERVER is running. - Port 2345 is the port on which the GDBSERVER is running. - </para> - - </section> - <section id="platdev-gdb-remotedebug-launch-gdb-using"> - - <title>Using the Debugger</title> - <para> - You can now proceed with debugging as normal - as if you were debugging - on the local machine. - For example, to instruct GDB to break in the "main" function and then - continue with execution of the inferior binary use the following commands - from within GDB: - <literallayout class='monospaced'> - (gdb) break main - (gdb) continue - </literallayout> - </para> - <para> - For more information about using GDB, see the project's online documentation at - <ulink url="http://sourceware.org/gdb/download/onlinedocs/"/>. - </para> - </section> - </section> - -</section> - -<section id="platdev-oprofile"> - <title>Profiling with OProfile</title> - - <para> - <ulink url="http://oprofile.sourceforge.net/">OProfile</ulink> is a - statistical profiler well suited for finding performance - bottlenecks in both userspace software and in the kernel. - This profiler provides answers to questions like "Which functions does my application spend - the most time in when doing X?" - Because Poky is well integrated with OProfile it makes profiling applications on target - hardware straightforward. - </para> - - <para> - To use OProfile you need an image that has OProfile installed. - The easiest way to do this is with "tools-profile" in - <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm>. - You also need debugging symbols to be available on the system where the analysis - takes place. - You can gain access to the symbols by using "dbg-pkgs" in - <glossterm><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> or by - installing the appropriate <filename>-dbg</filename> packages. - </para> - <para> - For successful call graph analysis the binaries must preserve the frame - pointer register and should also be compiled with the - "-fno-omit-framepointer" flag. - In Poky you can achieve this by setting - <glossterm><link linkend='var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION - </link></glossterm> to "-fexpensive-optimizations -fno-omit-framepointer - -frename-registers -O2". - You can also achieve it by setting - <glossterm><link linkend='var-DEBUG_BUILD'>DEBUG_BUILD</link></glossterm> to "1" in - <filename>local.conf</filename>. - If you use the DEBUG_BUILD variable you will also add extra debug information - that can make the debug packages large. - </para> - - <section id="platdev-oprofile-target"> - <title>Profiling on the Target</title> - - <para> - Using OProfile you can perform all the profiling work on the target device. - A simple OProfile session might look like the following: - </para> - - <para> - <literallayout class='monospaced'> -# opcontrol --reset -# opcontrol --start --separate=lib --no-vmlinux -c 5 -[do whatever is being profiled] -# opcontrol --stop -$ opreport -cl - </literallayout> - </para> - - <para> - In this example, the reset command clears any previously profiled data. - The next command starts OProfile. - The options used when starting the profiler separate dynamic library data - within applications, disable kernel profiling, and enable callgraphing up to - five levels deep. - </para> - <note><para> - To profile the kernel, you would specify the - <parameter>--vmlinux=/path/to/vmlinux</parameter> option. - The vmlinux file is usually in <filename class="directory">/boot/</filename> - in Poky and must match the running kernel. - </para></note> - <para> - After you perform your profiling tasks, the next command stops the profiler. - After that you can view results with the "opreport" command with options - to see the separate library symbols and callgraph information. - </para> - <para> - Callgraphing logs information about time spent in functions and about a function's - calling function (parent) and called functions (children). - The higher the callgraphing depth, - the more accurate the results. - However, higher depths also increase the logging - overhead. - Consequently, you should take care when setting the callgraphing depth. - </para> - <note><para> - On ARM, binaries need to have the frame pointer enabled for callgraphing to work. - To accomplish this use the <filename>-fno-omit-framepointer</filename> option - with <filename>gcc</filename>. - </para></note> - <para> - For more information on using OProfile, see the OProfile - online documentation at - <ulink url="http://oprofile.sourceforge.net/docs/"/>. - </para> - </section> - - <section id="platdev-oprofile-oprofileui"> - <title>Using OProfileUI</title> - - <para> - A graphical user interface for OProfile is also available. - You can download and build it from the Yocto Project at - <ulink url="http://git.yoctoproject.org/cgit.cgi/oprofileui/"></ulink>. - If the "tools-profile" image feature is selected, all necessary binaries - are installed onto the target device for OProfileUI interaction. - </para> - -<!-- DISABLED, Need a more 'contextual' shot? - <screenshot> - <mediaobject> - <imageobject> - <imagedata fileref="screenshots/ss-oprofile-viewer.png" format="PNG"/> - </imageobject> - <caption> - <para>OProfileUI Viewer showing an application being profiled on a remote device</para> - </caption> - </mediaobject> - </screenshot> - - <para> - In order to convert the data in the sample format from the target - to the host you need the <filename>opimport</filename> program. - This program is not included in standard Debian OProfile packages. - However, an OProfile package with this addition is available from the - <ulink url='http://debian.o-hand.com/'>OpenedHand repository</ulink>. - We recommend using OProfile 0.9.3 or greater. - </para> ---> - <para> - Even though Poky usually includes all needed patches on the target device, you - might find you need other OProfile patches for recent OProfileUI features. - If so, see the <ulink url='http://git.yoctoproject.org/cgit.cgi/oprofileui/tree/README'> - OProfileUI README</ulink> for the most recent information. - </para> - - <section id="platdev-oprofile-oprofileui-online"> - <title>Online Mode</title> - - <para> - Using OProfile in online mode assumes a working network connection with the target - hardware. - With this connection, you just need to run "oprofile-server" on the device. - By default OProfile listens on port 4224. - </para> - <note><para> - You can change the port using the <filename>--port</filename> command-line - option. - </para></note> - - <para> - The client program is called "oprofile-viewer" and its UI is relatively - straightforward. - You access key functionality through the buttons on the toolbar, which - are duplicated in the menus. - The buttons are: - </para> - - <itemizedlist> - <listitem> - <para> - Connect - Connects to the remote host. - You can also supply the IP address or hostname. - </para> - </listitem> - <listitem> - <para> - Disconnect - Disconnects from the target. - </para> - </listitem> - <listitem> - <para> - Start - Starts profiling on the device. - </para> - </listitem> - <listitem> - <para> - Stop - Stops profiling on the device and downloads the data to the local - host. - Stopping the profiler generates the profile and displays it in the viewer. - </para> - </listitem> - <listitem> - <para> - Download - Downloads the data from the target and generates the profile, - which appears in the viewer. - </para> - </listitem> - <listitem> - <para> - Reset - Resets the sample data on the device. - Resetting the data removes sample information collected from previous - sampling runs. - Be sure you reset the data if you do not want to include old sample information. - </para> - </listitem> - <listitem> - <para> - Save - Saves the data downloaded from the target to another directory for later - examination. - </para> - </listitem> - <listitem> - <para> - Open - Loads previously saved data. - </para> - </listitem> - </itemizedlist> - - <para> - The client downloads the complete 'profile archive' from - the target to the host for processing. - This archive is a directory that contains the sample data, the object files - and the debug information for the object files. - The archive is then converted using the "oparchconv" script, which is - included in this distribution. - The script uses "opimport" to convert the archive from - the target to something that can be processed on the host. - </para> - - <para> - Downloaded archives reside in <filename>/tmp</filename> and are cleared up - when they are no longer in use. - </para> - - <para> - If you wish to perform kernel profiling you need to be sure - a "vmlinux" file that matches the running kernel is available. - In Poky, that file is usually located in - <filename>/boot/vmlinux-KERNELVERSION</filename>, where KERNEL-version is the - version of the kernel. - Poky generates separate vmlinux packages for each kernel - it builds so it should be a question of just making sure a matching package is - installed - for example: <filename>opkg install kernel-vmlinux</filename>. - The files are automatically installed into development and profiling images - alongside OProfile. - There is a configuration option within the OProfileUI settings page where - you can enter the location of the vmlinux file. - </para> - - <para> - Waiting for debug symbols to transfer from the device can be slow, and it - is not always necessary to actually have them on the device for OProfile use. - All that is needed is a copy of the filesystem with the debug symbols present - on the viewer system. - The "<link linkend='platdev-gdb-remotedebug-launch-gdb'>Launching GDB - on the Host Computer</link>" section covers how to create such a directory with Poky and - how to use the OProfileUI Settings dialog to specify the location. - If you specify the directory, it will be used when the file checksums - match those on the system you are profiling. - </para> - </section> - - <section id="platdev-oprofile-oprofileui-offline"> - <title>Offline Mode</title> - - <para> - If network access to the target is unavailable, you can generate - an archive for processing in "oprofile-viewer" as follows: - </para> - - <para> - <literallayout class='monospaced'> - # opcontrol --reset - # opcontrol --start --separate=lib --no-vmlinux -c 5 - [do whatever is being profiled] - # opcontrol --stop - # oparchive -o my_archive - </literallayout> - </para> - - <para> - In the above example <filename>my_archive</filename> is the name of the - archive directory where you would like the profile archive to be kept. - After the directory is created, you can copy it to another host and load it - using "oprofile-viewer" open functionality. - If necessary, the archive is converted. - </para> - </section> - </section> -</section> - - - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/examples/hello-autotools/hello_2.3.bb b/documentation/poky-ref-manual/examples/hello-autotools/hello_2.3.bb deleted file mode 100644 index 5c5332f73..000000000 --- a/documentation/poky-ref-manual/examples/hello-autotools/hello_2.3.bb +++ /dev/null @@ -1,7 +0,0 @@ -DESCRIPTION = "GNU Helloworld application" -SECTION = "examples" -LICENSE = "GPLv3" - -SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.bz2" - -inherit autotools diff --git a/documentation/poky-ref-manual/examples/hello-single/files/helloworld.c b/documentation/poky-ref-manual/examples/hello-single/files/helloworld.c deleted file mode 100644 index fc7169b7b..000000000 --- a/documentation/poky-ref-manual/examples/hello-single/files/helloworld.c +++ /dev/null @@ -1,8 +0,0 @@ -#include <stdio.h> - -int main(void) -{ - printf("Hello world!\n"); - - return 0; -} diff --git a/documentation/poky-ref-manual/examples/hello-single/hello.bb b/documentation/poky-ref-manual/examples/hello-single/hello.bb deleted file mode 100644 index d815b1ed7..000000000 --- a/documentation/poky-ref-manual/examples/hello-single/hello.bb +++ /dev/null @@ -1,16 +0,0 @@ -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} -} diff --git a/documentation/poky-ref-manual/examples/libxpm/libxpm_3.5.6.bb b/documentation/poky-ref-manual/examples/libxpm/libxpm_3.5.6.bb deleted file mode 100644 index 2710189b2..000000000 --- a/documentation/poky-ref-manual/examples/libxpm/libxpm_3.5.6.bb +++ /dev/null @@ -1,13 +0,0 @@ -require xorg-lib-common.inc - -DESCRIPTION = "X11 Pixmap library" -LICENSE = "X-BSD" -DEPENDS += "libxext" -PR = "r2" -PE = "1" - -XORG_PN = "libXpm" - -PACKAGES =+ "sxpm cxpm" -FILES_cxpm = "${bindir}/cxpm" -FILES_sxpm = "${bindir}/sxpm" diff --git a/documentation/poky-ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb b/documentation/poky-ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb deleted file mode 100644 index b21dc653a..000000000 --- a/documentation/poky-ref-manual/examples/mtd-makefile/mtd-utils_1.0.0.bb +++ /dev/null @@ -1,13 +0,0 @@ -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} -} diff --git a/documentation/poky-ref-manual/extendpoky.xml b/documentation/poky-ref-manual/extendpoky.xml deleted file mode 100644 index 5bf22e547..000000000 --- a/documentation/poky-ref-manual/extendpoky.xml +++ /dev/null @@ -1,1027 +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 chapter provides information about how to extend the functionality - already present in Poky. - The chapter also documents standard tasks such as adding new - software packages, extending or customizing images or porting Poky to - new hardware (adding a new machine). - Finally, the chapter contains advice about how to make changes to Poky to achieve the best results. - </para> - - <section id='usingpoky-extend-addpkg'> - <title>Adding a Package</title> - <para> - To add a package into Poky you need to write a recipe for it. - Writing a recipe means creating a <filename>.bb</filename> file that sets some - variables. - For information on variables that are useful for recipes and for information about recipe naming - issues, see the <link linkend='ref-varlocality-recipe-required'>Recipe Variables - Required</link> - appendix. - </para> - <para> - 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 range of packages. - Because Poky aims to be compatible with OpenEmbedded, most recipes should - simply 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. - Following are some examples showing how to add standard types of packages: - </para> - - <section id='usingpoky-extend-addpkg-singlec'> - <title>Single .c File Package (Hello World!)</title> - <para> - Building an application from a single file that is stored locally (e.g. under - <filename>files/</filename>) requires a recipe that has the file listed in - the <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable. - Additionally, you need to manually write the "do_compile" and - "do_install" tasks. - The <glossterm><link linkend='var-S'>S</link></glossterm> variable defines the - directory containing the source code, which is set to <glossterm><link linkend='var-WORKDIR'> - WORKDIR</link></glossterm> in this case - the directory BitBake uses for the build. - </para> - <programlisting> -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} -} - </programlisting> - <para> - By default, the "helloworld", "helloworld-dbg" and "helloworld-dev" - packages are built. - For information on how to customize the packaging process, see - <link linkend='usingpoky-extend-addpkg-files'>Controlling Package Content</link>. - </para> - </section> - - <section id='usingpoky-extend-addpkg-autotools'> - <title>Autotooled Package</title> - <para> - Applications that use autotools such as <filename>autoconf</filename> and - <filename>automake</filename> require a recipe that has a source archive listed in - <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> and - also inherits autotools, which instructs BitBake to use the - <filename>autotools.bbclass</filename> file, which contains the definitions of all the steps - needed to build an autotooled application. - The result of the build is automatically packaged. - And, if the application uses NLS for localization, packages with local information are - generated (one package per language). - Following is one example: (<filename>hello_2.2.bb</filename>) - </para> - <programlisting> -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 - </programlisting> - <para> - The variable <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 changes</link>. - You can quickly create autotool-based recipes in a manner similar to the previous example. - </para> - - </section> - - <section id='usingpoky-extend-addpkg-makefile'> - <title>Makefile-Based Package</title> - <para> - Applications that use GNU <filename>make</filename> also require a recipe that has - the source archive listed in <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>. - You do not need to add a "do_compile" step since by default BitBake - starts the <filename>make</filename> command to compile the application. - If you need additional <filename>make</filename> options you should store them in the - <glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></glossterm> variable. - BitBake passes these options into the <filename>make</filename> GNU invocation. - Note that a "do_install" task is still required. - Otherwise BitBake runs an empty "do_install" task by default. - </para> - <para> - Some applications might require extra parameters to be passed to the compiler. - For example the application might need an additional header path. - You can accomplish this by adding to the <glossterm><link linkend='var-CFLAGS'>CFLAGS</link> - </glossterm> variable. - The following example shows this: - </para> - <programlisting> -CFLAGS_prepend = "-I ${S}/include " - </programlisting> - <para> - In the following example <filename>mtd-utils</filename> is a makefile-based package: - </para> - <programlisting> -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 -} - </programlisting> - - </section> - - <section id='usingpoky-extend-addpkg-files'> - <title>Controlling Package Content</title> - <para> - You can use the variables <glossterm><link linkend='var-PACKAGES'>PACKAGES</link></glossterm> and - <glossterm><link linkend='var-FILES'>FILES</link></glossterm> to split an application into - multiple packages. - </para> - <para> - Following is an example that uses the "libXpm" recipe (<filename>libxpm_3.5.7.bb</filename>). - By default, the "libXpm" recipe generates a single package that contains the library along - with a few binaries. - You can modify the recipe to split the binaries into separate packages: - </para> - <programlisting> -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" - </programlisting> - <para> - In the previous 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 by default, we prepend the <glossterm><link linkend='var-PACKAGES'>PACKAGES</link> - </glossterm> variable so additional package names are added to the start of list. - This results in the extra <glossterm><link linkend='var-FILES'>FILES</link></glossterm>_* - variables then containing information that define which files and - directories go into which packages. - Files included by earlier packages are skipped by latter packages. - Thus, the main <glossterm><link linkend='var-PN'>PN</link></glossterm> package does not include - the above listed files. - </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 <filename>pkg_postinst_PACKAGENAME() - </filename> function to the <filename>.bb</filename> file and use - <filename>PACKAGENAME</filename> as the name of the package you want to attach to the - <filename>postinst</filename> script. - Normally <glossterm><link linkend='var-PN'>PN</link></glossterm> can be used, which - automatically expands to PACKAGENAME. - 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 is 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 is - executed when the image boots again. - </para> - <para> - Sometimes it is necessary for the execution of a post-installation - script to be delayed until the first boot. - For example, the script might need to be executed on the device itself. - To delay script execution until boot time, use the following structure in the - post-installation script: - </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 previous example delays execution until the image boots again 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>Customizing Images</title> - <para> - You can customize Poky images to satisfy particular requirements. - This section describes several methods and provides guidelines for each. - </para> - - <section id='usingpoky-extend-customimage-custombb'> - <title>Customizing Images Using Custom .bb Files</title> - <para> - One way to get additional software into an image is to create a custom image. - The following example shows the form for the two lines you need: - </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. - You must use the OpenEmbedded notation and not the Debian notation for the names - (e.g. "glibc-dev" instead of "libc6-dev"). - </para> - <para> - The other method for creating a custom image is to modify an existing image. - For example, if a developer wants to add "strace" into "poky-image-sato", they can use - the following recipe: - </para> - <programlisting> -require poky-image-sato.bb - -IMAGE_INSTALL += "strace" - </programlisting> - </section> - - <section id='usingpoky-extend-customimage-customtasks'> - <title>Customizing Images Using Custom Tasks</title> - <para> - For complex custom images, the best approach is to create a custom task package - that is used to build the image or images. - A good example of a tasks package is - <filename>meta/recipes-sato/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, you can use - <glossterm><link linkend='var-RDEPENDS'>RDEPENDS</link></glossterm> - and <glossterm><link linkend='var-RRECOMMENDS'>RRECOMMENDS</link></glossterm> - entries to provide a list of packages the parent task package should contain. - Following is an example: - </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 the previous example, two task packages are created with their dependencies and their - recommended package dependencies listed: <filename>task-custom-apps</filename>, and - <filename>task-custom-tools</filename>. - To build an image using these task packages, you need to add - "task-custom-apps" and/or "task-custom-tools" to <glossterm><link - linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></glossterm>. - For other forms of image dependencies see the other areas of this section. - </para> - </section> - - <section id='usingpoky-extend-customimage-imagefeatures'> - <title>Customizing Images Using Custom IMAGE_FEATURES</title> - <para> - Ultimately users might 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 features, the best reference is - <filename>meta/classes/poky-image.bbclass</filename>, which shows 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 then maps that into a set of tasks or packages. - Based on this information the <glossterm><link linkend='var-IMAGE_INSTALL'> IMAGE_INSTALL</link> - </glossterm> variable is generated automatically. - Users can add extra features by extending the class or creating a custom class for use - with specialized image <filename>.bb</filename> files. - </para> - <para> - Poky ships with two SSH servers you can use in your images: Dropbear and OpenSSH. - Dropbear is a minimal SSH server appropriate for resource-constrained environments, - while OpenSSH is a well-known standard SSH server implementation. - By default, poky-image-sato is configured to use Dropbear. - The poky-image-basic and poky-image-lsb images both include OpenSSH. - To change these defaults, edit the <filename>IMAGE_FEATURES</filename> variable - so that it sets the image you are working with to include ssh-server-dropbear - or ssh-server-openssh. - </para> - </section> - - <section id='usingpoky-extend-customimage-localconf'> - <title>Customizing Images Using local.conf</title> - <para> - It is possible to customize image contents by using variables used by distribution - maintainers in the <filename>local.conf</filename>. - This method only allows the addition of packages and is not recommended. - </para> - <para> - For example, to add the "strace" package into the image you would add this package to the - <filename>local.conf</filename> file: - </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, adding packages using this method is not as simple as adding - them using a custom <filename>.bb</filename> file. - Using the <filename>local.conf</filename> file method could result in some packages - needing to be recreated. - For example, if packages were previously created and the image was rebuilt then the packages - would need to be recreated. - </para> - <para> - Cleaning task-* packages are required because they use the - <glossterm><link linkend='var-DISTRO_EXTRA_RDEPENDS'> - DISTRO_EXTRA_RDEPENDS</link></glossterm> variable. - You do not have to build them by hand because Poky images depend on the packages they contain. - This means dependencies are automatically built when the image builds. - For this reason we don't use the "rebuild" task. - In this case the "rebuild" task does not care about - dependencies - it only rebuilds the specified package. - </para> - <programlisting> -$ bitbake -c clean task-boot task-base task-poky -$ bitbake poky-image-sato - </programlisting> - </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. - This section provides information that gives you an idea of the changes you must make. - The information covers adding machines similar to those Poky already supports. - Although well within the capabilities of Poky, adding a totally new architecture might require - changes to <filename>gcc/glibc</filename> and to the site information, which is - beyond the scope of this manual. - </para> - - <section id="platdev-newmachine-conffile"> - <title>Adding the Machine Configuration File</title> - <para> - To add a machine configuration you need to add a <filename>.conf</filename> file - with details of the device being added to the <filename>conf/machine/</filename> file. - The name of the file determines the name Poky uses to reference the new 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"). - You might also need 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"). - You can find full details on these variables in the reference section. - You can leverage many existing machine <filename>.conf</filename> files from - <filename>meta/conf/machine/</filename>. - </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. - You can find several kernel examples in the <filename>meta/recipes-kernel/linux</filename> - directory that can be used as references. - </para> - <para> - If you are creating a new recipe, the "normal" recipe-writing rules apply for setting - up a <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>. - This means specifying any necessary patches and setting <glossterm> - <link linkend='var-S'>S</link></glossterm> to point at the source code. - You need to create a "configure" task that configures the unpacked kernel with a defconfig. - You can do this by using a <filename>make defconfig</filename> command or - more commonly by copying in a suitable <filename>defconfig</filename> file and and then running - <filename>make oldconfig</filename>. - By making use of "inherit kernel" and potentially some of the - <filename>linux-*.inc</filename> files, most other functionality is - centralized and the the defaults of the class normally work well. - </para> - <para> - If you are extending an existing kernel, it is usually a matter of adding a - suitable <filename>defconfig</filename> file. - The file needs to be added into a location similar to <filename>defconfig</filename> files - used for other machines in a given kernel. - A possible way to do this is by listing the file in the - <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> - and adding the machine to the expression in - <glossterm><link linkend='var-COMPATIBLE_MACHINE'>COMPATIBLE_MACHINE</link></glossterm>: - </para> - <programlisting> -COMPATIBLE_MACHINE = '(qemux86|qemumips)' - </programlisting> - </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 information 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 - the screen resolution. - </para> - <para> - Reasonable defaults are used in most cases, but if customization is - necessary you need to create a <filename>machconfig</filename> file - under <filename>meta/packages/formfactor/files/MACHINENAME/</filename>, - where <filename>MACHINENAME</filename> is the name for which this information - applies. - For information about the settings available and the defaults, see - <filename>meta/recipes-bsp/formfactor/files/config</filename>. - Following is an example for qemuarm: - </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 id="usingpoky-changes"> - <title>Making and Maintaining Changes</title> - <para> - Because Poky is extremely configurable and flexible, we recognize that people will want - to extend, configure or optimize Poky for their specific uses. - To best keep pace with future Poky changes we recommend you make controlled changes to Poky. - </para> - <para> - Poky supports the idea of <link linkend='usingpoky-changes-layers'>"layers"</link>. - If you use layers properly you can ease future upgrades and allow segregation - between the Poky core and a given developer's changes. - The following section provides more advice on managing changes to Poky. - </para> - - <section id="usingpoky-changes-layers"> - <title>BitBake Layers</title> - <para> - Often, people want to extend Poky either by adding packages - or by 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. - </para> - <para> - The Poky tree includes several additional layers such as meta-emenlow and meta-extras - that demonstrate this functionality. - The meta-emenlow layer is an example layer that, by default, is enabled. - However, the meta-extras repository is not enabled by default. - It is easy though to enable any layer. - You simply add the layer's path to the - <glossterm><link linkend='var-BBLAYERS'>BBLAYERS</link></glossterm> variable in your - <filename>bblayers.conf</filename> file. - The following example shows how to enable meta-extras in the Poky build: - </para> - <para> - <programlisting> -LCONF_VERSION = "1" - -BBFILES ?= "" -BBLAYERS = " \ - /path/to/poky/meta \ - /path/to/poky/meta-emenlow \ - /path/to/poky/meta-extras \ - " - </programlisting> - </para> - - <para> - BitBake parses each <filename>conf/layer.conf</filename> file for each layer in BBLAYERS - and adds the recipes, classes and configuration contained within the layer to Poky. - To create your own layer, independent of the main Poky repository, - simply create a directory with a <filename>conf/layer.conf</filename> file and - add the directory to your <filename>bblayers.conf</filename> file. - </para> - <para> - The <filename>meta-emenlow/conf/layer.conf</filename> file demonstrates the required syntax: - <programlisting> -# We have a conf and classes directory, add to BBPATH -BBPATH := "${BBPATH}:${LAYERDIR}" - -# We have a recipes directory containing both .bb and .bbappend files, add to BBFILES -BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ - ${LAYERDIR}/recipes/*/*.bbappend" - -BBFILE_COLLECTIONS += "emenlow" -BBFILE_PATTERN_emenlow := "^${LAYERDIR}/" -BBFILE_PRIORITY_emenlow = "6" - </programlisting> - </para> - <para> - In the previous example, the recipes for the layers are added to - <glossterm><link linkend='var-BBFILES'>BBFILES</link></glossterm>. - The <glossterm><link linkend='var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</link></glossterm> - variable is then appended with the layer name. - The <glossterm><link linkend='var-BBFILE_PATTERN'>BBFILE_PATTERN</link></glossterm> variable - immediately expands with a regular expression used to match files from BBFILES into - a particular layer, in this case by using the base pathname. - The <glossterm><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></glossterm> variable - then assigns different priorities to the files in different layers. - Applying priorities is useful in situations where the same package might appear in multiple - layers and allows you to choose what layer should take precedence. - </para> - <para> - Note the use of the <glossterm><link linkend='var-LAYERDIR'>LAYERDIR</link></glossterm> - variable with the immediate expansion operator. - The LAYERDIR variable expands to the directory of the current layer and - requires the immediate expansion operator so that BitBake does not wait to expand the variable - when it's parsing a different directory. - </para> - <para> - BitBake can locate where other bbclass and configuration files are applied through - the <glossterm><link linkend='var-BBPATH'>BBPATH</link></glossterm> - environment variable. - For these cases, BitBake uses the first file with the matching name found in BBPATH. - This is similar to the way the PATH variable is used for binaries. - We recommend, therefore, that you use unique bbclass and configuration file names in your - custom layer. - </para> - <para> - We also recommend the following: - <itemizedlist> - <listitem><para>Store custom layers in a git repository that uses the - meta-prvt-XXXX format.</para></listitem> - <listitem><para>Clone the repository alongside other meta directories in the Poky - tree.</para></listitem> - </itemizedlist> - Following these recommendations keeps your Poky tree and its configuration entirely - inside POKYBASE. - </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. - Because some simple practices can significantly improve usability, policy for committing changes - is important. - It helps to use a consistent documentation style when committing changes. - We have found the following style works well. - </para> - <para> - Following are suggestions for committing changes to the Poky core: - </para> - - <para> - <itemizedlist> - <listitem><para>The first line of the commit summarizes the change and begins with the - name of the affected package or packages. - However, not all changes apply to specific packages. - Consequently, the prefix could also be a machine name or class name for - example.</para></listitem> - <listitem><para>The second part of the commit (if needed) is a longer more detailed - description of the changes. Placing a blank line between the first and second parts - helps with readability.</para></listitem> - </itemizedlist> - </para> - <para> - Following is an example commit: - </para> - <literallayout class='monospaced'> - bitbake/data.py: Add emit_func() and generate_dependencies() functions - - These functions allow generation of dependency data between functions 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 richard.purdie@linuxfoundation.org - </literallayout> - - <para> - All commits should be self-contained such that they leave the - metadata in a consistent state that builds both before and after the - commit is made. - Besides being a good policy to follow, this helps ensure the autobuilder test results - are valid. - </para> - </section> - - <section id="usingpoky-changes-prbump"> - <title>Package Revision Incrementing</title> - <para> - If a committed change results in changing the package output - then the value of the <glossterm><link linkend='var-PR'>PR</link> - </glossterm> variable needs to be increased (or 'bumped') as part of that commit. - This means that for new recipes you must be sure to add the PR variable and set its initial value - equal to "r0". - Failing to define PR makes it easy to miss when you bump a package. - Note that you can only use integer values following the "r" in the PR variable. - </para> - <para> - If you are sharing a common .inc file with multiple recipes, you can also use the - <glossterm><link linkend='var-INC_PR'>INC_PR</link></glossterm> variable to ensure that - the recipes sharing the .inc file are rebuilt when the .inc file itself is changed. The - .inc file must set INC_PR (initially to "r0"), and all recipes referring to it should set PR to - "$(INC_PR).0" initially, incrementing the last number when the recipe is changed. If the - .inc file is changed then its INC_PR should be incremented. - </para> - <para> - When upgrading the version of a package, assuming the <glossterm><link - linkend='var-PV'>PV</link></glossterm> changes, the PR variable should be reset to "r0" - (or "$(INC_PR).0" if you are using INC_PR). - </para> - <para> - Usually, version increases occur only to packages. - However, if for some reason PV changes but does not increase, you can increase the - <glossterm><link linkend='var-PE'>PE</link></glossterm> variable (Package Epoch). - The PE variable defaults to "0". - </para> - <para> - Version numbering strives to follow the - <ulink url='http://www.debian.org/doc/debian-policy/ch-controlfields.html'> - Debian Version Field Policy Guidelines</ulink>. - These guidelines define how versions are compared and what "increasing" a version means. - </para> - <para> - There are two reasons for following these guidelines. - First, 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. - Second, to ensure that target users are able to upgrade their - devices using package manager commands such as <filename>opkg upgrade</filename> - (or similar commands for dpkg/apt or rpm-based systems). - </para> - <para> - The goal is to ensure Poky has upgradeable packages in all cases. - </para> - </section> - - <section id="usingpoky-changes-collaborate"> - <title>Using Poky in a Team Environment</title> - <para> - It might not be immediately clear how you can use Poky in a team environment, - or scale it for a large team of developers. - The specifics of any situation determine the best solution. - Granted that Poky offers immense flexibility regarding this, practices do exist - that experience has shown work well. - </para> - <para> - The core component of any development effort with Poky is often an - automated build testing framework and an image generation process. - You can use these core components to check that the metadata can be built, - highlight when commits break the build, and provide up-to-date images that - allow people to test the end result and use it as a base platform for further - development. - Experience shows that buildbot is a good fit for this role. - What works well is to configure buildbot to make two types of builds: - incremental and full (from scratch). - See <ulink url='http://autobuilder.pokylinux.org:8010'>poky autobuilder</ulink> - for an example implementation that uses buildbot. - </para> - <para> - You can tie incremental builds to a commit hook that triggers the build - each time a commit is made to the metadata. - This practice results in useful acid tests that determine whether a given commit - breaks the build in some serious way. - Associating a build to a commit can catch a lot of simple errors. - Furthermore, the tests are fast so developers can get quick feedback on changes. - </para> - <para> - Full builds build and test everything from the ground up. - They usually happen at predetermined times like during the night when the machine - load is low. - </para> - <para> - Most teams have many pieces of software undergoing active development at any given time. - You can derive large benefits by putting these pieces under the control of a source - control system that is compatible with Poky (i.e. git or svn). - You can then set the autobuilder to pull the latest revisions of the packages - and test the latest commits by the builds. - This practice quickly highlights issues. - Poky easily supports testing configurations that use both a stable known good revision - and a floating revision. - Poky can also take just the changes from specific source control branches. - This capability allows you to track and test specific changes. - </para> - <para> - Perhaps the hardest part of setting this up is defining the software project or - Poky metadata policies that surround the different source control systems. - Of course circumstances will be different in each case. - However, this situation reveals one of Poky's advantages - the system itself does not - force any particular policy on users, unlike a lot of build systems. - The system allows the best policies to be chosen for the given circumstances. - </para> - </section> - - <section id="usingpoky-changes-updatingimages"> - <title>Updating Existing Images</title> - <para> - Often, rather than re-flashing a new image you might wish to install updated - packages into an existing running system. - You can do this by first sharing the - <filename class="directory">tmp/deploy/ipk/</filename> directory - through a web server and then by changing <filename>/etc/opkg/base-feeds.conf</filename> - to point at the shared server. - Following is an example: - </para> - <literallayout class='monospaced'> - 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 - </literallayout> - </section> - </section> - - <section id="usingpoky-modifing-packages"> - <title>Modifying Package Source Code</title> - <para> - Although Poky is usually used to build software, you can use it to modify software. - </para> - <para> - During a build, source is available in the - <glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm> directory. - The actual location depends on the type of package and the architecture of the target device. - For a standard recipe not related to - <glossterm><link linkend='var-MACHINE'>MACHINE</link></glossterm> the location is - <filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>. - For target device-dependent packages you should use the <filename>MACHINE</filename> - variable instead of - <glossterm><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></glossterm> - in the directory name. - </para> - <tip> - <para> - Be sure the package recipe sets the - <glossterm><link linkend='var-S'>S</link></glossterm> variable to something - other than the standard <filename>WORKDIR/PN-PV/</filename> value. - </para> - </tip> - <para> - After building a package, you can modify the package source code without problems. - The easiest way to test your changes is by calling the "compile" task as shown in the - following example: - </para> - - <literallayout class='monospaced'> - $ bitbake -c compile -f NAME_OF_PACKAGE - </literallayout> - - <para> - The "-f" or "--force" option forces re-execution of the specified task. - You can call other tasks this way as well. - But note that all the modifications in - <glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm> - are gone once you execute "-c clean" for a package. - </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 the "do_patch" task. - This is a powerful tool that you can use to track all modifications to package sources. - </para> - <para> - Before modifying source code, it is important to notify quilt so it can track the changes - into the new patch file: - - <literallayout class='monospaced'> - quilt new NAME-OF-PATCH.patch - </literallayout> - - After notifying quilt, add all modified files into that patch: - <literallayout class='monospaced'> - quilt add file1 file2 file3 - </literallayout> - - You can now start editing. - Once you are done editing, you need to use quilt to generate the final patch that - will contain all your modifications. - <literallayout class='monospaced'> - quilt refresh - </literallayout> - - You can find the resulting patch file in the - <filename>patches/</filename> subdirectory of the source - (<glossterm><link linkend='var-S'>S</link></glossterm>) directory. - For future builds you should copy the patch into Poky metadata and add it into the - <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> of a recipe. - Here is an example: - <programlisting> -SRC_URI += "file://NAME-OF-PATCH.patch" - </programlisting> - Finally, don't forget to 'bump' the - <glossterm><link linkend='var-PR'>PR</link></glossterm> value in the same recipe since - the resulting packages have changed. - </para> - </section> - - </section> - - <section id="usingpoky-configuring-LIC_FILES_CHKSUM"> - <title>Track License Change</title> - <para> - The license of an upstream project might change in the future. - Poky uses the <glossterm><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></glossterm> variable - to track license changes. - </para> - - <section id="usingpoky-specifying-LIC_FILES_CHKSUM"> - <title>Specifying the LIC_FILES_CHKSUM Variable</title> - <para> - The <glossterm><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></glossterm> - variable contains checksums of the license text in the recipe source code. - Poky uses this to track changes in the license text of the source code files. - Following is an example of LIC_FILES_CHKSUM: - </para> - <programlisting> -LIC_FILES_CHKSUM = "file://COPYING; md5=xxxx \ - file://licfile1.txt; beginline=5; endline=29;md5=yyyy \ - file://licfile2.txt; endline=50;md5=zzzz \ - ..." - </programlisting> - <para> - Poky uses the <glossterm><link linkend='var-S'>S</link></glossterm> variable as the - default directory used when searching files listed in LIC_FILES_CHKSUM. - The previous example employs the default directory. - </para> - <para> - You can also use relative paths as shown in the following example: - </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> - In this example the first line locates a file in - <glossterm><link linkend='var-S'>S</link></glossterm><filename>/src/ls.c</filename>. - 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 id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax"> - <title>Explanation of Syntax</title> - <para> - As mentioned in the previous section the LIC_FILES_CHKSUM variable lists all the - important files that contain the license text for the source code. - Using this variable you can specify the line on which the license text starts and ends - by supplying "beginline" and "endline" parameters. - If you do not use the "beginline" parameter then it is assumed that the text begins on the - first line of the file. - Similarly, if you do not use the "endline" parameter it is assumed that the license text - ends as the last line of the file. - </para> - <para> - The "md5" parameter stores the md5 checksum of the license text. - If the license text changes in any way as compared to this parameter - then a mis-match occurs. - This mismatch triggers a build failure and notifies the developer. - Notification allows the developer to review and address the license text changes. - Also note that if a mis-match occurs during the build, the correct md5 - checksum is placed in the build log and can be easily copied to a .bb file. - </para> - <para> - There is no limit to how many files you can specify using the LIC_FILES_CHKSUM variable. - Generally, however, every project requires a few specifications for license tracking. - Many projects have a "COPYING" file that stores the license information for all the source - code files. - This practice allow you to just track the "COPYING" file as long as it is kept up to date. - </para> - <tip> - If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match - error and displays the correct "md5" parameter value during the build. The correct parameter - is also captured in the build log. - </tip> - <tip> - If the whole file contains only license text, you do not need to use the "beginline" and - "endline" parameters. - </tip> - </section> - </section> - - <section id="usingpoky-configuring-DISTRO_PN_ALIAS"> - <title>Handling Package Name Alias</title> - <para> - Sometimes a package name you are using might exist under an alias or as a similarly named - package in a different distribution. - Poky implements a "distro_check" task that automatically connects to major distributions - and checks for these situations. - If the package exists under a different name in a different distribution you get a - distro_check mismatch. - You can resolve this problem by defining a per-distro recipe name alias using the - <glossterm><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></glossterm> variable. - </para> - - <section id="usingpoky-specifying-DISTRO_PN_ALIAS"> - <title>Specifying the DISTRO_PN_ALIAS Variable</title> - <para> - Following is an example that shows how you specify the DISTRO_PN_ALIAS variable: - <programlisting> -DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \ - distro2=package_name_alias2 \ - distro3=package_name_alias3 \ - ..." - </programlisting> - </para> - <para> - If you have more than one distribution alias, separate them with a space. - Note that Poky currently automatically checks the Fedora, OpenSuSE, Debian, Ubuntu, - and Mandriva distributions for source package recipes without having to specify them - using the DISTRO_PN_ALIAS variable. - For example, the following command generates a report that lists the Linux distributions - that include the sources for each of the Poky recipes. - <literallayout class='monospaced'> - $ bitbake world -f -c distro_check - </literallayout> - The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename> - file. - </para> - </section> - </section> -</chapter> - -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/faq.xml b/documentation/poky-ref-manual/faq.xml deleted file mode 100644 index f4b5ae0fd..000000000 --- a/documentation/poky-ref-manual/faq.xml +++ /dev/null @@ -1,520 +0,0 @@ -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<appendix id='faq'> -<title>FAQ</title> -<qandaset> - <qandaentry> - <question> - <para> - How does Poky differ from <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>? - </para> - </question> - <answer> - <para> - Poky is a derivative of <ulink - url='http://www.openembedded.org/'>OpenEmbedded</ulink>, a stable, - smaller subset focused on the GNOME Mobile environment. Development - in Poky is closely tied to OpenEmbedded with features being merged - regularly between the two for mutual benefit. - </para> - </answer> - </qandaentry> - - - - - - <qandaentry> - <question> - <para> - I only have Python 2.4 or 2.5 but BitBake requires Python 2.6. - Can I still use Poky? - </para> - </question> - <answer> - <para> - You can use a stand-alone tarball to provide Python 2.6. - You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations: - <itemizedlist> - <listitem><para><ulink url='http://autobuilder.yoctoproject.org/downloads/miscsupport/python-nativesdk-standalone-i586.tar.bz2'></ulink></para></listitem> - <listitem><para><ulink url='http://autobuilder.yoctoproject.org/downloads/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2'></ulink></para></listitem> - </itemizedlist> - </para> - <para> - These tarballs are self-contained with all required libraries and should work - on most Linux systems. - To use the tarballs extract them into the root - directory and run the appropriate command: - <literallayout class='monospaced'> - $ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH - $ export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH - </literallayout> - </para> - <para> - Once you run the command, BitBake uses Python 2.6. - </para> - </answer> - </qandaentry> - - - - - - <qandaentry> - <question> - <para> - How can you claim Poky is stable? - </para> - </question> - <answer> - <para> - There are three areas that help with stability; - - <itemizedlist> - <listitem> - <para> - We keep Poky small and focused - around 650 packages compared to over 5000 for full OE - </para> - </listitem> - <listitem> - <para> - We only support hardware that we have access to for testing - </para> - </listitem> - <listitem> - <para> - We have an autobuilder which provides continuous build and integration tests - </para> - </listitem> - </itemizedlist> - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - How do I get support for my board added to Poky? - </para> - </question> - <answer> - <para> - There are two main ways to get a board supported in Poky; - <itemizedlist> - <listitem> - <para> - Send us the board if we don't have it yet - </para> - </listitem> - <listitem> - <para> - Send us BitBake recipes if you have them (see the Poky handbook to find out how to create recipes) - </para> - </listitem> - </itemizedlist> - Usually if it's not a completely exotic board then adding support in Poky should be fairly straightforward. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - Are there any products running poky ? - </para> - </question> - <answer> - <para> - The <ulink url='http://vernier.com/labquest/'>Vernier Labquest</ulink> is using Poky (for more about the Labquest see the case study at OpenedHand). There are a number of pre-production devices using Poky and we will announce those as soon as they are released. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - What is the Poky output ? - </para> - </question> - <answer> - <para> - The output of a Poky build will depend on how it was started, as the same set of recipes can be used to output various formats. Usually the output is a flashable image ready for the target device. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - How do I add my package to Poky? - </para> - </question> - <answer> - <para> - To add a package you need to create a BitBake recipe - see the Poky handbook to find out how to create a recipe. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - Do I have to reflash my entire board with a new poky image when recompiling a package? - </para> - </question> - <answer> - <para> - Poky can build packages in various formats, ipk (for ipkg/opkg), Debian package (.deb), or RPM. The packages can then be upgraded using the package tools on the device, much like on a desktop distribution like Ubuntu or Fedora. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - What is GNOME Mobile? What's the difference between GNOME Mobile and GNOME? - </para> - </question> - <answer> - <para> - <ulink url='http://www.gnome.org/mobile/'>GNOME Mobile</ulink> is a subset of the GNOME platform targeted at mobile and embedded devices. The the main difference between GNOME Mobile and standard GNOME is that desktop-orientated libraries have been removed, along with deprecated libraries, creating a much smaller footprint. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - I see the error 'chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x'. What's wrong? - </para> - </question> - <answer> - <para> - You're probably running the build on an NTFS filesystem. Use a sane one like ext2/3/4 instead! - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - How do I make Poky work in RHEL/CentOS? - </para> - </question> - <answer> - <para> - To get Poky working under RHEL/CentOS 5.1 you need to first install some required packages. The standard CentOS packages needed are: - <itemizedlist> - <listitem> - <para> - "Development tools" (selected during installation) - </para> - </listitem> - <listitem> - <para> - texi2html - </para> - </listitem> - <listitem> - <para> - compat-gcc-34 - </para> - </listitem> - </itemizedlist> - </para> - - <para> - On top of those the following external packages are needed: - <itemizedlist> - <listitem> - <para> - python-sqlite2 from <ulink - url='http://dag.wieers.com/rpm/packages/python-sqlite2/'>DAG - repository</ulink> - </para> - </listitem> - <listitem> - <para> - help2man from <ulink - url='http://centos.karan.org/el5/extras/testing/i386/RPMS/help2man-1.33.1-2.noarch.rpm'>Karan - repository</ulink> - </para> - </listitem> - </itemizedlist> - </para> - - <para> - Once these packages are installed Poky will be able to build standard images however there - may be a problem with QEMU segfaulting. You can either disable the generation of binary - locales by setting <glossterm><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link> - </glossterm> to "0" or remove the linux-2.6-execshield.patch from the kernel and rebuild - it since its that patch which causes the problems with QEMU. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - I see lots of 404 responses for files on - http://autobuilder.yoctoproject.org/sources/*. Is something wrong? - </para> - </question> - <answer> - <para> - Nothing is wrong, Poky will check any configured source mirrors before downloading - from the upstream sources. It does this searching for both source archives and - pre-checked out versions of SCM managed software. This is so in large installations, - it can reduce load on the SCM servers themselves. The address above is one of the - default mirrors configured into standard Poky so if an upstream source disappears, - we can place sources there so builds continue to work. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - I have a machine specific data in a package for one machine only but the package is - being marked as machine specific in all cases, how do I stop it? - </para> - </question> - <answer> - <para> - Set <glossterm><link linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link> - </glossterm> = "0" in the .bb file but make sure the package is manually marked as - machine specific in the case that needs it. The code which handles <glossterm><link - linkend='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'>SRC_URI_OVERRIDES_PACKAGE_ARCH</link></glossterm> - is in base.bbclass. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - I'm behind a firewall and need to use a proxy server. How do I do that? - </para> - </question> - <answer> - <para> - Most source fetching by Poky is done by wget and you therefore need to specify the proxy - settings in a .wgetrc file in your home directory. Example settings in that file would be - 'http_proxy = http://proxy.yoyodyne.com:18023/' and 'ftp_proxy = http://proxy.yoyodyne.com:18023/'. - Poky also includes a site.conf.sample file which shows how to configure cvs and git proxy servers - if needed. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - I'm using Ubuntu Intrepid and am seeing build failures. Whats wrong? - </para> - </question> - <answer> - <para> - In Intrepid, Ubuntu turned on by default normally optional compile-time security features - and warnings. There are more details at <ulink - url='https://wiki.ubuntu.com/CompilerFlags'>https://wiki.ubuntu.com/CompilerFlags</ulink>. - You can work around this problem by disabling those options by adding " -Wno-format-security -U_FORTIFY_SOURCE" - to the BUILD_CPPFLAGS variable in conf/bitbake.conf. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - Whats the difference between foo and foo-native? - </para> - </question> - <answer> - <para> - The *-native targets are designed to run on the system the build is running on. These are usually tools that are needed to assist the build in some way such as quilt-native which is used to apply patches. The non-native version is the one that would run on the target device. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - I'm seeing random build failures. Help?! - </para> - </question> - <answer> - <para> - If the same build is failing in totally different and random ways the most likely explanation is that either the hardware you're running it on has some problem or if you are running it under virtualisation, the virtualisation probably has bugs. Poky processes a massive amount of data causing lots of network, disk and cpu activity and is sensitive to even single bit failure in any of these areas. Totally random failures have always been traced back to hardware or virtualisation issues. - </para> - </answer> - </qandaentry> - <qandaentry> - <question> - <para> - What do we need to ship for license compliance? - </para> - </question> - <answer> - <para> - This is a difficult question and you need to consult your lawyer for the answer for your specific case. Its worth bearing in mind that for GPL compliance there needs to be enough information shipped to allow someone else to rebuild the same end result as you are shipping. This means sharing the source code, any patches applied to it but also any configuration information about how that package was configured and built. - </para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para> - How do I disable the cursor on my touchscreen device? - </para> - </question> - <answer> - <para> - You need to create a form factor file as described in - <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref> - and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one. - <literallayout class='monospaced'> - HAVE_TOUCHSCREEN=1 - </literallayout> - </para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para> - How do I make sure connected network interfaces are brought up by default? - </para> - </question> - <answer> - <para> - The default interfaces file provided by the netbase recipe does not - automatically bring up network interfaces. - Therefore you will need to add a BSP-specific netbase that includes an interfaces - file. - See <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref> - for information on creating these types of miscellaneous recipe files. - </para> - <para> - For example, add the following files to your layer: - <literallayout class='monospaced'> - meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces - meta-MACHINE/recipes-bsp/netbase/netbase_4.44.bbappend - </literallayout> - </para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para> - How do I create images with more free space? - </para> - </question> - <answer> - <para> - Images are created to be 1.2 times the size of the populated root filesystem. - To modify this ratio so that there is more free space available you need to - set the configuration value <filename>IMAGE_OVERHEAD_FACTOR</filename>. - For example, setting <filename>IMAGE_OVERHEAD_FACTOR</filename> to 1.5 sets - the image size ratio to one and a half times the size of the populated - root filesystem. - <literallayout class='monospaced'> - IMAGE_OVERHEAD_FACTOR = "1.5" - </literallayout> - </para> - </answer> - </qandaentry> - - <qandaentry> - <question> - <para> - How does Poky obtain source code and will it work behind my firewall or proxy server? - </para> - </question> - <answer> - <para> - The way Poky obtains source code is highly configurable. - You can setup Poky to get source code in most environmnents if - HTTP transport is available. - </para> - <para> - When Poky searches for source code it first tries the local download directory. - If that location fails, Poky tries PREMIRRORS, the upstream source, - and then MIRRORS in that order. - </para> - <para> - By default, Poky uses the Yocto Project source PREMIRRORS for SCM-based sources, - upstreams for normal tarballs and then falls back to a number of other mirrors - including the Yocto Project source mirror if those fail. - </para> - <para> - As an example, you could add a specific server for Poky to attempt before any - others by adding something like the following to the <filename>local.conf</filename> - configuration file: - <literallayout class='monospaced'> - PREMIRRORS_prepend = "\ - git://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \ - ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \ - http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \ - https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n" - </literallayout> - </para> - <para> - These changes cause Poky to intercept GIT, FTP, HTTP, and HTTPS - requests and direct them to the <filename>http://</filename> sources mirror. - You can use <filename>file://</filename> urls to point to local directories - or network shares as well. - </para> - <para> - Aside from the previous technique, these options also exist: - <literallayout class='monospaced'> - BB_NO_NETWORK = "1" - </literallayout> - </para> - <para> - This statement tells BitBake to throw an error instead of trying to access the - Internet. - This technique is useful if you want to ensure code builds only from local sources. - </para> - <para> - Here is another technique: - <literallayout class='monospaced'> - BB_FETCH_PREMIRRORONLY = "1" - </literallayout> - </para> - <para> - This statement limits Poky to pulling source from the PREMIRRORS only. - Again, this technique is useful for reproducing builds. - </para> - <para> - Here is another technique: - <literallayout class='monospaced'> - BB_GENERATE_MIRROR_TARBALLS = "1" - </literallayout> - </para> - <para> - This statement tells Poky to generate mirror tarballs. - This technique is useful if you want to create a mirror server. - If not, however, the technique can simply waste time during the build. - </para> - <para> - Finally, consider an example where you are behind an HTTP-only firewall. - You could make the following changes to the <filename>local.conf</filename> - configuration file as long as the premirror server is up to date: - <literallayout class='monospaced'> - PREMIRRORS_prepend = "\ - ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \ - http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \ - https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n" - BB_FETCH_PREMIRRORONLY = "1" - </literallayout> - </para> - <para> - These changes would cause Poky to successfully fetch source over HTTP and - any network accesses to anything other than the premirror would fail. - </para> - <para> - Poky also honors the standard environment variables - <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, - <filename>https_proxy</filename>, and <filename>all_proxy</filename> - to redirect requests through proxy servers. - </para> - </answer> - </qandaentry> - - - -</qandaset> -</appendix> -<!-- -vim: expandtab tw=80 ts=4 ---> - diff --git a/documentation/poky-ref-manual/figures/cropped-yocto-project-bw.png b/documentation/poky-ref-manual/figures/cropped-yocto-project-bw.png Binary files differdeleted file mode 100755 index 561333b14..000000000 --- a/documentation/poky-ref-manual/figures/cropped-yocto-project-bw.png +++ /dev/null diff --git a/documentation/poky-ref-manual/figures/poky-ref-manual.png b/documentation/poky-ref-manual/figures/poky-ref-manual.png Binary files differdeleted file mode 100644 index 333442e0d..000000000 --- a/documentation/poky-ref-manual/figures/poky-ref-manual.png +++ /dev/null diff --git a/documentation/poky-ref-manual/figures/yocto-project-transp.png b/documentation/poky-ref-manual/figures/yocto-project-transp.png Binary files differdeleted file mode 100755 index 31d2b147f..000000000 --- a/documentation/poky-ref-manual/figures/yocto-project-transp.png +++ /dev/null diff --git a/documentation/poky-ref-manual/introduction.xml b/documentation/poky-ref-manual/introduction.xml deleted file mode 100644 index 90eaf014c..000000000 --- a/documentation/poky-ref-manual/introduction.xml +++ /dev/null @@ -1,171 +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='intro'> -<title>Introduction</title> - -<section id='intro-welcome'> - <title>Welcome to Poky!</title> - - <para> - Poky is the build tool in the Yocto Project. - The Yocto Project uses Poky to build images (kernel, system, and application software) for - targeted hardware. - </para> - - <para> - Before diving into Poky, it helps to have an understanding of the Yocto Project. - Especially useful for newcomers is the information in the Yocto Project Quick Start, which - you can find on the <ulink url="http://www.yoctoproject.org">Yocto Project website</ulink>. - Specifically, the guide is - at <ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html"/>. - </para> -</section> - -<section id='what-is-poky'> - <title>What is Poky?</title> - - <para> - Within the Yocto Project, Poky provides an open source, full-platform build tool based on - Linux, X11, Matchbox, GTK+, Pimlico, Clutter, - and other <ulink url='http://gnome.org/mobile'>GNOME Mobile</ulink> technologies. - It provides a focused and stable subset of OpenEmbedded upon which you can easily and - reliably build and develop. - Poky fully supports a wide range of x86, ARM, MIPS and PowerPC hardware and device virtualization. - </para> - - <para> - Poky is primarily a platform builder that generates filesystem images - based on open source software such as the Kdrive X server, the Matchbox - window manager, the GTK+ toolkit and the D-Bus message bus system. While images - for many kinds of devices can be generated, the standard example - machines target QEMU full-system emulation (x86, ARM, MIPS and PowerPC) and - real reference boards for each of these architectures. - Poky's ability to boot inside a QEMU - emulator makes it particularly suitable as a test platform for developing embedded software. - </para> - - <para> - An important component integrated within Poky is Sato, a GNOME Mobile-based - user interface environment. - It is designed to work well with screens that use very high DPI and have restricted - sizes, such as those often found on smartphones and PDAs. - Because Sato is coded for speed and efficiency, it works smoothly on hand-held and - other embedded hardware. - It sits nicely on top of any device that uses the GNOME Mobile stack and it results in - a well-defined user experience. - </para> - - <screenshot> - <mediaobject> - <imageobject> - <imagedata fileref="screenshots/ss-sato.png" format="PNG" align='center' scalefit='1' width="100%" contentdepth="100%"/> - </imageobject> - <caption> - <para>The Sato Desktop - A screenshot from a machine running a Poky built image</para> - </caption> - </mediaobject> - </screenshot> - - <para> - Poky has a growing open source community and is also backed up by commercial organizations - including Intel® Corporation. - </para> -</section> - -<section id='intro-manualoverview'> - <title>Documentation Overview</title> - <para> - The sections in this reference manual describe different aspects of Poky. - The <link linkend='usingpoky'>'Using Poky'</link> section provides an overview of the components - that make up Poky followed by information about using Poky and debugging images created in - the Yocto Project. - The <link linkend='extendpoky'>'Extending Poky'</link> and - <link linkend='bsp'>'Board Support Packages'</link> sections provide information - about how to extend and customize Poky along with advice on how to manage these changes. - The <link linkend='platdev'>'Platform Development with Poky'</link> section provides information about - interaction between Poky and target hardware for common platform development tasks such as software - development, debugging and profiling. - The rest of the manual consists of several reference sections, each providing details on a specific - area of Poky functionality. - </para> - - <para> - This manual applies to Poky Release 5.0 (Bernard). - </para> -</section> - - -<section id='intro-requirements'> - <title>System Requirements</title> - <para> - Although we recommend Debian-based distributions - (Ubuntu 10.04 or newer) as the host system for Poky, nothing in Poky is - distribution-specific. Consequently, other distributions should work as long - as the appropriate prerequisites are installed. For example, we know of Poky being used - successfully on Redhat, SUSE, Gentoo and Slackware host systems. - For information on what you need to develop images using Yocto Project and Poky, - you should see the Yocto Project Quick Start on the <ulink url="http://www.yoctoproject.org"> - Yocto Project website</ulink>. - The direct link to the quick start is - <ulink url='http://yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html'/>. - </para> -</section> - -<section id='intro-getit'> - <title>Obtaining Poky</title> - - <section id='intro-getit-releases'> - <title>Releases</title> - - <para>Periodically, we make releases of Poky available - at <ulink url='http://yoctoproject.org/downloads/poky/'/>. - These releases are more stable and more rigorously tested than the nightly development images. - </para> - </section> - - <section id='intro-getit-nightly'> - <title>Nightly Builds</title> - - <para> - We make nightly builds of Poky for testing purposes and to make the - latest developments available. The output from these builds is available - at <ulink url='http://autobuilder.yoctoproject.org/'/>. - The numbers used in the builds increase for each subsequent build and can be used to - reference a specific build. - </para> - - <para> - Automated builds are available for "standard" Poky and for Poky SDKs and toolchains. - Additionally, testing versions such as poky-bleeding can be made available as - 'experimental' builds. - The toolchains can - be used either as external standalone toolchains or can be combined with Poky as a - pre-built toolchain to reduce build time. Using the external toolchains is simply a - case of untarring the tarball into the root of your system (it only creates files in - <filename>/opt/poky</filename>) and then enabling the option - in <filename>local.conf</filename>. - </para> - </section> - - <section id='intro-getit-dev'> - <title>Development Checkouts</title> - - <para> - Poky is available from our git repository located at - git://git.yoctoproject.org/poky.git; a web interface to the repository - can be accessed at <ulink url='http://git.yoctoproject.org/'/>. - </para> - - <para> - The 'master' is where the development work takes place and you should use this if you're - interested in working with the latest cutting-edge developments. It is possible for the trunk - to suffer temporary periods of instability while new features are developed. - If these periods of instability are undesirable, we recommend using one of the release branches. - </para> - </section> -</section> -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/poky-beaver.png b/documentation/poky-ref-manual/poky-beaver.png Binary files differdeleted file mode 100644 index 9f9e6cf99..000000000 --- a/documentation/poky-ref-manual/poky-beaver.png +++ /dev/null diff --git a/documentation/poky-ref-manual/poky-logo.svg b/documentation/poky-ref-manual/poky-logo.svg deleted file mode 100644 index d0be40287..000000000 --- a/documentation/poky-ref-manual/poky-logo.svg +++ /dev/null @@ -1,117 +0,0 @@ -<?xml version="1.0" encoding="utf-8"?>
-<!-- Generator: Adobe Illustrator 13.0.0, SVG Export Plug-In -->
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" [
- <!ENTITY ns_flows "http://ns.adobe.com/Flows/1.0/">
-]>
-<svg version="1.1"
- xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:a="http://ns.adobe.com/AdobeSVGViewerExtensions/3.0/"
- x="0px" y="0px" width="300px" height="300px" viewBox="-40.981 -92.592 300 300" enable-background="new -40.981 -92.592 300 300"
- xml:space="preserve">
-<defs>
-</defs>
-<path fill="#6AC7BD" d="M48.96,48.476v0.003h0.001v-0.061C48.962,48.438,48.96,48.457,48.96,48.476z"/>
-<g opacity="0.65">
- <g>
- <path fill="#EF412A" d="M24.482,23.998v-0.003C10.961,23.994,0,34.955,0,48.476l0.001,0.003v0.003
- C0.003,62.001,10.962,72.96,24.482,72.96l0,0H0v24.482h0.003c13.52-0.002,24.479-10.962,24.479-24.481h0.003
- C38.005,72.959,48.963,62,48.963,48.479v-0.003C48.962,34.957,38.001,23.998,24.482,23.998z M24.482,50.928
- c-1.352,0-2.448-1.096-2.448-2.448s1.096-2.448,2.448-2.448s2.448,1.096,2.448,2.448S25.834,50.928,24.482,50.928z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#A9C542" d="M119.96,48.842c0.064-1.294,1.126-2.326,2.437-2.326c1.31,0,2.371,1.032,2.436,2.327
- c12.378-1.223,22.046-11.662,22.046-24.36h-24.482C122.396,10.961,111.435,0,97.915,0v24.485
- C97.917,37.183,107.584,47.619,119.96,48.842z M124.833,49.084c-0.064,1.295-1.126,2.327-2.436,2.327h-0.001v22.033h24.482v-0.003
- C146.876,60.745,137.208,50.308,124.833,49.084z M119.949,48.963H97.915v24.479h0c12.698,0,23.137-9.668,24.36-22.043
- C120.981,51.334,119.949,50.274,119.949,48.963z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#F9C759" d="M168.912,48.967c0-1.311,1.033-2.371,2.328-2.436c-1.222-12.379-11.661-22.049-24.361-22.049v24.481
- c0,13.521,10.961,24.481,24.482,24.481v-22.03C170.007,51.415,168.912,50.319,168.912,48.967z M195.841,48.978
- c0-0.005,0.001-0.009,0.001-0.014V24.482h-0.004c-12.698,0.002-23.136,9.672-24.356,22.049c1.294,0.064,2.326,1.125,2.326,2.436
- s-1.032,2.372-2.327,2.436c1.198,12.187,11.333,21.743,23.763,22.042h-23.883v24.482h0.003
- c13.515-0.002,24.47-10.954,24.478-24.467h0.002V48.979L195.841,48.978z M195.832,48.964h0.01v0.014L195.832,48.964z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#6AC7BD" d="M70.994,48.479H48.962v0.002h22.033C70.995,48.481,70.994,48.48,70.994,48.479z M73.44,24.001h-0.003
- v22.031c0.002,0,0.003,0,0.005,0c1.352,0,2.448,1.096,2.448,2.448s-1.096,2.448-2.448,2.448c-1.351,0-2.446-1.094-2.448-2.445
- H48.958v0.003c0.002,13.519,10.961,24.478,24.479,24.478s24.477-10.959,24.479-24.478v-0.003
- C97.916,34.963,86.958,24.003,73.44,24.001z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#EF412A" d="M24.482,23.998v-0.003C10.961,23.994,0,34.955,0,48.476h22.034c0.002-1.351,1.097-2.445,2.448-2.445
- c1.352,0,2.448,1.096,2.448,2.448s-1.096,2.448-2.448,2.448v22.01C24.469,59.427,13.514,48.479,0,48.479V72.96h24.481l0,0H0
- v24.482h0.003c13.52-0.002,24.479-10.962,24.479-24.481h0.003C38.005,72.959,48.963,62,48.963,48.479v-0.003
- C48.962,34.957,38.001,23.998,24.482,23.998z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#A9C542" d="M122.397,46.516c1.31,0,2.371,1.032,2.436,2.327c12.378-1.223,22.046-11.662,22.046-24.36h-24.482
- L122.397,46.516L122.397,46.516z M97.915,0v24.482h24.481C122.396,10.961,111.435,0,97.915,0z M122.275,46.528
- c-1.223-12.377-11.662-22.046-24.361-22.046v24.482h0v24.479h0c12.698,0,23.137-9.668,24.36-22.043
- c-1.294-0.065-2.326-1.125-2.326-2.436C119.949,47.653,120.98,46.593,122.275,46.528z M124.833,49.084
- c-0.064,1.295-1.126,2.327-2.436,2.327h-0.001v22.033h24.482v-0.003C146.876,60.745,137.208,50.308,124.833,49.084z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#F9C759" d="M173.795,49.1c-0.071,1.289-1.129,2.315-2.435,2.315c-1.354,0-2.449-1.096-2.449-2.448
- c0-1.311,1.033-2.371,2.328-2.436c-1.222-12.379-11.661-22.049-24.361-22.049v24.481c0,13.521,10.961,24.481,24.482,24.481v24.482
- h0.003c13.515-0.002,24.47-10.954,24.478-24.467h0.001v-0.016h-0.001C195.833,60.753,186.167,50.322,173.795,49.1z
- M195.838,24.482c-12.698,0.002-23.136,9.672-24.356,22.049c1.293,0.064,2.324,1.124,2.326,2.433h22.033v0.015
- c0-0.005,0.001-0.01,0.001-0.015V24.482H195.838z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#6AC7BD" d="M71.007,48.347c0.068-1.242,1.055-2.23,2.297-2.301c-0.795-8.026-5.454-14.913-12.103-18.762
- C57.601,25.2,53.424,24,48.965,24h-0.003c0,4.46,1.199,8.638,3.283,12.24C56.093,42.891,62.98,47.552,71.007,48.347z
- M48.962,48.418c0,0.02-0.001,0.038-0.001,0.058v0.003h0.001V48.418z M70.995,48.482c0-0.001,0-0.001,0-0.002H48.962v0.002H70.995
- z M73.44,24.001h-0.003v22.031c0.002,0,0.003,0,0.005,0c1.352,0,2.448,1.096,2.448,2.448s-1.096,2.448-2.448,2.448
- c-1.351,0-2.446-1.094-2.448-2.445H48.958v0.003c0.002,13.519,10.961,24.478,24.479,24.478s24.477-10.959,24.479-24.478v-0.003
- C97.916,34.963,86.958,24.003,73.44,24.001z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#EF412A" d="M24.482,23.998v-0.003C10.961,23.994,0,34.955,0,48.476h22.034c0.002-1.351,1.097-2.445,2.448-2.445
- c1.352,0,2.448,1.096,2.448,2.448s-1.096,2.448-2.448,2.448c-1.311,0-2.372-1.033-2.436-2.327
- C9.669,49.824,0.001,60.262,0.001,72.96H0v24.482h0.003c13.52-0.002,24.479-10.962,24.479-24.481h0.003
- C38.005,72.959,48.963,62,48.963,48.479v-0.003C48.962,34.957,38.001,23.998,24.482,23.998z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#A9C542" d="M119.949,48.963c0-1.352,1.096-2.448,2.448-2.448c1.31,0,2.371,1.032,2.436,2.327
- c12.378-1.223,22.046-11.662,22.046-24.36h-24.482C122.396,10.961,111.435,0,97.915,0v24.482h24.479
- c-13.52,0.002-24.478,10.962-24.478,24.481h0v24.479h0c12.698,0,23.137-9.668,24.36-22.043
- C120.981,51.334,119.949,50.274,119.949,48.963z M124.833,49.084c-0.064,1.295-1.126,2.327-2.436,2.327h-0.001v22.033h24.482
- v-0.003C146.876,60.745,137.208,50.308,124.833,49.084z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#F9C759" d="M195.841,48.979l-0.006-0.015h0.006V48.979c0-0.005,0.001-0.01,0.001-0.015V24.482h-0.004
- c-12.698,0.002-23.136,9.672-24.356,22.049c1.294,0.064,2.326,1.125,2.326,2.436c0,1.352-1.096,2.448-2.447,2.448
- c-1.354,0-2.449-1.096-2.449-2.448c0-1.311,1.033-2.371,2.328-2.436c-1.222-12.379-11.661-22.049-24.361-22.049v24.481
- c0,13.521,10.961,24.481,24.482,24.481v24.482h0.003c13.519-0.002,24.479-10.963,24.479-24.482h-23.884
- C185.203,73.126,195.841,62.299,195.841,48.979z"/>
- </g>
-</g>
-<g opacity="0.65">
- <g>
- <path fill="#6AC7BD" d="M73.44,24.001h-0.003C59.919,24.003,48.96,34.959,48.958,48.476v0.003h0.003v0.002l-0.004,0.001v0.003
- c0.002,13.519,10.961,24.478,24.479,24.478s24.477-10.959,24.479-24.478v-0.003C97.916,34.963,86.958,24.003,73.44,24.001z
- M73.442,50.928c-1.352,0-2.448-1.096-2.448-2.448s1.096-2.448,2.448-2.448s2.448,1.096,2.448,2.448S74.794,50.928,73.442,50.928z
- "/>
- </g>
-</g>
-</svg>
diff --git a/documentation/poky-ref-manual/poky-ref-manual-customization.xsl b/documentation/poky-ref-manual/poky-ref-manual-customization.xsl deleted file mode 100644 index 362ebed13..000000000 --- a/documentation/poky-ref-manual/poky-ref-manual-customization.xsl +++ /dev/null @@ -1,6 +0,0 @@ -<?xml version='1.0'?> -<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0"> - - <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" /> - -</xsl:stylesheet> diff --git a/documentation/poky-ref-manual/poky-ref-manual.xml b/documentation/poky-ref-manual/poky-ref-manual.xml deleted file mode 100644 index 874d9a1c7..000000000 --- a/documentation/poky-ref-manual/poky-ref-manual.xml +++ /dev/null @@ -1,107 +0,0 @@ -<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<book id='poky-ref-manual' lang='en' - xmlns:xi="http://www.w3.org/2003/XInclude" - xmlns="http://docbook.org/ns/docbook" - > - <bookinfo> - - <mediaobject> - <imageobject> - <imagedata fileref='figures/poky-ref-manual.png' - format='SVG' - align='center' scalefit='1' width='100%'/> - </imageobject> - </mediaobject> - - <title>Poky Reference Manual</title> - <subtitle>A Guide and Reference to Poky</subtitle> - <authorgroup> - <author> - <firstname>Richard</firstname> <surname>Purdie</surname> - <affiliation> - <orgname>Linux Foundation</orgname> - </affiliation> - <email>richard.purdie@linuxfoundation.org</email> - </author> - - <author> - <firstname>Tomas</firstname> <surname>Frydrych</surname> - <affiliation> - <orgname>Intel Corporation</orgname> - </affiliation> - </author> - - <author> - <firstname>Marcin</firstname> <surname>Juszkiewicz</surname> - </author> - <author> - <firstname>Dodji</firstname> <surname>Seketeli</surname> - </author> - </authorgroup> - - <revhistory> - <revision> - <revnumber>4.0+git</revnumber> - <date>24 November 2010</date> - <revremark>Poky Master Documentation</revremark> - </revision> - <revision> - <revnumber>5.0+git</revnumber> - <date>6 April 2011</date> - <revremark>Released with Yocto Project 1.0 (Bernard 5.0).</revremark> - </revision> - </revhistory> - - <copyright> - <year>2007-2011</year> - <holder>Linux Foundation</holder> - </copyright> - - <legalnotice> - <para> - Permission is granted to copy, distribute and/or modify this document under - the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England & Wales</ulink> as published by Creative Commons. - </para> - </legalnotice> - - </bookinfo> - - <xi:include href="introduction.xml"/> - - <xi:include href="usingpoky.xml"/> - - <xi:include href="extendpoky.xml"/> - - <xi:include href="../bsp-guide/bsp.xml"/> - - <xi:include href="development.xml"/> - - <xi:include href="ref-structure.xml"/> - - <xi:include href="ref-bitbake.xml"/> - - <xi:include href="ref-classes.xml"/> - - <xi:include href="ref-images.xml"/> - - <xi:include href="ref-features.xml"/> - - <xi:include href="ref-variables.xml"/> - - <xi:include href="ref-varlocality.xml"/> - - <xi:include href="faq.xml"/> - - <xi:include href="resources.xml"/> - -<!-- <index id='index'> - <title>Index</title> - </index> ---> - -</book> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/ref-bitbake.xml b/documentation/poky-ref-manual/ref-bitbake.xml deleted file mode 100644 index 75b3bf5e5..000000000 --- a/documentation/poky-ref-manual/ref-bitbake.xml +++ /dev/null @@ -1,347 +0,0 @@ -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<appendix id='ref-bitbake'> - - <title>Reference: BitBake</title> - - <para> - BitBake is a program written in Python that interprets the metadata that makes up Poky. - At some point, people wonder what actually happens when you enter: - <literallayout class='monospaced'> - $ bitbake poky-image-sato - </literallayout> - </para> - - <para> - This appendix provides an overview of what happens behind the scenes from BitBake's perspective. - </para> - - <note><para> - BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships. - As such, it has no real knowledge of what the tasks being executed actually do. - BitBake just considers a list of tasks with dependencies and handles metadata - that consists of variables in a certain format that get passed to the tasks. - </para></note> - - <section id='ref-bitbake-parsing'> - <title>Parsing</title> - - <para> - BitBake parses configuration files, classes, and <filename>.bb</filename> files. - </para> - - <para> - The first thing BitBake does is look for the <filename>bitbake.conf</filename> file. - Poky keeps this file in <filename>meta/conf/</filename>. - BitBake finds it by examining the <filename>BBPATH</filename> environment - variable and looking for the <filename>meta/conf/</filename> - directory. - </para> - - <para> - In Poky, <filename>bitbake.conf</filename> lists other configuration - files to include from a <filename>conf/</filename> - directory below the directories listed in <filename>BBPATH</filename>. - In general the most important configuration file from a user's perspective - is <filename>local.conf</filename>, which contains a user's customized - settings for Poky. - Other notable configuration files are the distribution - configuration file (set by the <glossterm><link linkend='var-DISTRO'> - DISTRO</link></glossterm> variable) and the machine configuration file - (set by the <glossterm><link linkend='var-MACHINE'>MACHINE</link> - </glossterm> variable). - The DISTRO and MACHINE environment variables are both usually set in - the <filename>local.conf</filename> file. - Valid distribution - configuration files are available in the <filename> - meta/conf/distro/</filename> directory and valid machine configuration - files in the <filename>meta/conf/machine/</filename> - directory. - Within the <filename>meta/conf/machine/include/</filename> - directory are various <filename>tune-*.inc</filename> configuration files that provide common - "tuning" settings specific to and shared between particular architectures and machines. - </para> - - <para> - After the parsing of the configuration files some standard classes are included. - The <filename>base.bbclass</filename> file is always included. - Other classes that are specified in the configuration using the - <glossterm><link linkend='var-INHERIT'>INHERIT</link></glossterm> - variable are also inculded. - Class files are searched for in a classes subdirectory - under the paths in <filename>BBPATH</filename> in the same way as - configuration files. - </para> - - <para> - After classes are included, the - variable <glossterm><link linkend='var-BBFILES'>BBFILES</link></glossterm> - is set, usually in - <filename>local.conf</filename>, and defines the list of places to search for - <filename>.bb</filename> files. - By default, the BBFILES variable specifies the <filename>meta/recipes-*/ - </filename> directory within Poky. - Adding extra content to BBFILES is best achieved through the use of BitBake - <link linkend='usingpoky-changes-layers'>"layers"</link>. - </para> - - <para> - BitBake parses each <filename>.bb</filename> file in BBFILES and - stores the values of various variables. - In summary, for each <filename>.bb</filename> - file the configuration plus the base class of variables are set, followed - by the data in the <filename>.bb</filename> file - itself, followed by any inherit commands that - <filename>.bb</filename> file might contain. - </para> - - <para> - Because parsing <filename>.bb</filename> files is a time - consuming process, a cache is kept to speed up subsequent parsing. - This cache is invalid if the timestamp of the <filename>.bb</filename> - file itself changes, or if the timestamps of any of the include, - configuration or class files the <filename>.bb</filename> - file depends on changes. - </para> - </section> - - <section id='ref-bitbake-providers'> - <title>Preferences and Providers</title> - - <para> - Once all the <filename>.bb</filename> files have been - parsed, BitBake starts to build the target (poky-image-sato in the previous section's - example) and looks for providers of that target. - Once a provider is selected, BitBake resolves all the dependencies for - the target. - In the case of "poky-image-sato", it would lead to <filename>task-base.bb</filename>, - which in turn leads to packages like <application>Contacts</application>, - <application>Dates</application> and <application>BusyBox</application>. - These packages in turn depend on glibc and the toolchain. - </para> - - <para> - Sometimes a target might have multiple providers. - A common example is "virtual/kernel", which is provided by each kernel package. - Each machine often elects the best kernel provider by using a line similar to the - following in the machine configuration file: - </para> - - <programlisting> -PREFERRED_PROVIDER_virtual/kernel = "linux-rp" - </programlisting> - - <para> - The default <glossterm><link linkend='var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</link></glossterm> - is the provider with the same name as the target. - </para> - - <para> - Understanding how providers are chosen is made complicated by the fact - that multiple versions might exist. - BitBake defaults to the highest version of a provider. - Version comparisons are made using the same method as Debian. - You can use the <glossterm><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></glossterm> - variable to specify a particular version (usually in the distro configuration). - You can influence the order by using the - <glossterm><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></glossterm> - variable. - By default, files have a preference of "0". - Setting the DEFAULT_PREFERENCE to "-1" makes the package unlikely to be used unless it is - explicitly referenced. - Setting the DEFAULT_PREFERENCE to "1" makes it likely the package is used. - PREFERRED_VERSION overrides any DEFAULT_PREFERENCE setting. - DEFAULT_PREFERENCE is often used to mark newer and more experimental package - versions until they have undergone sufficient testing to be considered stable. - </para> - - <para> - In summary, BitBake has created a list of providers, which is prioritized, for each target. - </para> - </section> - - <section id='ref-bitbake-dependencies'> - <title>Dependencies</title> - - <para> - Each target BitBake builds consists of multiple tasks such as fetch, unpack, patch, configure, - and compile. - For best performance on multi-core systems, BitBake considers each task as an independent - entity with its own set of dependencies. - </para> - - <para> - Dependencies are defined through several variables. - You can find information about variables BitBake uses in the - <ulink url='http://bitbake.berlios.de/manual/'>BitBake manual</ulink>. - At a basic level it is sufficient to know that BitBake uses the - <glossterm><link linkend='var-DEPENDS'>DEPENDS</link></glossterm> and - <glossterm><link linkend='var-RDEPENDS'>RDEPENDS</link></glossterm> variables when - calculating dependencies. - </para> - - </section> - - <section id='ref-bitbake-tasklist'> - <title>The Task List</title> - - <para> - Based on the generated list of providers and the dependency information, - BitBake can now calculate exactly what tasks it needs to run and in what - order it needs to run them. - The build now starts with BitBake forking off threads up to the limit set in the - <glossterm><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></glossterm> variable. - BitBake continues to fork threads as long as there are tasks ready to run, - those tasks have all their dependencies met, and the thread threshold has not been - exceeded. - </para> - - <para> - As each task completes, a timestamp is written to the directory specified by the - <glossterm><link linkend='var-STAMPS'>STAMPS</link></glossterm> variable (usually - <filename>build/tmp/stamps/*/</filename>). - On subsequent runs, BitBake looks at the STAMPS directory and does not rerun - tasks that are already completed unless a timestamp is found to be invalid. - Currently, invalid timestamps are only considered on a per - <filename>.bb</filename> file basis. - So, for example, if the configure stamp has a timestamp greater than the - compile timestamp for a given target then the compile task would rerun. - Running the compile task again, however, has no effect on other providers - that depend on that target. - This behavior could change or become configurable in future versions of BitBake. - </para> - - <note><para> - Some tasks are marked as "nostamp" tasks. - No timestamp file is created when these tasks are run. - Consequently, "nostamp" tasks are always rerun. - </para></note> - </section> - - <section id='ref-bitbake-runtask'> - <title>Running a Task</title> - - <para> - Tasks can either be a shell task or a python task. - For shell tasks, BitBake writes a shell script to - <filename>${WORKDIR}/temp/run.do_taskname.pid</filename> and then executes the script. - The generated shell script contains all the exported variables, and the shell functions - with all variables expanded. - Output from the shell script goes to the file <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>. - Looking at the expanded shell functions in the run file and the output in the log files - is a useful debugging technique. - </para> - - <para> - For Python tasks, BitBake executes the task internally and logs information to the - controlling terminal. - Future versions of BitBake will write the functions to files similar to the way - shell tasks are handled. - Logging will be handled in way similar to shell tasks as well. - </para> - - <para> - Once all the tasks have been completed BitBake exits. - </para> - </section> - - - <section id='ref-bitbake-commandline'> - <title>BitBake Command Line</title> - - <para> - Following is the bitbake manpage: - </para> - - <screen> -$ bitbake --help -Usage: bitbake [options] [package ...] - -Executes the specified task (default is 'build') for a given set of BitBake files. -It expects that BBFILES is defined, which is a space separated list of files to -be executed. BBFILES does support wildcards. -Default BBFILES are the .bb files in the current directory. - -Options: - --version show program's version number and exit - -h, --help show this help message and exit - -b BUILDFILE, --buildfile=BUILDFILE - execute the task against this .bb file, rather than a - package from BBFILES. - -k, --continue continue as much as possible after an error. While the - target that failed, and those that depend on it, - cannot be remade, the other dependencies of these - targets can be processed all the same. - -a, --tryaltconfigs continue with builds by trying to use alternative - providers where possible. - -f, --force force run of specified cmd, regardless of stamp status - -i, --interactive drop into the interactive mode also called the BitBake - shell. - -c CMD, --cmd=CMD Specify task to execute. Note that this only executes - the specified task for the providee and the packages - it depends on, i.e. 'compile' does not implicitly call - stage for the dependencies (IOW: use only if you know - what you are doing). Depending on the base.bbclass a - listtasks tasks is defined and will show available - tasks - -r FILE, --read=FILE read the specified file before bitbake.conf - -v, --verbose output more chit-chat to the terminal - -D, --debug Increase the debug level. You can specify this more - than once. - -n, --dry-run don't execute, just go through the motions - -p, --parse-only quit after parsing the BB files (developers only) - -d, --disable-psyco disable using the psyco just-in-time compiler (not - recommended) - -s, --show-versions show current and preferred versions of all packages - -e, --environment show the global or per-package environment (this is - what used to be bbread) - -g, --graphviz emit the dependency trees of the specified packages in - the dot syntax - -I IGNORED_DOT_DEPS, --ignore-deps=IGNORED_DOT_DEPS - Stop processing at the given list of dependencies when - generating dependency graphs. This can help to make - the graph more appealing - -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS - Show debug logging for the specified logging domains - -P, --profile profile the command and print a report - </screen> - </section> - - <section id='ref-bitbake-fetchers'> - <title>Fetchers</title> - - <para> - BitBake also contains a set of "fetcher" modules that allow - retrieval of source code from various types of sources. - For example, BitBake can get source code from a disk with the metadata, from websites, - from remote shell accounts or from Source Code Management (SCM) systems - like <filename>cvs/subversion/git</filename>. - </para> - - <para> - Fetchers are usually triggered by entries in - <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>. - You can find information about the options and formats of entries for specific - fetchers in the <ulink url='http://bitbake.berlios.de/manual/'>BitBake manual</ulink>. - </para> - - <para> - One useful feature for certain SCM fetchers is the ability to - "auto-update" when the upstream SCM changes version. - Since this ability requires certain functionality from the SCM, not all - systems support it. - Currently Subversion, Bazaar and to a limited extent, Git support the ability to "auto-update". - This feature works using the <glossterm><link linkend='var-SRCREV'>SRCREV</link></glossterm> - variable. - See the - <link linkend='platdev-appdev-srcrev'>Developing within Poky with an External SCM-based Package</link> - section for more information. - </para> - - </section> - -</appendix> -<!-- -vim: expandtab tw=80 ts=4 spell spelllang=en_gb ---> diff --git a/documentation/poky-ref-manual/ref-classes.xml b/documentation/poky-ref-manual/ref-classes.xml deleted file mode 100644 index 8eb94c268..000000000 --- a/documentation/poky-ref-manual/ref-classes.xml +++ /dev/null @@ -1,435 +0,0 @@ -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<appendix id='ref-classes'> -<title>Reference: Classes</title> - -<para> - Class files are used to abstract common functionality and share it amongst multiple - <filename>.bb</filename> files. Any metadata usually found in a - <filename>.bb</filename> file can also be placed in a class - file. Class files are identified by the extension - <filename>.bbclass</filename> and are usually placed - in a <filename>classes/</filename> directory beneath the - <filename>meta*/</filename> directory or the directory pointed - by BUILDDIR (e.g. <filename>build/</filename>)in the same way as - <filename>.conf</filename> files in the <filename - class="directory">conf</filename> directory. Class files are searched for - in BBPATH in the same was as <filename>.conf</filename> files too. -</para> - -<para> - In most cases inheriting the class is enough to enable its features, although - for some classes you may need to set variables and/or override some of the - default behaviour. -</para> - -<section id='ref-classes-base'> - <title>The base class - <filename>base.bbclass</filename></title> - - <para> - The base class is special in that every <filename>.bb</filename> - file inherits it automatically. It contains definitions of standard basic - tasks such as fetching, unpacking, configuring (empty by default), compiling - (runs any Makefile present), installing (empty by default) and packaging - (empty by default). These are often overridden or extended by other classes - such as <filename>autotools.bbclass</filename> or - <filename>package.bbclass</filename>. The class also contains some commonly - used functions such as <filename>oe_runmake</filename>. - </para> -</section> - -<section id='ref-classes-autotools'> - <title>Autotooled Packages - <filename>autotools.bbclass</filename></title> - - <para> - Autotools (autoconf, automake, libtool) bring standardization. - This class defines a set of tasks (configure, compile etc.) that - work for all autotooled packages. - It should usually be enough to define a few standard variables as documented in the - <link linkend='usingpoky-extend-addpkg-autotools'>simple autotools - example</link> section and then simply "inherit autotools". - This class can also work with software that emulates autotools. - </para> - - <para> - It's useful to have some idea of how the tasks defined by this class work - and what they do behind the scenes. - </para> - - <itemizedlist> - <listitem> - <para> - <filename>do_configure</filename> ‐ regenerates the configure script (using autoreconf) - and then launches it with a standard set of arguments used during - cross-compilation. - You can pass additional parameters to - <filename>configure</filename> through the - <glossterm><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></glossterm> variable. - </para> - </listitem> - <listitem> - <para> - <filename>do_compile</filename> ‐ runs <filename>make</filename> with - arguments that specify the compiler and linker. - You can pass additional arguments through - the <glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link> - </glossterm> variable. - </para> - </listitem> - <listitem> - <para> - <filename>do_install</filename> ‐ runs <filename>make install</filename> - and passes a <filename>DESTDIR</filename> - option, which takes its value from the standard - <glossterm><link linkend='var-DESTDIR'>DESTDIR</link></glossterm> variable. - </para> - </listitem> - </itemizedlist> - -</section> - -<section id='ref-classes-update-alternatives'> - <title>Alternatives - <filename>update-alternatives.bbclass</filename></title> - - <para> - Several programs can fulfill the same or similar function and - be installed with the same name. - For example, the <filename>ar</filename> - command is available from the "busybox", "binutils" and "elfutils" packages. - The <filename>update-alternatives.bbclass</filename> class handles renaming the - binaries so that multiple packages can be installed without conflicts. - The <filename>ar</filename> command still works regardless of which packages are installed - or subsequently removed. - The class renames the conflicting binary in each package - and symlinks the highest priority binary during installation or removal - of packages. - </para> - <para> - Four variables control this class: - </para> - <itemizedlist> - <listitem><para><filename>ALTERNATIVE_NAME</filename> ‐ The name of the - binary that is replaced (<filename>ar</filename> in this example).</para></listitem> - <listitem><para><filename>ALTERNATIVE_LINK</filename> ‐ The path to - the resulting binary (<filename>/bin/ar</filename> in this example).</para></listitem> - <listitem><para><filename>ALTERNATIVE_PATH</filename> ‐ The path to the - real binary (<filename>/usr/bin/ar.binutils</filename> in this example).</para></listitem> - <listitem><para><filename>ALTERNATIVE_PRIORITY</filename> ‐ The priority of - the binary. - The version with the most features should have the highest priority.</para></listitem> - </itemizedlist> - <para> - Currently, only one binary per package is supported. - </para> -</section> - -<section id='ref-classes-update-rc.d'> - <title>Initscripts - <filename>update-rc.d.bbclass</filename></title> - - <para> - This class uses update-rc.d to safely install an initscript on behalf of - the package. Details such as making sure the initscript is stopped before - a package is removed and started when the package is installed are taken - care of. Three variables control this class, - <link linkend='var-INITSCRIPT_PACKAGES'>INITSCRIPT_PACKAGES</link>, - <link linkend='var-INITSCRIPT_NAME'>INITSCRIPT_NAME</link> and - <link linkend='var-INITSCRIPT_PARAMS'>INITSCRIPT_PARAMS</link>. See the - links for details. - </para> -</section> - -<section id='ref-classes-binconfig'> - <title>Binary config scripts - <filename>binconfig.bbclass</filename></title> - - <para> - Before pkg-config had become widespread, libraries shipped shell - scripts to give information about the libraries and include paths needed - to build software (usually named 'LIBNAME-config'). This class assists - any recipe using such scripts. - </para> - - <para> - During staging Bitbake installs such scripts into the <filename - class="directory">sysroots/</filename> directory. It also changes all - paths to point into the <filename>sysroots/</filename> - directory so all builds which use the script will use the correct - directories for the cross compiling layout. - </para> -</section> - -<section id='ref-classes-debian'> - <title>Debian renaming - <filename>debian.bbclass</filename></title> - - <para> - This class renames packages so that they follow the Debian naming - policy, i.e. 'glibc' becomes 'libc6' and 'glibc-devel' becomes - 'libc6-dev'. - </para> -</section> - -<section id='ref-classes-pkgconfig'> - <title>Pkg-config - <filename>pkgconfig.bbclass</filename></title> - - <para> - Pkg-config brought standardisation and this class aims to make its - integration smooth for all libraries which make use of it. - </para> - - <para> - During staging Bitbake installs pkg-config data into the <filename - class="directory">sysroots/</filename> directory. By making use of - sysroot functionality within pkgconfig this class no longer has to - manipulate the files. - </para> -</section> - -<section id='ref-classes-src-distribute'> - <title>Distribution of sources - <filename>src_distribute_local.bbclass</filename></title> - - <para> - Many software licenses require providing the sources for compiled - binaries. To simplify this process two classes were created: - <filename>src_distribute.bbclass</filename> and - <filename>src_distribute_local.bbclass</filename>. - </para> - - <para> - Result of their work are <filename>tmp/deploy/source/</filename> - subdirs with sources sorted by <glossterm><link linkend='var-LICENSE'>LICENSE</link> - </glossterm> field. If recipe lists few licenses (or has entries like "Bitstream Vera") source archive is put in each - license dir. - </para> - - <para> - Src_distribute_local class has three modes of operating: - </para> - - <itemizedlist> - <listitem><para>copy - copies the files to the distribute dir</para></listitem> - <listitem><para>symlink - symlinks the files to the distribute dir</para></listitem> - <listitem><para>move+symlink - moves the files into distribute dir, and symlinks them back</para></listitem> - </itemizedlist> -</section> - -<section id='ref-classes-perl'> - <title>Perl modules - <filename>cpan.bbclass</filename></title> - - <para> - Recipes for Perl modules are simple - usually needs only - pointing to source archive and inheriting of proper bbclass. - Building is split into two methods dependly on method used by - module authors. - </para> - - <para> - Modules which use old Makefile.PL based build system require - using of <filename>cpan.bbclass</filename> in their recipes. - </para> - - <para> - Modules which use Build.PL based build system require - using of <filename>cpan_build.bbclass</filename> in their recipes. - </para> - -</section> - -<section id='ref-classes-distutils'> - <title>Python extensions - <filename>distutils.bbclass</filename></title> - - <para> - Recipes for Python extensions are simple - they usually only - require pointing to the source archive and inheriting the proper - bbclasses. - Building is split into two methods depending on the build method - used by the module authors. - </para> - - <para> - Extensions which use autotools based build system require use - of autotools and distutils-base bbclasses in their recipes. - </para> - - <para> - Extensions which use distutils build system require use - of <filename>distutils.bbclass</filename> in their recipes. - </para> - -</section> - -<section id='ref-classes-devshell'> - <title>Developer Shell - <filename>devshell.bbclass</filename></title> - - <para> - This class adds the devshell task. Its usually up to distribution policy - to include this class (Poky does). See the <link - linkend='platdev-appdev-devshell'>developing with 'devshell' section</link> - for more information about using devshell. - </para> - -</section> - -<section id='ref-classes-package'> - <title>Packaging - <filename>package*.bbclass</filename></title> - - <para> - The packaging classes add support for generating packages from a builds - output. The core generic functionality is in - <filename>package.bbclass</filename>, code specific to particular package - types is contained in various sub classes such as - <filename>package_deb.bbclass</filename>, <filename>package_ipk.bbclass</filename> - and <filename>package_rpm.bbclass</filename>. Most users will - want one or more of these classes and this is controlled by the <glossterm> - <link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></glossterm> - variable. The first class listed in this variable will be used for image - generation. Since images are generated from packages a packaging class is - needed to enable image generation. - </para> - -</section> - -<section id='ref-classes-kernel'> - <title>Building kernels - <filename>kernel.bbclass</filename></title> - - <para> - This class handles building of Linux kernels and the class contains code to know how to build both 2.4 and 2.6 kernel trees. All needed headers are - staged into <glossterm><link - linkend='var-STAGING_KERNEL_DIR'>STAGING_KERNEL_DIR</link></glossterm> - directory to allow building of out-of-tree modules using <filename>module.bbclass</filename>. - </para> - <para> - This means that each kernel module built is packaged separately and inter-module dependencies are - created by parsing the <filename>modinfo</filename> output. If all modules are - required then installing the "kernel-modules" package will install all - packages with modules and various other kernel packages such as "kernel-vmlinux". - </para> - - <para> - Various other classes are used by the kernel and module classes internally including - <filename>kernel-arch.bbclass</filename>, <filename>module_strip.bbclass</filename>, - <filename>module-base.bbclass</filename> and <filename>linux-kernel-base.bbclass</filename>. - </para> -</section> - -<section id='ref-classes-image'> - <title>Creating images - <filename>image.bbclass</filename> and <filename>rootfs*.bbclass</filename></title> - - <para> - Those classes add support for creating images in many formats. First the - rootfs is created from packages by one of the <filename>rootfs_*.bbclass</filename> - files (depending on package format used) and then image is created. - - The <glossterm><link - linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link></glossterm> - variable controls which types of image to generate. - - The list of packages to install into the image is controlled by the - <glossterm><link - linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></glossterm> - variable. - </para> -</section> - -<section id='ref-classes-sanity'> - <title>Host System sanity checks - <filename>sanity.bbclass</filename></title> - - <para> - This class checks prerequisite software is present to - notify the users of potential problems that will affect their build. It - also performs basic checks of the user configuration from local.conf to - prevent common mistakes resulting in build failures. It's usually up to - distribution policy whether to include this class (Poky does). - </para> -</section> - -<section id='ref-classes-insane'> - <title>Generated output quality assurance checks - <filename>insane.bbclass</filename></title> - - <para> - This class adds a step to package generation which sanity checks the - packages generated by Poky. There are an ever increasing range of checks - it performs, checking for common problems which break builds/packages/images, - see the bbclass file for more information. It's usually up to distribution - policy whether to include this class (Poky does). - </para> -</section> - -<section id='ref-classes-siteinfo'> - <title>Autotools configuration data cache - <filename>siteinfo.bbclass</filename></title> - - <para> - Autotools can require tests which have to execute on the target hardware. - Since this isn't possible in general when cross compiling, siteinfo is - used to provide cached test results so these tests can be skipped over but - the correct values used. The <link linkend='structure-meta-site'>meta/site directory</link> - contains test results sorted into different categories like architecture, endianess and - the libc used. Siteinfo provides a list of files containing data relevant to - the current build in the <glossterm><link linkend='var-CONFIG_SITE'>CONFIG_SITE - </link></glossterm> variable which autotools will automatically pick up. - </para> - <para> - The class also provides variables like <glossterm><link - linkend='var-SITEINFO_ENDIANESS'>SITEINFO_ENDIANESS</link></glossterm> - and <glossterm><link linkend='var-SITEINFO_BITS'>SITEINFO_BITS</link> - </glossterm> which can be used elsewhere in the metadata. - </para> - <para> - This class is included from <filename>base.bbclass</filename> and is hence always active. - </para> -</section> - -<section id='ref-classes-others'> - <title>Other Classes</title> - - <para> - Only the most useful/important classes are covered here but there are - others, see the <filename>meta/classes</filename> directory for the rest. - </para> -</section> - -<!-- Undocumented classes are: - base_srpm.bbclass - bootimg.bbclass - ccache.inc - ccdv.bbclass - cmake.bbclass - cml1.bbclass - cross.bbclass - flow-lossage.bbclass - gconf.bbclass - gettext.bbclass - gnome.bbclass - gtk-icon-cache.bbclass - icecc.bbclass - lib_package.bbclass - mirrors.bbclass - mozilla.bbclass - multimachine.bbclass - native.bbclass - oelint.bbclass - patch.bbclass - patcher.bbclass - pkg_distribute.bbclass - pkg_metainfo.bbclass - poky.bbclass - rm_work.bbclass - rpm_core.bbclass - scons.bbclass - sdk.bbclass - sdl.bbclass - sip.bbclass - sourcepkg.bbclass - srec.bbclass - syslinux.bbclass - tinderclient.bbclass - tmake.bbclass - utils.bbclass - xfce.bbclass - xlibs.bbclass ---> - - -</appendix> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/ref-features.xml b/documentation/poky-ref-manual/ref-features.xml deleted file mode 100644 index cde958811..000000000 --- a/documentation/poky-ref-manual/ref-features.xml +++ /dev/null @@ -1,302 +0,0 @@ -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<appendix id='ref-features'> - <title>Reference: Features</title> - - <para>'Features' provide a mechanism for working out which packages - should be included in the generated images. Distributions can - select which features they want to support through the - <glossterm linkend='var-DISTRO_FEATURES'><link - linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></glossterm> - variable which is set in the distribution configuration file - (poky.conf for Poky). Machine features are set in the - <glossterm linkend='var-MACHINE_FEATURES'><link - linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></glossterm> - variable which is set in the machine configuration file and - specifies which hardware features a given machine has. - </para> - - <para>These two variables are combined to work out which kernel modules, - utilities and other packages to include. A given distribution can - support a selected subset of features so some machine features might not - be included if the distribution itself doesn't support them. - </para> - - <section id='ref-features-distro'> - <title>Distro</title> - - <para>The items below are valid options for <glossterm linkend='var-DISTRO_FEATURES'><link - linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></glossterm>. - </para> - - <itemizedlist> - <listitem> - <para> - alsa - ALSA support will be included (OSS compatibility - kernel modules will be installed if available) - </para> - </listitem> - <listitem> - <para> - bluetooth - Include bluetooth support (integrated BT only) - </para> - </listitem> - <listitem> - <para> - ext2 - Include tools for supporting for devices with internal - HDD/Microdrive for storing files (instead of Flash only devices) - </para> - </listitem> - <listitem> - <para> - irda - Include Irda support - </para> - </listitem> - <listitem> - <para> - keyboard - Include keyboard support (e.g. keymaps will be - loaded during boot). - </para> - </listitem> - <listitem> - <para> - pci - Include PCI bus support - </para> - </listitem> - <listitem> - <para> - pcmcia - Include PCMCIA/CompactFlash support - </para> - </listitem> - <listitem> - <para> - usbgadget - USB Gadget Device support (for USB - networking/serial/storage) - </para> - </listitem> - <listitem> - <para> - usbhost - USB Host support (allows to connect external - keyboard, mouse, storage, network etc) - </para> - </listitem> - <listitem> - <para> - wifi - WiFi support (integrated only) - </para> - </listitem> - <listitem> - <para> - cramfs - CramFS support - </para> - </listitem> - <listitem> - <para> - ipsec - IPSec support - </para> - </listitem> - <listitem> - <para> - ipv6 - IPv6 support - </para> - </listitem> - <listitem> - <para> - nfs - NFS client support (for mounting NFS exports on - device) - </para> - </listitem> - <listitem> - <para> - ppp - PPP dialup support - </para> - </listitem> - <listitem> - <para> - smbfs - SMB networks client support (for mounting - Samba/Microsoft Windows shares on device) - </para> - </listitem> - </itemizedlist> - </section> - - <section id='ref-features-machine'> - <title>Machine</title> - - <para>The items below are valid options for <glossterm linkend='var-MACHINE_FEATURES'><link - linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></glossterm>. - </para> - - <itemizedlist> - <listitem> - <para> - acpi - Hardware has ACPI (x86/x86_64 only) - </para> - </listitem> - <listitem> - <para> - alsa - Hardware has ALSA audio drivers - </para> - </listitem> - <listitem> - <para> - apm - Hardware uses APM (or APM emulation) - </para> - </listitem> - <listitem> - <para> - bluetooth - Hardware has integrated BT - </para> - </listitem> - <listitem> - <para> - ext2 - Hardware HDD or Microdrive - </para> - </listitem> - <listitem> - <para> - irda - Hardware has Irda support - </para> - </listitem> - <listitem> - <para> - keyboard - Hardware has a keyboard - </para> - </listitem> - <listitem> - <para> - pci - Hardware has a PCI bus - </para> - </listitem> - <listitem> - <para> - pcmcia - Hardware has PCMCIA or CompactFlash sockets - </para> - </listitem> - <listitem> - <para> - screen - Hardware has a screen - </para> - </listitem> - <listitem> - <para> - serial - Hardware has serial support (usually RS232) - </para> - </listitem> - <listitem> - <para> - touchscreen - Hardware has a touchscreen - </para> - </listitem> - <listitem> - <para> - usbgadget - Hardware is USB gadget device capable - </para> - </listitem> - <listitem> - <para> - usbhost - Hardware is USB Host capable - </para> - </listitem> - <listitem> - <para> - wifi - Hardware has integrated WiFi - </para> - </listitem> - </itemizedlist> - </section> - - <section id='ref-features-image'> - <title>Reference: Images</title> - - <para> - The contents of images generated by Poky can be controlled by the <glossterm - linkend='var-IMAGE_FEATURES'><link - linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> - variable in local.conf. Through this you can add several different - predefined packages such as development utilities or packages with debug - information needed to investigate application problems or profile applications. - </para> - - <para> - Current list of <glossterm - linkend='var-IMAGE_FEATURES'><link - linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm> contains: - </para> - - <itemizedlist> - <listitem> - <para> - apps-console-core - Core console applications such as ssh daemon, - avahi daemon, portmap (for mounting NFS shares) - </para> - </listitem> - <listitem> - <para> - x11-base - X11 server + minimal desktop - </para> - </listitem> - <listitem> - <para> - x11-sato - OpenedHand Sato environment - </para> - </listitem> - <listitem> - <para> - apps-x11-core - Core X11 applications such as an X Terminal, file manager, file editor - </para> - </listitem> - <listitem> - <para> - apps-x11-games - A set of X11 games - </para> - </listitem> - <listitem> - <para> - apps-x11-pimlico - OpenedHand Pimlico application suite - </para> - </listitem> - <listitem> - <para> - tools-sdk - A full SDK which runs on device - </para> - </listitem> - <listitem> - <para> - tools-debug - Debugging tools such as strace and gdb - </para> - </listitem> - <listitem> - <para> - tools-profile - Profiling tools such as oprofile, exmap and LTTng - </para> - </listitem> - <listitem> - <para> - tools-testapps - Device testing tools (e.g. touchscreen debugging) - </para> - </listitem> - <listitem> - <para> - nfs-server - NFS server (exports / over NFS to everybody) - </para> - </listitem> - <listitem> - <para> - dev-pkgs - Development packages (headers and extra library links) for all packages - installed in a given image - </para> - </listitem> - <listitem> - <para> - dbg-pkgs - Debug packages for all packages installed in a given image - </para> - </listitem> - </itemizedlist> - </section> -</appendix> - -<!-- -vim: expandtab tw=80 ts=4 spell spelllang=en_gb ---> diff --git a/documentation/poky-ref-manual/ref-images.xml b/documentation/poky-ref-manual/ref-images.xml deleted file mode 100644 index 03cc62450..000000000 --- a/documentation/poky-ref-manual/ref-images.xml +++ /dev/null @@ -1,92 +0,0 @@ -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<appendix id='ref-images'> - <title>Reference: Images</title> - - <para> - Poky has several standard images covering most people's standard needs. - Use the following command to list the supported images: - <literallayout class='monospaced'> - $ ls meta*/recipes*/images/*.bb - </literallayout> - Images are listed below along with details of what they contain: - </para> - - <note> - Building an image without GNU Public License Version 3 (GPLv3) components is - only supported for minimal and base images. - Furthermore, if you are going to build an image using non-GPLv3 components, - you must make the following changes in the <filename>local.conf</filename> file - before using the BitBake command to build the minimal or base image: - <literallayout class='monospaced'> - 1. Comment out the IMAGE_EXTRA_FEATURES line - 2. Set INCOMPATIBLE_LICENSE = "GPLv3" - </literallayout> - </note> - - <itemizedlist> - <listitem> - <para> - <emphasis>poky-image-minimal</emphasis> - A small image just capable - of allowing a device to boot. - </para> - </listitem> - <listitem> - <para> - <emphasis>poky-image-base</emphasis> - A console-only image that fully - supports the target device hardware. - </para> - </listitem> - <listitem> - <para> - <emphasis>poky-image-core</emphasis> - An X11 image with simple - applications such as terminal, editor, and file manager. - </para> - </listitem> - <listitem> - <para> - <emphasis>poky-image-sato</emphasis> - An X11 image with Sato theme and - Pimlico applications. - The image also contains terminal, editor, and file manager. - </para> - </listitem> - <listitem> - <para> - <emphasis>poky-image-sato-dev</emphasis> - An X11 image similar to - poky-image-sato but - also includes a native toolchain and libraries needed to build applications - on the device itself. The image also includes testing and profiling tools - as well as debug symbols. This image was formerly poky-image-sdk. - </para> - </listitem> - <listitem> - <para> - <emphasis>poky-image-lsb</emphasis> - An image suitable for implementations - that conform to Linux Standard Base (LSB). - </para> - </listitem> - <listitem> - <para> - <emphasis>meta-toolchain</emphasis> - This image generates a tarball - that contains a stand-alone toolchain that can be used externally to Poky. - The tarball is self-contained and unpacks to the - <filename class="directory">/opt/poky</filename> directory. - The tarball also contains a copy of QEMU and the scripts necessary to run - poky QEMU images. - </para> - </listitem> - <listitem> - <para> - <emphasis>meta-toolchain-sdk</emphasis> - This image includes everything in - meta-toolchain but also includes development headers and libraries - to form a complete standalone SDK. - See the <link linkend='platdev-appdev-external-sdk'> - External Development Using the Poky SDK</link> section for more information. - </para> - </listitem> - </itemizedlist> -</appendix> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/ref-structure.xml b/documentation/poky-ref-manual/ref-structure.xml deleted file mode 100644 index 4cfd08fae..000000000 --- a/documentation/poky-ref-manual/ref-structure.xml +++ /dev/null @@ -1,621 +0,0 @@ -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<appendix id='ref-structure'> - -<title>Reference: Directory Structure</title> - -<para> - Poky consists of several components. - Understanding them and knowing where they are located is key to using Poky well. - This appendix describes the Poky directory structure and gives information about the various - files and directories. -</para> - -<section id='structure-core'> - <title>Top level core components</title> - - <section id='structure-core-bitbake'> - <title><filename class="directory">bitbake/</filename></title> - - <para> - Poky includes a copy of BitBake for ease of use. - The copy usually matches the current stable BitBake release from the BitBake project. - BitBake, a metadata interpreter, reads the Poky metadata and runs the tasks - defined by that data. - Failures are usually from the metadata and not - from BitBake itself. - Consequently, most users do not need to worry about BitBake. - The <filename class="directory">bitbake/bin/</filename> directory is placed - into the PATH environment variable by the - <link linkend="structure-core-script">poky-init-build-env</link> script. - </para> - - <para> - For more information on BitBake, see the BitBake on-line manual at - <ulink url="http://bitbake.berlios.de/manual/"/>. - </para> - </section> - - <section id='structure-core-build'> - <title><filename class="directory">build/</filename></title> - - <para> - This directory contains user configuration files and the output - generated by Poky in its standard configuration where the source tree is - combined with the output. - It is also possible to place output and configuration - files in a directory separate from the Poky source. - For information on separating output from the Poky source, see <link - linkend='structure-core-script'>poky-init-build-env</link>. - </para> - </section> - - <section id='structure-core-meta'> - <title><filename class="directory">meta/</filename></title> - - <para> - This directory contains the core metadata, which is a key part of Poky. - This directory contains the machine definitions, the Poky distribution, - and the packages that make up a given system. - </para> - </section> - -<!-- <section id='structure-core-meta-extras'> - <title><filename class="directory">meta-extras/</filename></title> - - <para> - This directory is similar to <filename class="directory">meta/</filename>. - The directory contains extra metadata not included in standard Poky. - This metadata is disabled by default and is not supported as part of Poky. - </para> - </section> ---> - - <section id='structure-core-meta-demoapps'> - <title><filename class="directory">meta-demoapps/</filename></title> - - <para> - This directory contains recipes for applications and demos that are not core. - </para> - </section> - - <section id='structure-core-meta-rt'> - <title><filename class="directory">meta-rt/</filename></title> - - <para> - This directory contains recipes for RealTime. - </para> - </section> - -<!-- <section id='structure-core-meta-***'> - <title><filename class="directory">meta-***/</filename></title> - - <para> - These directories are optional layers that are added to core metadata. - The layers are enabled by adding them to the <filename>conf/bblayers.conf</filename> file. - </para> - </section> ---> - - <section id='structure-core-scripts'> - <title><filename class="directory">scripts/</filename></title> - - <para> - This directory contains various integration scripts that implement - extra functionality in the Poky environment (e.g. QEMU scripts). - The <link linkend="structure-core-script">poky-init-build-env</link> script appends this - directory to the PATH environment variable. - </para> - </section> - -<!-- <section id='structure-core-sources'> - <title><filename class="directory">sources/</filename></title> - - <para> - This directory receives downloads as specified by the - <glossterm><link linkend='var-DL_DIR'>DL_DIR</link></glossterm> variable. - Even though the directory is not part of a checkout, Poky creates it during a build. - You can use this directory to share downloading files between Poky builds. - This practice can save you from downloading files multiple times. - <note><para> - You can override the location for this directory by setting - the DL_DIR variable in <filename>local.conf</filename>. - </para></note> - </para> - - <para> - This directory also contains SCM checkouts (e.g. <filename class="directory">sources/svn/ - </filename>, <filename class="directory">sources/cvs/</filename> or - <filename class="directory">sources/git/</filename>). - The <filename class="directory">sources</filename> directory can contain archives of - checkouts for various revisions or dates. - </para> - - <para> - It's worth noting that BitBake creates <filename class="extension">.md5 - </filename> stamp files for downloads. - BitBake uses these files to mark downloads as - complete as well as for checksum and access accounting purposes. - If you manually add a file to the directory, you need to touch the corresponding - <filename class="extension">.md5</filename> file as well. - </para> - </section> ---> - - <section id='handbook'> - <title><filename class="directory">documentation</filename></title> - - <para> - This directory holds the source for the documentation. Each manual is contained in - a sub-folder. For example, the files for this manual reside in - <filename class="directory">poky-ref-manual</filename>. - </para> - </section> - - <section id='structure-core-script'> - <title><filename>poky-init-build-env</filename></title> - - <para> - This script sets up the Poky build environment. - Sourcing this file in - a shell makes changes to PATH and sets other core BitBake variables based on the - current working directory. - You need to run this script before running Poky commands. - The script uses other scripts within the <filename class="directory">scripts/ - </filename> directory to do the bulk of the work. - You can use this script to specify any directory for the build's output by doing the following: - </para> - - <literallayout class='monospaced'> - $ source POKY_SRC/poky-init-build-env [BUILDDIR] - </literallayout> - - <para> - You can enter the above command from any directory, as long as POKY_SRC points to - the desired Poky source tree. - The optional BUILDDIR can be any directory into which you would - like Poky to generate the build output. - </para> - </section> - - <section id='structure-basic-top-level'> - <title><filename>LICENSE, README, and README.hardware</filename></title> - - <para> - These files are standard top-level files. - </para> - </section> -</section> - -<section id='structure-build'> - <title>The Build Directory - <filename class="directory">build/</filename></title> - - <section id='structure-build-pseudodone'> - <title><filename>build/pseudodone</filename></title> - - <para> - This tag file indicates that the intitial pseudo binar was created. - The first time BitBake is invoked this file is built. - </para> - </section> - - <section id='structure-build-conf-local.conf'> - <title><filename>build/conf/local.conf</filename></title> - - <para> - This file contains all the local user configuration of Poky. - If there is no <filename>local.conf</filename> present, it is created from - <filename>local.conf.sample</filename>. - The <filename>local.conf</filename> file contains documentation on the various configuration options. - Any variable set here overrides any variable set elsewhere within Poky unless - that variable is hard-coded within Poky (e.g. by using '=' instead of '?='). - Some variables are hard-coded for various reasons but these variables are - relatively rare. - </para> - - <para> - Edit this file to set the <glossterm><link linkend='var-MACHINE'>MACHINE</link></glossterm> - for which you want to build, which package types you - wish to use (PACKAGE_CLASSES) or where you want to downloaded files - (<glossterm><link linkend='var-DL_DIR'>DL_DIR</link></glossterm>). - </para> - </section> - - <section id='structure-build-conf-bblayers.conf'> - <title><filename>build/conf/bblayers.conf</filename></title> - - <para> - This file defines layers, which is a directory tree, traversed (or walked) by BitBake. - If <filename>bblayers.conf</filename> - is not present, it is created from <filename>bblayers.conf.sample</filename> when the environment - setup script is sourced. - </para> - </section> - - <section id='structure-build-conf-sanity_info'> - <title><filename>build/conf/sanity_info</filename></title> - - <para> - This file is created during the build to indicate the state of the sanity checks. - </para> - </section> - - <section id='structure-build-downloads'> - <title><filename>build/downloads/</filename></title> - - <para> - This directory is used for the upstream source tarballs. - The directory can be reused by multiple builds or moved to another location. - You can control the location of this directory through the - <glossterm><link linkend='var-DL_DIR'>DL_DIR</link></glossterm> variable. - </para> - </section> - - <section id='structure-build-sstate-cache'> - <title><filename>build/sstate-cache/</filename></title> - - <para> - This directory is used for the shared state cache. - The directory can be reused by multiple builds or moved to another location. - You can control the location of this directory through the - <glossterm><link linkend='var-SSTATE_DIR'>SSTATE_DIR</link></glossterm> variable. - </para> - </section> - - <section id='structure-build-tmp'> - <title><filename class="directory">build/tmp/</filename></title> - - <para> - This directory receives all the Poky output. - BitBake creates this directory if it does not exist. - To clean Poky and start a build from scratch (other than downloads), - you can remove everything in this directory or get rid of the directory completely. - The <filename class="directory">tmp/</filename> directory has some important - sub-components detailed below. - </para> - </section> - - <section id='structure-build-tmp-buildstats'> - <title><filename class="directory">build/tmp/buildstats/</filename></title> - - <para> - This directory stores the build statistics. - </para> - </section> - - <section id='structure-build-tmp-cache'> - <title><filename class="directory">build/tmp/cache/</filename></title> - - <para> - When BitBake parses the metadata it creates a cache file of the result that can - be used when subsequently running commands. - These results are stored here on a per-machine basis. - </para> - </section> - - <section id='structure-build-tmp-deploy'> - <title><filename class="directory">build/tmp/deploy/</filename></title> - - <para>This directory contains any 'end result' output from Poky.</para> - </section> - - <section id='structure-build-tmp-deploy-deb'> - <title><filename class="directory">build/tmp/deploy/deb/</filename></title> - - <para> - This directory receives any <filename>.deb</filename> packages produced by Poky. - The packages are sorted into feeds for different architecture types. - </para> - </section> - - <section id='structure-build-tmp-deploy-rpm'> - <title><filename class="directory">build/tmp/deploy/rpm/</filename></title> - - <para> - This directory receives any <filename>.rpm</filename> packages produced by Poky. - The packages re sorted into feeds for different architecture types. - </para> - </section> - - <section id='structure-build-tmp-deploy-images'> - <title><filename class="directory">build/tmp/deploy/images/</filename></title> - - <para> - This directory receives complete filesystem images. - If you want to flash the resulting image from a build onto a device, look here for the image. - </para> - </section> - - <section id='structure-build-tmp-deploy-ipk'> - <title><filename class="directory">build/tmp/deploy/ipk/</filename></title> - - <para>This directory receives <filename>.ipk</filename> packages produced by Poky.</para> - </section> - - <section id='structure-build-tmp-sysroots'> - <title><filename class="directory">build/tmp/sysroots/</filename></title> - - <para> - This directory contains shared header files and libraries as well as other shared - data. - Packages that need to share output with other packages do so within this directory. - The directory is subdivided by architecture so multiple builds can run within - the one build directory. - </para> - </section> - - <section id='structure-build-tmp-stamps'> - <title><filename class="directory">build/tmp/stamps/</filename></title> - - <para> - This directory holds information that that BitBake uses for accounting purposes - to track what tasks have run and when they have run. - The directory is sub-divided by architecture. - The files in the directory are empty of data. - However, BitBake uses the filenames and timestamps for tracking purposes. - </para> - </section> - - <section id='structure-build-tmp-log'> - <title><filename class="directory">build/tmp/log/</filename></title> - - <para> - This directory contains general logs that are not otherwise placed using the - package's <glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>. - Examples of logs are the output from the "check_pkg" or "distro_check" tasks. - </para> - </section> - - <section id='structure-build-tmp-pkgdata'> - <title><filename class="directory">build/tmp/pkgdata/</filename></title> - - <para> - This directory contains intermediate packaging data that is used later in the packaging process. - For more information, see <link linkend='ref-classes-package'>package.bbclass</link>. - </para> - </section> - - <section id='structure-build-tmp-pstagelogs'> - <title><filename class="directory">build/tmp/pstagelogs/</filename></title> - - <para> - This directory contains manifest for task-based pre-built. - Each manifest is basically a file list for installed files from a given task. - Manifests are useful for later packaging or cleanup processes. - </para> - </section> - - <section id='structure-build-tmp-work'> - <title><filename class="directory">build/tmp/work/</filename></title> - - <para> - This directory contains architecture-specific work sub-directories for packages built by BitBake. - All tasks execute from a work directory. - For example, the source for a particular package is unpacked, patched, configured and compiled all - within its own work directory. - </para> - - <para> - It is worth considering the structure of a typical work directory. - As an example consider the linux-rp kernel, version 2.6.20 r7 on the machine spitz - built within Poky. - For this package a work directory of - <filename class="directory">tmp/work/spitz-poky-linux-gnueabi/linux-rp-2.6.20-r7/</filename>, - referred to as <glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>, is created. - Within this directory, the source is unpacked to linux-2.6.20 and then patched by quilt - (see <link linkend="usingpoky-modifying-packages-quilt">Section 3.5.1</link>). - Within the <filename class="directory">linux-2.6.20</filename> directory, - standard quilt directories <filename class="directory">linux-2.6.20/patches</filename> - and <filename class="directory">linux-2.6.20/.pc</filename> are created, - and standard quilt commands can be used. - </para> - - <para> - There are other directories generated within WORKDIR. - The most important directory is WORKDIR - <filename class="directory">/temp/</filename>, which has log files for each - task (<filename>log.do_*.pid</filename>) and contains the scripts BitBake runs for - each task (<filename>run.do_*.pid</filename>). - The WORKDIR<filename class="directory">/image/</filename> directory is where "make - install" places its output that is then split into sub-packages - within WORKDIR<filename class="directory">/packages-split/</filename>. - </para> - </section> -</section> - -<section id='structure-meta'> - <title>The Metadata - <filename class="directory">meta/</filename></title> - - <para> - As mentioned previously, metadata is the core of Poky. - Metadata has several important subdivisions: - </para> - - <section id='structure-meta-classes'> - <title><filename class="directory">meta/classes/</filename></title> - - <para> - This directory contains the <filename class="extension">*.bbclass</filename> files. - Class files are used to abstract common code so it can be reused by multiple - packages. - Every package inherits the <filename>base.bbclass</filename> file. - Examples of other important classes are <filename>autotools.bbclass</filename>, which - in theory allows any Autotool-enabled package to work with Poky with minimal effort. - Another example is <filename>kernel.bbclass</filename> that contains common code and functions - for working with the Linux kernel. - Functions like image generation or packaging also have their specific class files - such as <filename>image.bbclass</filename>, <filename>rootfs_*.bbclass</filename> and - <filename>package*.bbclass</filename>. - </para> - </section> - - <section id='structure-meta-conf'> - <title><filename class="directory">meta/conf/</filename></title> - - <para> - This directory contains the core set of configuration files that start from - <filename>bitbake.conf</filename> and from which all other configuration - files are included. - See the includes at the end of the file and you will note that even - <filename>local.conf</filename> is loaded from there! - While <filename>bitbake.conf</filename> sets up the defaults, you can often override - these by using the (<filename>local.conf</filename>) file, machine file or - the distribution configuration file. - </para> - </section> - - <section id='structure-meta-conf-machine'> - <title><filename class="directory">meta/conf/machine/</filename></title> - - <para> - This directory contains all the machine configuration files. - If you set MACHINE="spitz", Poky looks for a <filename>spitz.conf</filename> file in this - directory. - The includes directory contains various data common to multiple machines. - If you want to add support for a new machine to Poky, look in this directory. - </para> - </section> - - <section id='structure-meta-conf-distro'> - <title><filename class="directory">meta/conf/distro/</filename></title> - - <para> - Any distribution-specific configuration is controlled from this directory. - Poky only contains the Poky distribution so <filename>poky.conf</filename> - is the main file here. - This directory includes the versions and SRCDATES for applications that are configured here. - An example of an alternative configuration is <filename>poky-bleeding.conf</filename> - although this file mainly inherits its configuration from Poky itself. - </para> - </section> - - <section id='structure-meta-recipes-bsp'> - <title><filename class="directory">meta/recipes-bsp/</filename></title> - - <para> - This directory contains anything linking to specific hardware or hardware configuration information - such as "uboot" and "grub". - </para> - </section> - - <section id='structure-meta-recipes-connectivity'> - <title><filename class="directory">meta/recipes-connectivity/</filename></title> - - <para> - This directory contains libraries and applications related to communication with other devices. - </para> - </section> - - <section id='structure-meta-recipes-core'> - <title><filename class="directory">meta/recipes-core/</filename></title> - - <para> - This directory contains what is needed to build a basic working Linux image - including commonly used dependencies. - </para> - </section> - - <section id='structure-meta-recipes-devtools'> - <title><filename class="directory">meta/recipes-devtools/</filename></title> - - <para> - This directory contains tools that are primarily used by the build system. - The tools, however, can also be used on targets. - </para> - </section> - - <section id='structure-meta-recipes-extended'> - <title><filename class="directory">meta/recipes-extended/</filename></title> - - <para> - This directory contains non-essential applications that add features compared to the - alternatives in core. - You might need this directory for full tool functionality or for Linux Standard Base (LSB) - compliance. - </para> - </section> - - <section id='structure-meta-recipes-gnome'> - <title><filename class="directory">meta/recipes-gnome/</filename></title> - - <para> - This directory contains all things related to the GTK+ application framework. - </para> - </section> - - <section id='structure-meta-recipes-graphics'> - <title><filename class="directory">meta/recipes-graphics/</filename></title> - - <para> - This directory contains X and other graphically related system libraries - </para> - </section> - - <section id='structure-meta-recipes-kernel'> - <title><filename class="directory">meta/recipes-kernel/</filename></title> - - <para> - This directory contains the kernel and generic applications and libraries that - have strong kernel dependencies. - </para> - </section> - - <section id='structure-meta-recipes-multimedia'> - <title><filename class="directory">meta/recipes-multimedia/</filename></title> - - <para> - This directory contains codecs and support utilities for audio, images and video. - </para> - </section> - - <section id='structure-meta-recipes-qt'> - <title><filename class="directory">meta/recipes-qt/</filename></title> - - <para> - This directory contains all things related to the QT application framework. - </para> - </section> - - <section id='structure-meta-recipes-sato'> - <title><filename class="directory">meta/recipes-sato/</filename></title> - - <para> - This directory contains the Sato demo/reference UI/UX and its associated applications - and configuration data. - </para> - </section> - - <section id='structure-meta-recipes-support'> - <title><filename class="directory">meta/recipes-support/</filename></title> - - <para> - This directory contains recipes that used by other recipes, but that are not directly - included in images (i.e. depenendies of other recipes). - </para> - </section> - - <section id='structure-meta-site'> - <title><filename class="directory">meta/site/</filename></title> - - <para> - This directory contains a list of cached results for various architectures. - Because certain "autoconf" test results cannot be determined when cross-compiling due to - the tests not able to run on a live system, the information in this directory is - passed to "autoconf" for the various architectures. - </para> - </section> - - <section id='structure-meta-recipes-txt'> - <title><filename class="directory">meta/recipes.txt/</filename></title> - - <para> - This file is a description of the contents of <filename>recipes-*</filename>. - </para> - </section> -</section> - -</appendix> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/ref-variables.xml b/documentation/poky-ref-manual/ref-variables.xml deleted file mode 100644 index 2e3dbb668..000000000 --- a/documentation/poky-ref-manual/ref-variables.xml +++ /dev/null @@ -1,956 +0,0 @@ -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<!-- Dummy chapter --> -<appendix id='ref-variables-glos'> - -<title>Reference: Variables Glossary</title> - -<para> - This section lists common variables used in Poky and gives an overview - of their function and contents. -</para> - -<glossary id='ref-variables-glossary'> - - - <para> - <link linkend='var-glossary-a'>A</link> - <link linkend='var-glossary-b'>B</link> - <link linkend='var-glossary-c'>C</link> - <link linkend='var-glossary-d'>D</link> - <link linkend='var-glossary-e'>E</link> - <link linkend='var-glossary-f'>F</link> -<!-- <link linkend='var-glossary-g'>G</link> --> - <link linkend='var-glossary-h'>H</link> - <link linkend='var-glossary-i'>I</link> -<!-- <link linkend='var-glossary-j'>J</link> --> - <link linkend='var-glossary-k'>K</link> - <link linkend='var-glossary-l'>L</link> - <link linkend='var-glossary-m'>M</link> -<!-- <link linkend='var-glossary-n'>N</link> --> -<!-- <link linkend='var-glossary-o'>O</link> --> - <link linkend='var-glossary-p'>P</link> -<!-- <link linkend='var-glossary-q'>Q</link> --> - <link linkend='var-glossary-r'>R</link> - <link linkend='var-glossary-s'>S</link> - <link linkend='var-glossary-t'>T</link> -<!-- <link linkend='var-glossary-u'>U</link> --> -<!-- <link linkend='var-glossary-v'>V</link> --> - <link linkend='var-glossary-w'>W</link> -<!-- <link linkend='var-glossary-x'>X</link> --> -<!-- <link linkend='var-glossary-y'>Y</link> --> -<!-- <link linkend='var-glossary-z'>Z</link>--> - </para> - - <glossdiv id='var-glossary-a'><title>A</title> - - <glossentry id='var-AUTHOR'><glossterm>AUTHOR</glossterm> - <glossdef> - <para>E-mail address to contact original author(s) - to - send patches, forward bugs...</para> - </glossdef> - </glossentry> - - <glossentry id='var-AUTOREV'><glossterm>AUTOREV</glossterm> - <glossdef> - <para>Use current (newest) source revision - used with - <glossterm><link linkend='var-SRCREV'>SRCREV</link></glossterm> - variable.</para> - </glossdef> - </glossentry> - - </glossdiv> - - <glossdiv id='var-glossary-b'><title>B</title> - - <glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm> - <glossdef> - <para>The maximum number of tasks BitBake should run in parallel at any one time</para> - </glossdef> - </glossentry> - - <glossentry id='var-BBFILE_COLLECTIONS'><glossterm>BBFILE_COLLECTIONS</glossterm> - <glossdef> - <para>Identifies layer-specific bbfiles, which contain recipes used by BitBake to build software. - The Variable is appended with a layer name.</para> - </glossdef> - </glossentry> - - <glossentry id='var-BBFILE_PATTERN'><glossterm>BBFILE_PATTERN</glossterm> - <glossdef> - <para>Variable that expands to match files from BBFILES in a particular layer. BBFILE_PATTERN - is used in the <filename>conf/layer.conf</filename> file and must contain the name of the - specific layer (e.g. BBFILE_PATTERN_emenlow).</para> - </glossdef> - </glossentry> - - <glossentry id='var-BBFILE_PRIORITY'><glossterm>BBFILE_PRIORITY</glossterm> - <glossdef> - <para>Assigns different priorities to recipe files in different layers. - This variable is useful in situations where the same package might appear in multiple layers. - It allows you to choose what takes precedence.</para> - </glossdef> - </glossentry> - - <glossentry id='var-BBFILES'><glossterm>BBFILES</glossterm> - <glossdef> - <para>List of recipes used by BitBake to build software</para> - </glossdef> - </glossentry> - - <glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm> - <glossdef> - <para>Used by Bitbake to locate bbclass and configuration files. This variable is analogous to - the PATH variable.</para> - </glossdef> - </glossentry> - - <glossentry id='var-BBINCLUDELOGS'><glossterm>BBINCLUDELOGS</glossterm> - <glossdef> - <para>Variable which controls how BitBake displays logs on build failure.</para> - </glossdef> - </glossentry> - - <glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm> - <glossdef> - <para>Lists in the <filename>bblayers.conf</filename> file layers to enable in the Poky build.</para> - </glossdef> - </glossentry> - - <glossentry id='var-BPN'><glossterm>BPN</glossterm> - <glossdef> - <para>Bare name of package with any suffixes like -cross -native - removed. </para> - </glossdef> - </glossentry> - - </glossdiv> - - <glossdiv id='var-glossary-c'><title>C</title> - - <glossentry id='var-CFLAGS'><glossterm>CFLAGS</glossterm> - <glossdef> - <para> - Flags passed to C compiler for the target system. Evaluates to the same - as <link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link>. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm> - <glossdef> - <para>A regular expression which evaluates to match the machines the recipe - works with. It stops recipes being run on machines they're incompatible with, - which is particularly useful with kernels. It also helps to increase parsing - speed as further parsing of the recipe is skipped as if it found the current - machine is not compatible.</para> - </glossdef> - </glossentry> - - <glossentry id='var-CONFIG_SITE'><glossterm>CONFIG_SITE</glossterm> - <glossdef> - <para> - A list of files which contains autoconf test results relevant - to the current build. This variable is used by the autotools utilities - when running configure. - </para> - </glossdef> - </glossentry> - - </glossdiv> - - <glossdiv id='var-glossary-d'><title>D</title> - - <glossentry id='var-D'><glossterm>D</glossterm> - <glossdef> - <para>Destination directory</para> - </glossdef> - </glossentry> - - <glossentry id='var-DEBUG_BUILD'><glossterm>DEBUG_BUILD</glossterm> - <glossdef> - <para> - Build packages with debugging information. This influences the value - <link linkend='var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION</link> - takes. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-DEBUG_OPTIMIZATION'><glossterm>DEBUG_OPTIMIZATION</glossterm> - <glossdef> - <para> - The options to pass in <link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link> - and <link linkend='var-CFLAGS'>CFLAGS</link> when compiling a system for debugging. - This defaults to "-O -fno-omit-frame-pointer -g". - </para> - </glossdef> - </glossentry> - - <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm> - <glossdef> - <para>Priority of recipe</para> - </glossdef> - </glossentry> - - <glossentry id='var-DEPENDS'><glossterm>DEPENDS</glossterm> - <glossdef> - <para> - A list of build time dependencies for a given recipe. These indicate - recipes that must have staged before this recipe can configure. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-DESCRIPTION'><glossterm>DESCRIPTION</glossterm> - <glossdef> - <para>Package description used by package - managers</para> - </glossdef> - </glossentry> - - <glossentry id='var-DESTDIR'><glossterm>DESTDIR</glossterm> - <glossdef> - <para>Destination directory</para> - </glossdef> - </glossentry> - - <glossentry id='var-DISTRO'><glossterm>DISTRO</glossterm> - <glossdef> - <para>Short name of distribution</para> - </glossdef> - </glossentry> - - <glossentry id='var-DISTRO_EXTRA_RDEPENDS'><glossterm>DISTRO_EXTRA_RDEPENDS</glossterm> - <glossdef> - <para>List of packages required by distribution.</para> - </glossdef> - </glossentry> - - <glossentry id='var-DISTRO_EXTRA_RRECOMMENDS'><glossterm>DISTRO_EXTRA_RRECOMMENDS</glossterm> - <glossdef> - <para>List of packages which extend usability of - image. Those packages will be automatically - installed but can be removed by user.</para> - </glossdef> - </glossentry> - - <glossentry id='var-DISTRO_FEATURES'><glossterm>DISTRO_FEATURES</glossterm> - <glossdef> - <para>Features of the distribution.</para> - </glossdef> - </glossentry> - - <glossentry id='var-DISTRO_NAME'><glossterm>DISTRO_NAME</glossterm> - <glossdef> - <para>Long name of distribution</para> - </glossdef> - </glossentry> - - <glossentry id='var-DISTRO_PN_ALIAS'><glossterm>DISTRO_PN_ALIAS</glossterm> - <glossdef> - <para>Alias names of the recipe in various Linux distributions. </para> - <para>More information in - <link - linkend='usingpoky-configuring-DISTRO_PN_ALIAS'> - Configuring the DISTRO_PN_ALIAS variable section - </link> - </para> - </glossdef> - </glossentry> - - <glossentry id='var-DISTRO_VERSION'><glossterm>DISTRO_VERSION</glossterm> - <glossdef> - <para>Version of distribution</para> - </glossdef> - </glossentry> - - <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm> - <glossdef> - <para>Directory where all fetched sources will be stored</para> - </glossdef> - - </glossentry> - </glossdiv> - - <glossdiv id='var-glossary-e'><title>E</title> - - <glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm> - <glossdef> - <para>Variable which control which locales for glibc are - to be generated during build (useful if target device - has 64M RAM or less)</para> - </glossdef> - </glossentry> - - <glossentry id='var-EXTRA_OECMAKE'><glossterm>EXTRA_OECMAKE</glossterm> - <glossdef> - <para>Additional cmake options</para> - </glossdef> - </glossentry> - - <glossentry id='var-EXTRA_OECONF'><glossterm>EXTRA_OECONF</glossterm> - <glossdef> - <para>Additional 'configure' script options</para> - </glossdef> - </glossentry> - - <glossentry id='var-EXTRA_OEMAKE'><glossterm>EXTRA_OEMAKE</glossterm> - <glossdef> - <para>Additional GNU make options</para> - </glossdef> - </glossentry> - - </glossdiv> - - <glossdiv id='var-glossary-f'><title>F</title> - - <glossentry id='var-FILES'><glossterm>FILES</glossterm> - <glossdef> - <para>list of directories/files which will be placed - in packages</para> - </glossdef> - </glossentry> - - <glossentry id='var-FULL_OPTIMIZATION'><glossterm>FULL_OPTIMIZATION</glossterm> - <glossdef> - <para> - The options to pass in <link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link> - and <link linkend='var-CFLAGS'>CFLAGS</link> when compiling an optimised system. - This defaults to "-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2". - </para> - </glossdef> - </glossentry> - - </glossdiv> - -<!-- <glossdiv id='var-glossary-g'><title>G</title>--> -<!-- </glossdiv>--> - - <glossdiv id='var-glossary-h'><title>H</title> - - <glossentry id='var-HOMEPAGE'><glossterm>HOMEPAGE</glossterm> - <glossdef> - <para>Website where more info about package can be found</para> - </glossdef> - </glossentry> - - </glossdiv> - - <glossdiv id='var-glossary-i'><title>I</title> - - <glossentry id='var-IMAGE_FEATURES'><glossterm>IMAGE_FEATURES</glossterm> - <glossdef> - <para><link linkend="ref-features-image">List of - features</link> present in resulting images</para> - </glossdef> - </glossentry> - - <glossentry id='var-IMAGE_FSTYPES'><glossterm>IMAGE_FSTYPES</glossterm> - <glossdef> - <para>Formats of rootfs images which we want to have - created</para> - </glossdef> - </glossentry> - - <glossentry id='var-IMAGE_INSTALL'><glossterm>IMAGE_INSTALL</glossterm> - <glossdef> - <para>List of packages used to build image</para> - </glossdef> - </glossentry> - - <glossentry id='var-INC_PR'><glossterm>INC_PR</glossterm> - <glossdef> - <para>Defines the Package revision. - You manually combine values for INC_PR into the PR field of the parent recipe. - When you change INC_PR you change the PR value for every person that includes the file. - </para> - <para> - The following example shows how to use INC_PR given a common <filename>.inc</filename> - that defines the variable. - Once defined, the variable can be used to set the PR value: - </para> - <programlisting> -recipes-graphics/xorg-font/font-util_1.1.1.bb:PR - "$(INC_PR).1" -recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR - "r1" -recipes-graphics/xorg-font/encondings_1.0.3.bb:PR - "$(INC_PR).1" -recipes-graphics/xorg-font/fiont-alias_1.0.2.bb:PR - "$(INC_PR).0" - </programlisting> - </glossdef> - </glossentry> - - <glossentry id='var-INHIBIT_PACKAGE_STRIP'><glossterm>INHIBIT_PACKAGE_STRIP</glossterm> - <glossdef> - <para> - This variable causes the build to not strip binaries in - resulting packages. - </para> - </glossdef> - </glossentry> - - - <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm> - <glossdef> - <para> - This variable causes the named class to be inherited at - this point during parsing. Its only valid in configuration - files. - </para> - </glossdef> - </glossentry> - - - <glossentry id='var-INITSCRIPT_PACKAGES'><glossterm>INITSCRIPT_PACKAGES</glossterm> - <glossdef> - <para> - Scope: Used in recipes when using update-rc.d.bbclass. Optional, defaults to PN. - </para> - <para> - A list of the packages which contain initscripts. If multiple - packages are specified you need to append the package name - to the other INITSCRIPT_* as an override. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-INITSCRIPT_NAME'><glossterm>INITSCRIPT_NAME</glossterm> - <glossdef> - <para> - Scope: Used in recipes when using update-rc.d.bbclass. Mandatory. - </para> - <para> - The filename of the initscript (as installed to ${etcdir}/init.d). - </para> - </glossdef> - </glossentry> - - <glossentry id='var-INITSCRIPT_PARAMS'><glossterm>INITSCRIPT_PARAMS</glossterm> - <glossdef> - <para> - Scope: Used in recipes when using update-rc.d.bbclass. Mandatory. - </para> - <para> - Specifies the options to pass to update-rc.d. An example is - "start 99 5 2 . stop 20 0 1 6 ." which gives the script a - runlevel of 99, starts the script in initlevels 2 and 5 and - stops it in levels 0, 1 and 6. - </para> - </glossdef> - </glossentry> - - - </glossdiv> - -<!-- <glossdiv id='var-glossary-j'><title>J</title>--> -<!-- </glossdiv>--> - - <glossdiv id='var-glossary-k'><title>K</title> - - <glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm> - <glossdef> - <para>The type of kernel to build for a device, usually set by the - machine configuration files and defaults to "zImage". This is used - when building the kernel and is passed to "make" as the target to - build.</para> - </glossdef> - </glossentry> - - </glossdiv> - - <glossdiv id='var-glossary-l'><title>L</title> - - <glossentry id='var-LAYERDIR'><glossterm>LAYERDIR</glossterm> - <glossdef> - <para>When used inside a layer.conf gives the path of the - current layer. This variable requires immediate expansion - (see the Bitbake manual) as lazy expansion can result in - the expansion happening in the wrong directory and therefore - giving the wrong value.</para> - </glossdef> - </glossentry> - <glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm> - <glossdef> - <para>List of package source licenses.</para> - </glossdef> - </glossentry> - <glossentry id='var-LIC_FILES_CHKSUM'><glossterm>LIC_FILES_CHKSUM</glossterm> - <glossdef> - <para>Checksums of the license text in the recipe source code. - </para> - <para>This variable tracks changes in license text of the source - code files. If the license text is changed, it will trigger the build - failure, which gives developer an opportunity to review any - license change</para> - <para> This is an optional variable now, and the plan is to make - it a required variable in the future </para> - <para>See "meta/package/zlib/zlib_${PV}.bb" file for an example</para> - - <para>More information in <link - linkend='usingpoky-configuring-LIC_FILES_CHKSUM'> - Configuring the LIC_FILES_CHKSUM variable section</link></para> - </glossdef> - </glossentry> - - </glossdiv> - - <glossdiv id='var-glossary-m'><title>M</title> - - <glossentry id='var-MACHINE'><glossterm>MACHINE</glossterm> - <glossdef> - <para>Target device</para> - </glossdef> - </glossentry> - - <glossentry id='var-MACHINE_ESSENTIAL_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_RDEPENDS</glossterm> - <glossdef> - <para>List of packages required to boot device</para> - </glossdef> - </glossentry> - - <glossentry id='var-MACHINE_ESSENTIAL_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_RRECOMMENDS</glossterm> - <glossdef> - <para>List of packages required to boot device (usually - additional kernel modules)</para> - </glossdef> - </glossentry> - - <glossentry id='var-MACHINE_EXTRA_RDEPENDS'><glossterm>MACHINE_EXTRA_RDEPENDS</glossterm> - <glossdef> - <para>List of packages required to use device</para> - </glossdef> - </glossentry> - - <glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMNEDS</glossterm> - <glossdef> - <para>List of packages useful to use device (for example - additional kernel modules)</para> - </glossdef> - </glossentry> - - <glossentry id='var-MACHINE_FEATURES'><glossterm>MACHINE_FEATURES</glossterm> - <glossdef> - <para>List of device features - defined in <link - linkend='ref-features-machine'>machine - features section</link></para> - </glossdef> - </glossentry> - - <glossentry id='var-MAINTAINER'><glossterm>MAINTAINER</glossterm> - <glossdef> - <para>E-mail of distribution maintainer</para> - </glossdef> - </glossentry> - </glossdiv> - -<!-- <glossdiv id='var-glossary-n'><title>N</title>--> -<!-- </glossdiv>--> - -<!-- <glossdiv id='var-glossary-o'><title>O</title>--> -<!-- </glossdiv>--> - - <glossdiv id='var-glossary-p'><title>P</title> - - <glossentry id='var-PACKAGE_ARCH'><glossterm>PACKAGE_ARCH</glossterm> - <glossdef> - <para>Architecture of resulting package</para> - </glossdef> - </glossentry> - - <glossentry id='var-PACKAGE_CLASSES'><glossterm>PACKAGE_CLASSES</glossterm> - <glossdef> - <para>List of resulting packages formats</para> - </glossdef> - </glossentry> - - <glossentry id='var-PACKAGE_DESCRIPTION'><glossterm>PACKAGE_DESCRIPTION</glossterm> - <glossdef> - <para>Long form description of binary package for packaging sytems such as ipkg, rpm or debian, inherits DESCRIPTION by default</para> - </glossdef> - </glossentry> - - <glossentry id='var-PACKAGE_EXTRA_ARCHS'><glossterm>PACKAGE_EXTRA_ARCHS</glossterm> - <glossdef> - <para>List of architectures compatible with device - CPU. Usable when build is done for few different - devices with misc processors (like XScale and - ARM926-EJS)</para> - </glossdef> - </glossentry> - - <glossentry id='var-PACKAGE_SUMMARY'><glossterm>PACKAGE_SUMMARY</glossterm> - <glossdef> - <para>Short (72 char suggested) Summary of binary package for packaging sytems such as ipkg, rpm or debian, inherits DESCRIPTION by default</para> - </glossdef> - </glossentry> - - - <glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm> - <glossdef> - <para>List of packages to be created from recipe. - The default value is "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev"</para> - </glossdef> - </glossentry> - - <glossentry id='var-PARALLEL_MAKE'><glossterm>PARALLEL_MAKE</glossterm> - <glossdef> - <para>Extra options that are passed to the make command during the - compile tasks. This is usually of the form '-j 4' where the number - represents the maximum number of parallel threads make can run.</para> - </glossdef> - </glossentry> - - <glossentry id='var-PN'><glossterm>PN</glossterm> - <glossdef> - <para>Name of package. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-PR'><glossterm>PR</glossterm> - <glossdef> - <para>Revision of package. The default value is "r0". - </para> - </glossdef> - </glossentry> - - <glossentry id='var-PV'><glossterm>PV</glossterm> - <glossdef> - <para>Version of package. - This is normally extracted from the recipe name, e.g. if the recipe is named - "expat_2.0.1.bb" then PV will be "2.0.1". PV is generally not overridden within - a recipe unless it is building an unstable version from a source code repository - (git, svn, etc.). - </para> - </glossdef> - </glossentry> - - <glossentry id='var-PE'><glossterm>PE</glossterm> - <glossdef> - <para> - Epoch of the package. The default value is "0". The field is used - to make upgrades possible when the versioning scheme changes in - some backwards incompatible way. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm> - <glossdef> - <para>If multiple recipes provide an item, this variable - determines which one should be given preference. It - should be set to the "$PN" of the recipe to be preferred.</para> - </glossdef> - </glossentry> - - <glossentry id='var-PREFERRED_VERSION'><glossterm>PREFERRED_VERSION</glossterm> - <glossdef> - <para> - If there are multiple versions of recipe available, this - variable determines which one should be given preference. It - should be set to the "$PV" of the recipe to be preferred. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-POKY_EXTRA_INSTALL'><glossterm>POKY_EXTRA_INSTALL</glossterm> - <glossdef> - <para>List of packages to be added to the image. This should - only be set in <filename>local.conf</filename>.</para> - </glossdef> - </glossentry> - - <glossentry id='var-POKYLIBC'><glossterm>POKYLIBC</glossterm> - <glossdef> - <para>Libc implementation selector - glibc, eglibc, or uclibc can be selected.</para> - </glossdef> - </glossentry> - - <glossentry id='var-POKYMODE'><glossterm>POKYMODE</glossterm> - <glossdef> - <para>Toolchain selector. It can be external toolchain - built from Poky or few supported combinations of - upstream GCC or CodeSourcery Labs toolchain.</para> - </glossdef> - </glossentry> - - </glossdiv> - -<!-- <glossdiv id='var-glossary-q'><title>Q</title>--> -<!-- </glossdiv>--> - - <glossdiv id='var-glossary-r'><title>R</title> - - <glossentry id='var-RCONFLICTS'><glossterm>RCONFLICTS</glossterm> - <glossdef> - <para>List of packages which conflict with this - one. Package will not be installed if they are not - removed first.</para> - </glossdef> - </glossentry> - - <glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm> - <glossdef> - <para> - A list of run-time dependencies for a package. These packages - need to be installed alongside the package it applies to so - the package will run correctly, an example is a perl script - which would rdepend on perl. Since this variable applies to - output packages there would usually be an override attached - to this variable like RDEPENDS_${PN}-dev. Names in this field - should be as they are in <link linkend='var-PACKAGES'>PACKAGES - </link> namespace before any renaming of the output package - by classes like debian.bbclass. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-ROOT_FLASH_SIZE'><glossterm>ROOT_FLASH_SIZE</glossterm> - <glossdef> - <para>Size of rootfs in megabytes</para> - </glossdef> - </glossentry> - - <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm> - <glossdef> - <para>List of packages which extend usability of the - package. Those packages will be automatically - installed but can be removed by user.</para> - </glossdef> - </glossentry> - - <glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm> - <glossdef> - <para>List of packages which are replaced with this - one.</para> - </glossdef> - </glossentry> - - </glossdiv> - - <glossdiv id='var-glossary-s'><title>S</title> - - <glossentry id='var-S'><glossterm>S</glossterm> - <glossdef> - <para> - Path to unpacked sources (by default: - "${<link linkend='var-WORKDIR'>WORKDIR</link>}/${<link linkend='var-PN'>PN</link>}-${<link linkend='var-PV'>PV</link>}") - </para> - </glossdef> - </glossentry> - - <glossentry id='var-SECTION'><glossterm>SECTION</glossterm> - <glossdef> - <para>Section where package should be put - used - by package managers</para> - </glossdef> - </glossentry> - - <glossentry id='var-SELECTED_OPTIMIZATION'><glossterm>SELECTED_OPTIMIZATION</glossterm> - <glossdef> - <para> - The variable takes the value of <link linkend='var-FULL_OPTIMIZATION'>FULL_OPTIMIZATION</link> - unless <link linkend='var-DEBUG_BUILD'>DEBUG_BUILD</link> = "1" in which case - <link linkend='var-DEBUG_OPTIMIZATION'>DEBUG_OPTIMIZATION</link> is used. - </para> - </glossdef> - </glossentry> - - - <glossentry id='var-SERIAL_CONSOLE'><glossterm>SERIAL_CONSOLE</glossterm> - <glossdef> - <para>Speed and device for serial port used to attach - serial console. This is given to kernel as "console" - param and after boot getty is started on that port - so remote login is possible.</para> - </glossdef> - </glossentry> - - <glossentry id='var-SSTATE_DIR'><glossterm>SSTATE_DIR</glossterm> - <glossdef> - <para>Directory for the shared state.</para> - </glossdef> - - </glossentry> - <glossentry id='var-SHELLCMDS'><glossterm>SHELLCMDS</glossterm> - <glossdef> - <para> - A list of commands to run within the a shell, used by <glossterm><link - linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm>. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-SITEINFO_ENDIANESS'><glossterm>SITEINFO_ENDIANESS</glossterm> - <glossdef> - <para> - Contains "le" for little-endian or "be" for big-endian depending - on the endian byte order of the target system. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-SITEINFO_BITS'><glossterm>SITEINFO_BITS</glossterm> - <glossdef> - <para> - Contains "32" or "64" depending on the number of bits for the - CPU of the target system. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm> - <glossdef> - <para>List of source files (local or remote ones)</para> - </glossdef> - </glossentry> - - <glossentry id='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'><glossterm>SRC_URI_OVERRIDES_PACKAGE_ARCH</glossterm> - <glossdef> - <para> - By default there is code which automatically detects whether - <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> - contains files which are machine specific and if this is the case it - automatically changes - <glossterm><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></glossterm>. - Setting this variable to "0" disables that behaviour. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-SRCDATE'><glossterm>SRCDATE</glossterm> - <glossdef> - <para> - Date of source code used to build package (if it was fetched - from SCM). - </para> - </glossdef> - </glossentry> - - <glossentry id='var-SRCREV'><glossterm>SRCREV</glossterm> - <glossdef> - <para> - Revision of source code used to build package (Subversion, - GIT, Bazaar only). - </para> - </glossdef> - </glossentry> - - <glossentry id='var-STAGING_KERNEL_DIR'><glossterm>STAGING_KERNEL_DIR</glossterm> - <glossdef> - <para> - Directory with kernel headers required to build out-of-tree - modules. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-STAMPS'><glossterm>STAMPS</glossterm> - <glossdef> - <para> - Directory (usually TMPDIR/stamps) with timestamps of - executed tasks. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm> - <glossdef> - <para>Short (72 char suggested) Summary of binary package for packaging systems such as ipkg, rpm or debian, inherits DESCRIPTION by default</para> - </glossdef> - </glossentry> - - </glossdiv> - - <glossdiv id='var-glossary-t'><title>T</title> - - <glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm> - <glossdef> - <para>The architecture of the device we're building for. - A number of values are possible but Poky primarily supports - "arm" and "i586".</para> - </glossdef> - </glossentry> - - <glossentry id='var-TARGET_CFLAGS'><glossterm>TARGET_CFLAGS</glossterm> - <glossdef> - <para> - Flags passed to C compiler for the target system. Evaluates to the same - as <link linkend='var-CFLAGS'>CFLAGS</link>. - </para> - </glossdef> - </glossentry> - - - <glossentry id='var-TARGET_FPU'><glossterm>TARGET_FPU</glossterm> - <glossdef> - <para>Method of handling FPU code. For FPU-less targets - (most of ARM cpus) it has to be set to "soft" otherwise - kernel emulation will get used which will result in - performance penalty.</para> - </glossdef> - </glossentry> - - <glossentry id='var-TARGET_OS'><glossterm>TARGET_OS</glossterm> - <glossdef> - <para>Type of target operating system. Can be "linux" - for glibc based system, "linux-uclibc" for uClibc. For - ARM/EABI targets there are also "linux-gnueabi" and - "linux-uclibc-gnueabi" values possible.</para> - </glossdef> - </glossentry> - - <glossentry id='var-TERMCMD'><glossterm>TERMCMD</glossterm> - <glossdef> - <para> - This command is used by bitbake to lauch a terminal window with a - shell. The shell is unspecified so the user's default shell is used. - By default it is set to <command>gnome-terminal</command> but it can - be any X11 terminal application or terminal multiplexers like screen. - </para> - </glossdef> - </glossentry> - - <glossentry id='var-TERMCMDRUN'><glossterm>TERMCMDRUN</glossterm> - <glossdef> - <para> - This command is similar to <glossterm><link - linkend='var-TERMCMD'>TERMCMD</link></glossterm> however instead of the users shell it runs the command specified by the <glossterm><link - linkend='var-SHELLCMDS'>SHELLCMDS</link></glossterm> variable. - </para> - </glossdef> - </glossentry> - - </glossdiv> - -<!-- <glossdiv id='var-glossary-u'><title>U</title>--> -<!-- </glossdiv>--> - -<!-- <glossdiv id='var-glossary-v'><title>V</title>--> -<!-- </glossdiv>--> - - <glossdiv id='var-glossary-w'><title>W</title> - - <glossentry id='var-WORKDIR'><glossterm>WORKDIR</glossterm> - <glossdef> - <para>Path to directory in tmp/work/ where package - will be built.</para> - </glossdef> - </glossentry> - - </glossdiv> - -<!-- <glossdiv id='var-glossary-x'><title>X</title>--> -<!-- </glossdiv>--> - -<!-- <glossdiv id='var-glossary-y'><title>Y</title>--> -<!-- </glossdiv>--> - -<!-- <glossdiv id='var-glossary-z'><title>Z</title>--> -<!-- </glossdiv>--> - -</glossary> -</appendix> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/ref-varlocality.xml b/documentation/poky-ref-manual/ref-varlocality.xml deleted file mode 100644 index 87ef0833d..000000000 --- a/documentation/poky-ref-manual/ref-varlocality.xml +++ /dev/null @@ -1,211 +0,0 @@ -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<appendix id='ref-varlocality'> - <title>Reference: Variable Locality (Distro, Machine, Recipe etc.)</title> - - <para> - Whilst most variables can be used in almost any context (.conf, .bbclass, - .inc or .bb file), variables are often associated with a particular - locality/context. This section describes some common associations. - </para> - - <section id='ref-varlocality-config-distro'> - <title>Distro Configuration</title> - - <itemizedlist> - <listitem> - <para><glossterm linkend='var-DISTRO'><link linkend='var-DISTRO'>DISTRO</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-DISTRO_NAME'><link linkend='var-DISTRO_NAME'>DISTRO_NAME</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-DISTRO_VERSION'><link linkend='var-DISTRO_VERSION'>DISTRO_VERSION</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-MAINTAINER'><link linkend='var-MAINTAINER'>MAINTAINER</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-PACKAGE_CLASSES'><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-TARGET_OS'><link linkend='var-TARGET_OS'>TARGET_OS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-TARGET_FPU'><link linkend='var-TARGET_FPU'>TARGET_FPU</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-POKYMODE'><link linkend='var-POKYMODE'>POKYMODE</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-POKYLIBC'><link linkend='var-POKYLIBC'>POKYLIBC</link></glossterm></para> - </listitem> - </itemizedlist> - </section> - - <section id='ref-varlocality-config-machine'> - <title>Machine Configuration</title> - - <itemizedlist> - <listitem> - <para><glossterm linkend='var-TARGET_ARCH'><link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-SERIAL_CONSOLE'><link linkend='var-SERIAL_CONSOLE'>SERIAL_CONSOLE</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-PACKAGE_EXTRA_ARCHS'><link linkend='var-PACKAGE_EXTRA_ARCHS'>PACKAGE_EXTRA_ARCHS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-IMAGE_FSTYPES'><link linkend='var-IMAGE_FSTYPES'>IMAGE_FSTYPES</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-ROOT_FLASH_SIZE'><link linkend='var-ROOT_FLASH_SIZE'>ROOT_FLASH_SIZE</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-MACHINE_FEATURES'><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-MACHINE_EXTRA_RDEPENDS'><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-MACHINE_EXTRA_RRECOMMENDS'><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-MACHINE_ESSENTIAL_RDEPENDS'><link linkend='var-MACHINE_ESSENTIAL_RDEPENDS'>MACHINE_ESSENTIAL_RDEPENDS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-MACHINE_ESSENTIAL_RRECOMMENDS'><link linkend='var-MACHINE_ESSENTIAL_RRECOMMENDS'>MACHINE_ESSENTIAL_RRECOMMENDS</link></glossterm></para> - </listitem> - </itemizedlist> - </section> - - <section id='ref-varlocality-config-local'> - <title>Local Configuration (local.conf)</title> - <itemizedlist> - <listitem> - <para><glossterm linkend='var-DISTRO'><link linkend='var-DISTRO'>DISTRO</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-MACHINE'><link linkend='var-MACHINE'>MACHINE</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-DL_DIR'><link linkend='var-DL_DIR'>DL_DIR</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-BBFILES'><link linkend='var-BBFILES'>BBFILES</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-IMAGE_FEATURES'><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-PACKAGE_CLASSES'><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-BB_NUMBER_THREADS'><link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-BBINCLUDELOGS'><link linkend='var-BBINCLUDELOGS'>BBINCLUDELOGS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm linkend='var-ENABLE_BINARY_LOCALE_GENERATION'><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link></glossterm></para> - </listitem> - </itemizedlist> - </section> - - <section id='ref-varlocality-recipe-required'> - <title>Recipe Variables - Required</title> - - <itemizedlist> - <listitem> - <para><glossterm><link linkend='var-DESCRIPTION'>DESCRIPTION</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-LICENSE'>LICENSE</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-SECTION'>SECTION</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-HOMEPAGE'>HOMEPAGE</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-AUTHOR'>AUTHOR</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm></para> - </listitem> - </itemizedlist> - </section> - - <section id='ref-varlocality-recipe-dependencies'> - <title>Recipe Variables - Dependencies</title> - - <itemizedlist> - <listitem> - <para><glossterm><link linkend='var-DEPENDS'>DEPENDS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-RDEPENDS'>RDEPENDS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-RRECOMMENDS'>RRECOMMENDS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-RCONFLICTS'>RCONFLICTS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-RREPLACES'>RREPLACES</link></glossterm></para> - </listitem> - </itemizedlist> - </section> - - <section id='ref-varlocality-recipe-paths'> - <title>Recipe Variables - Paths</title> - - <itemizedlist> - <listitem> - <para><glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-S'>S</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-FILES'>FILES</link></glossterm></para> - </listitem> - </itemizedlist> - </section> - - <section id='ref-varlocality-recipe-build'> - <title>Recipe Variables - Extra Build Information</title> - - <itemizedlist> - <listitem> - <para><glossterm><link - linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-EXTRA_OECMAKE'>EXTRA_OECMAKE</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-PACKAGES'>PACKAGES</link></glossterm></para> - </listitem> - <listitem> - <para><glossterm><link linkend='var-DEFAULT_PREFERENCE'>DEFAULT_PREFERENCE</link></glossterm></para> - </listitem> - </itemizedlist> - </section> -</appendix> -<!-- -vim: expandtab tw=80 ts=4 spell spelllang=en_gb ---> diff --git a/documentation/poky-ref-manual/resources.xml b/documentation/poky-ref-manual/resources.xml deleted file mode 100644 index dd4b58db5..000000000 --- a/documentation/poky-ref-manual/resources.xml +++ /dev/null @@ -1,164 +0,0 @@ -<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<appendix id='resources'> -<title>Contributing to Poky</title> - -<section id='resources-intro'> - <title>Introduction</title> - <para> - We're happy for people to experiment with Poky and there are a number of places to - find help if you run into difficulties or find bugs. To find out how to download - source code see the <link linkend='intro-getit'>Obtaining Poky</link> section of - the Introduction. - </para> -</section> - -<section id='resources-bugtracker'> - <title>Bugtracker</title> - - <para> - Problems with Poky should be reported using the Bugzilla application at - <ulink url='http://bugzilla.yoctoproject.org/'></ulink>. - </para> -</section> - -<section id='resources-mailinglist'> - <title>Mailing lists</title> - - <para> - To subscribe to the mailing lists click on the following URLs and follow the instructions: - </para> - - <itemizedlist> - <listitem><para> - <ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a Yocto Discussions - mailing list. - </para></listitem> - - <listitem><para> - <ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a Poky Discussions - mailing list. - </para></listitem> - - <listitem><para> - <ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink> for a mailing list - to receive offical Yocto Project announcements for developments and milestones. - </para></listitem> - </itemizedlist> - -</section> - -<section id='resources-irc'> - <title>Internet Relay Chat (IRC)</title> - - <para> - Two IRC channels on freenode are available for Yocto Project and Poky discussions: - <itemizedlist> - <listitem><para> - #yocto - </para></listitem> - - <listitem><para> - #poky - </para></listitem> - </itemizedlist> - </para> -</section> - -<section id='resources-links'> - <title>Links</title> - - <itemizedlist> - <listitem><para> - <ulink url='http://yoctoproject.org'>The Yocto Project website</ulink> - The home site - for Yocto Project. - </para></listitem> - <listitem><para> - <ulink url='http://pokylinux.org'>The Poky website</ulink> - The home site - for Poky Linux. - </para></listitem> - <listitem><para> - <ulink url='http://www.openedhand.com/'>OpenedHand</ulink> - The - original company behind Poky. - </para></listitem> - <listitem><para> - <ulink url='http://www.intel.com/'>Intel Corporation</ulink> - The - company who acquired OpenedHand in 2008. - </para></listitem> - - <listitem><para> - <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink> - - The upstream generic embedded distribution Poky derives - from (and contributes to). - </para></listitem> - <listitem><para> - <ulink url='http://developer.berlios.de/projects/bitbake/'>Bitbake</ulink> - - The tool used to process Poky metadata. - </para></listitem> - <listitem><para> - <ulink url='http://bitbake.berlios.de/manual/'>BitBake User - Manual</ulink> - A comprehensive guide to the BitBake tool. - </para></listitem> - <listitem><para> - <ulink url='http://pimlico-project.org/'>Pimlico</ulink> - A - suite of lightweight Personal Information Management (PIM) - applications designed primarily for handheld and mobile - devices. - </para></listitem> - <listitem><para> - <ulink url='http://fabrice.bellard.free.fr/qemu/'>QEMU</ulink> - - An open source machine emulator and virtualizer. - </para></listitem> - </itemizedlist> -</section> - -<section id='resources-contributions'> - <title>Contributions</title> - - <para> - Contributions to Poky are very welcome. Patches should be sent to the Poky mailing list along with a Signed-off-by: line in the same style as the Linux kernel. Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1: - </para> - - <programlisting> - Developer's Certificate of Origin 1.1 - - By making a contribution to this project, I certify that: - - (a) The contribution was created in whole or in part by me and I - have the right to submit it under the open source license - indicated in the file; or - - (b) The contribution is based upon previous work that, to the best - of my knowledge, is covered under an appropriate open source - license and I have the right under that license to submit that - work with modifications, whether created in whole or in part - by me, under the same open source license (unless I am - permitted to submit under a different license), as indicated - in the file; or - - (c) The contribution was provided directly to me by some other - person who certified (a), (b) or (c) and I have not modified - it. - - (d) I understand and agree that this project and the contribution - are public and that a record of the contribution (including all - personal information I submit with it, including my sign-off) is - maintained indefinitely and may be redistributed consistent with - this project or the open source license(s) involved. -</programlisting> - - <para> - A Poky contributions tree (poky-contrib, git://git.yoctoproject.org/poky-contrib.git) - exists for people to stage contributions in, for regular contributors. - If people desire such access, please ask on the mailing list. Usually - access will be given to anyone with a proven track record of good patches. - </para> - -</section> - - -</appendix> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-1.png b/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-1.png Binary files differdeleted file mode 100644 index 4e92012af..000000000 --- a/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-1.png +++ /dev/null diff --git a/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-2.png b/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-2.png Binary files differdeleted file mode 100644 index 2c9bfb3bb..000000000 --- a/documentation/poky-ref-manual/screenshots/ss-anjuta-poky-2.png +++ /dev/null diff --git a/documentation/poky-ref-manual/screenshots/ss-oprofile-viewer.png b/documentation/poky-ref-manual/screenshots/ss-oprofile-viewer.png Binary files differdeleted file mode 100644 index fa7d1dfa4..000000000 --- a/documentation/poky-ref-manual/screenshots/ss-oprofile-viewer.png +++ /dev/null diff --git a/documentation/poky-ref-manual/screenshots/ss-sato.png b/documentation/poky-ref-manual/screenshots/ss-sato.png Binary files differdeleted file mode 100644 index 5a0570924..000000000 --- a/documentation/poky-ref-manual/screenshots/ss-sato.png +++ /dev/null diff --git a/documentation/poky-ref-manual/style.css b/documentation/poky-ref-manual/style.css deleted file mode 100644 index 138d485f5..000000000 --- a/documentation/poky-ref-manual/style.css +++ /dev/null @@ -1,958 +0,0 @@ -/* - Generic XHTML / DocBook XHTML CSS Stylesheet. - - Browser wrangling and typographic design by - Oyvind Kolas / pippin@gimp.org - - Customised for Poky by - Matthew Allum / mallum@o-hand.com - - Thanks to: - Liam R. E. Quin - William Skaggs - Jakub Steiner - - Structure - --------- - - The stylesheet is divided into the following sections: - - Positioning - Margins, paddings, width, font-size, clearing. - Decorations - Borders, style - Colors - Colors - Graphics - Graphical backgrounds - Nasty IE tweaks - Workarounds needed to make it work in internet explorer, - currently makes the stylesheet non validating, but up until - this point it is validating. - Mozilla extensions - Transparency for footer - Rounded corners on boxes - -*/ - - - /*************** / - / Positioning / -/ ***************/ - -body { - font-family: Verdana, Sans, sans-serif; - - min-width: 640px; - width: 80%; - margin: 0em auto; - padding: 2em 5em 5em 5em; - color: #333; -} - -.reviewer { - color: red; -} - -h1,h2,h3,h4,h5,h6,h7 { - font-family: Arial, Sans; - color: #00557D; - clear: both; -} - -h1 { - font-size: 2em; - text-align: left; - padding: 0em 0em 0em 0em; - margin: 2em 0em 0em 0em; -} - -h2.subtitle { - margin: 0.10em 0em 3.0em 0em; - padding: 0em 0em 0em 0em; - font-size: 1.8em; - padding-left: 20%; - font-weight: normal; - font-style: italic; -} - -h2 { - margin: 2em 0em 0.66em 0em; - padding: 0.5em 0em 0em 0em; - font-size: 1.5em; - font-weight: bold; -} - -h3.subtitle { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; - font-size: 142.14%; - text-align: right; -} - -h3 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 140%; - font-weight: bold; -} - -h4 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 120%; - font-weight: bold; -} - -h5 { - margin: 1em 0em 0.5em 0em; - padding: 1em 0em 0em 0em; - font-size: 110%; - font-weight: bold; -} - -h6 { - margin: 1em 0em 0em 0em; - padding: 1em 0em 0em 0em; - font-size: 80%; - font-weight: bold; -} - -.authorgroup { - background-color: transparent; - background-repeat: no-repeat; - padding-top: 256px; - background-image: url("figures/poky-ref-manual.png"); - background-position: left top; - margin-top: -256px; - padding-right: 50px; - margin-left: 50px; - text-align: right; - width: 600px; -} - -h3.author { - margin: 0em 0me 0em 0em; - padding: 0em 0em 0em 0em; - font-weight: normal; - font-size: 100%; - color: #333; - clear: both; -} - -.author tt.email { - font-size: 66%; -} - -.titlepage hr { - width: 0em; - clear: both; -} - -.revhistory { - padding-top: 2em; - clear: both; -} - -.toc, -.list-of-tables, -.list-of-examples, -.list-of-figures { - padding: 1.33em 0em 2.5em 0em; - color: #00557D; -} - -.toc p, -.list-of-tables p, -.list-of-figures p, -.list-of-examples p { - padding: 0em 0em 0em 0em; - padding: 0em 0em 0.3em; - margin: 1.5em 0em 0em 0em; -} - -.toc p b, -.list-of-tables p b, -.list-of-figures p b, -.list-of-examples p b{ - font-size: 100.0%; - font-weight: bold; -} - -.toc dl, -.list-of-tables dl, -.list-of-figures dl, -.list-of-examples dl { - margin: 0em 0em 0.5em 0em; - padding: 0em 0em 0em 0em; -} - -.toc dt { - margin: 0em 0em 0em 0em; - padding: 0em 0em 0em 0em; -} - -.toc dd { - margin: 0em 0em 0em 2.6em; - padding: 0em 0em 0em 0em; -} - -div.glossary dl, -div.variablelist dl { -} - -.glossary dl dt, -.variablelist dl dt, -.variablelist dl dt span.term { - font-weight: normal; - width: 20em; - text-align: right; -} - -.variablelist dl dt { - margin-top: 0.5em; -} - -.glossary dl dd, -.variablelist dl dd { - margin-top: -1em; - margin-left: 25.5em; -} - -.glossary dd p, -.variablelist dd p { - margin-top: 0em; - margin-bottom: 1em; -} - - -div.calloutlist table td { - padding: 0em 0em 0em 0em; - margin: 0em 0em 0em 0em; -} - -div.calloutlist table td p { - margin-top: 0em; - margin-bottom: 1em; -} - -div p.copyright { - text-align: left; -} - -div.legalnotice p.legalnotice-title { - margin-bottom: 0em; -} - -p { - line-height: 1.5em; - margin-top: 0em; - -} - -dl { - padding-top: 0em; -} - -hr { - border: solid 1px; -} - - -.mediaobject, -.mediaobjectco { - text-align: center; -} - -img { - border: none; -} - -ul { - padding: 0em 0em 0em 1.5em; -} - -ul li { - padding: 0em 0em 0em 0em; -} - -ul li p { - text-align: left; -} - -table { - width :100%; -} - -th { - padding: 0.25em; - text-align: left; - font-weight: normal; - vertical-align: top; -} - -td { - padding: 0.25em; - vertical-align: top; -} - -p a[id] { - margin: 0px; - padding: 0px; - display: inline; - background-image: none; -} - -a { - text-decoration: underline; - color: #444; -} - -pre { - overflow: auto; -} - -a:hover { - text-decoration: underline; - /*font-weight: bold;*/ -} - - -div.informalfigure, -div.informalexample, -div.informaltable, -div.figure, -div.table, -div.example { - margin: 1em 0em; - padding: 1em; - page-break-inside: avoid; -} - - -div.informalfigure p.title b, -div.informalexample p.title b, -div.informaltable p.title b, -div.figure p.title b, -div.example p.title b, -div.table p.title b{ - padding-top: 0em; - margin-top: 0em; - font-size: 100%; - font-weight: normal; -} - -.mediaobject .caption, -.mediaobject .caption p { - text-align: center; - font-size: 80%; - padding-top: 0.5em; - padding-bottom: 0.5em; -} - -.epigraph { - padding-left: 55%; - margin-bottom: 1em; -} - -.epigraph p { - text-align: left; -} - -.epigraph .quote { - font-style: italic; -} -.epigraph .attribution { - font-style: normal; - text-align: right; -} - -span.application { - font-style: italic; -} - -.programlisting { - font-family: monospace; - font-size: 80%; - white-space: pre; - margin: 1.33em 0em; - padding: 1.33em; -} - -.tip, -.warning, -.caution, -.note { - margin-top: 1em; - margin-bottom: 1em; - -} - -/* force full width of table within div */ -.tip table, -.warning table, -.caution table, -.note table { - border: none; - width: 100%; -} - - -.tip table th, -.warning table th, -.caution table th, -.note table th { - padding: 0.8em 0.0em 0.0em 0.0em; - margin : 0em 0em 0em 0em; -} - -.tip p, -.warning p, -.caution p, -.note p { - margin-top: 0.5em; - margin-bottom: 0.5em; - padding-right: 1em; - text-align: left; -} - -.acronym { - text-transform: uppercase; -} - -b.keycap, -.keycap { - padding: 0.09em 0.3em; - margin: 0em; -} - -.itemizedlist li { - clear: none; -} - -.filename { - font-size: medium; - font-family: Courier, monospace; -} - - -div.navheader, div.heading{ - position: absolute; - left: 0em; - top: 0em; - width: 100%; - background-color: #cdf; - width: 100%; -} - -div.navfooter, div.footing{ - position: fixed; - left: 0em; - bottom: 0em; - background-color: #eee; - width: 100%; -} - - -div.navheader td, -div.navfooter td { - font-size: 66%; -} - -div.navheader table th { - /*font-family: Georgia, Times, serif;*/ - /*font-size: x-large;*/ - font-size: 80%; -} - -div.navheader table { - border-left: 0em; - border-right: 0em; - border-top: 0em; - width: 100%; -} - -div.navfooter table { - border-left: 0em; - border-right: 0em; - border-bottom: 0em; - width: 100%; -} - -div.navheader table td a, -div.navfooter table td a { - color: #777; - text-decoration: none; -} - -/* normal text in the footer */ -div.navfooter table td { - color: black; -} - -div.navheader table td a:visited, -div.navfooter table td a:visited { - color: #444; -} - - -/* links in header and footer */ -div.navheader table td a:hover, -div.navfooter table td a:hover { - text-decoration: underline; - background-color: transparent; - color: #33a; -} - -div.navheader hr, -div.navfooter hr { - display: none; -} - - -.qandaset tr.question td p { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; -} - -.qandaset tr.answer td p { - margin: 0em 0em 1em 0em; - padding: 0em 0em 0em 0em; -} -.answer td { - padding-bottom: 1.5em; -} - -.emphasis { - font-weight: bold; -} - - - /************* / - / decorations / -/ *************/ - -.titlepage { -} - -.part .title { -} - -.subtitle { - border: none; -} - -/* -h1 { - border: none; -} - -h2 { - border-top: solid 0.2em; - border-bottom: solid 0.06em; -} - -h3 { - border-top: 0em; - border-bottom: solid 0.06em; -} - -h4 { - border: 0em; - border-bottom: solid 0.06em; -} - -h5 { - border: 0em; -} -*/ - -.programlisting { - border: solid 1px; -} - -div.figure, -div.table, -div.informalfigure, -div.informaltable, -div.informalexample, -div.example { - border: 1px solid; -} - - - -.tip, -.warning, -.caution, -.note { - border: 1px solid; -} - -.tip table th, -.warning table th, -.caution table th, -.note table th { - border-bottom: 1px solid; -} - -.question td { - border-top: 1px solid black; -} - -.answer { -} - - -b.keycap, -.keycap { - border: 1px solid; -} - - -div.navheader, div.heading{ - border-bottom: 1px solid; -} - - -div.navfooter, div.footing{ - border-top: 1px solid; -} - - /********* / - / colors / -/ *********/ - -body { - color: #333; - background: white; -} - -a { - background: transparent; -} - -a:hover { - background-color: #dedede; -} - - -h1, -h2, -h3, -h4, -h5, -h6, -h7, -h8 { - background-color: transparent; -} - -hr { - border-color: #aaa; -} - - -.tip, .warning, .caution, .note { - border-color: #aaa; -} - - -.tip table th, -.warning table th, -.caution table th, -.note table th { - border-bottom-color: #aaa; -} - - -.warning { - background-color: #fea; -} - -.caution { - background-color: #fea; -} - -.tip { - background-color: #eff; -} - -.note { - background-color: #dfc; -} - -.glossary dl dt, -.variablelist dl dt, -.variablelist dl dt span.term { - color: #044; -} - -div.figure, -div.table, -div.example, -div.informalfigure, -div.informaltable, -div.informalexample { - border-color: #aaa; -} - -pre.programlisting { - color: black; - background-color: #fff; - border-color: #aaa; - border-width: 2px; -} - -.guimenu, -.guilabel, -.guimenuitem { - background-color: #eee; -} - - -b.keycap, -.keycap { - background-color: #eee; - border-color: #999; -} - - -div.navheader { - border-color: black; -} - - -div.navfooter { - border-color: black; -} - - - /*********** / - / graphics / -/ ***********/ - -/* -body { - background-image: url("images/body_bg.jpg"); - background-attachment: fixed; -} - -.navheader, -.note, -.tip { - background-image: url("images/note_bg.jpg"); - background-attachment: fixed; -} - -.warning, -.caution { - background-image: url("images/warning_bg.jpg"); - background-attachment: fixed; -} - -.figure, -.informalfigure, -.example, -.informalexample, -.table, -.informaltable { - background-image: url("images/figure_bg.jpg"); - background-attachment: fixed; -} - -*/ -h1, -h2, -h3, -h4, -h5, -h6, -h7{ -} - -div.preface .titlepage .title, -div.colophon .title, -div.chapter .titlepage .title { - background-image: url("images/title-bg.png"); - background-position: bottom; - background-repeat: repeat-x; -} - -div.section div.section .titlepage .title, -div.sect2 .titlepage .title { - background: none; -} - - -h1.title { - background-color: transparent; - background-image: url("poky-ref-manual.png"); - background-repeat: no-repeat; - height: 256px; - text-indent: -9000px; - overflow:hidden; -} - -h2.subtitle { - background-color: transparent; - text-indent: -9000px; - overflow:hidden; - width: 0px; - display: none; -} - - /*************************************** / - / pippin.gimp.org specific alterations / -/ ***************************************/ - -/* -div.heading, div.navheader { - color: #777; - font-size: 80%; - padding: 0; - margin: 0; - text-align: left; - position: absolute; - top: 0px; - left: 0px; - width: 100%; - height: 50px; - background: url('/gfx/heading_bg.png') transparent; - background-repeat: repeat-x; - background-attachment: fixed; - border: none; -} - -div.heading a { - color: #444; -} - -div.footing, div.navfooter { - border: none; - color: #ddd; - font-size: 80%; - text-align:right; - - width: 100%; - padding-top: 10px; - position: absolute; - bottom: 0px; - left: 0px; - - background: url('/gfx/footing_bg.png') transparent; -} -*/ - - - - /****************** / - / nasty ie tweaks / -/ ******************/ - -/* -div.heading, div.navheader { - width:expression(document.body.clientWidth + "px"); -} - -div.footing, div.navfooter { - width:expression(document.body.clientWidth + "px"); - margin-left:expression("-5em"); -} -body { - padding:expression("4em 5em 0em 5em"); -} -*/ - - /**************************************** / - / mozilla vendor specific css extensions / -/ ****************************************/ -/* -div.navfooter, div.footing{ - -moz-opacity: 0.8em; -} - -div.figure, -div.table, -div.informalfigure, -div.informaltable, -div.informalexample, -div.example, -.tip, -.warning, -.caution, -.note { - -moz-border-radius: 0.5em; -} - -b.keycap, -.keycap { - -moz-border-radius: 0.3em; -} -*/ - -table tr td table tr td { - display: none; -} - - -hr { - display: none; -} - -table { - border: 0em; -} - - .photo { - float: right; - margin-left: 1.5em; - margin-bottom: 1.5em; - margin-top: 0em; - max-width: 17em; - border: 1px solid gray; - padding: 3px; - background: white; -} - .seperator { - padding-top: 2em; - clear: both; - } - - #validators { - margin-top: 5em; - text-align: right; - color: #777; - } - @media print { - body { - font-size: 8pt; - } - .noprint { - display: none; - } - } - - -.tip, -.note { - background: #666666; - color: #fff; - padding: 20px; - margin: 20px; -} - -.tip h3, -.note h3 { - padding: 0em; - margin: 0em; - font-size: 2em; - font-weight: bold; - color: #fff; -} - -.tip a, -.note a { - color: #fff; - text-decoration: underline; -} diff --git a/documentation/poky-ref-manual/usingpoky.xml b/documentation/poky-ref-manual/usingpoky.xml deleted file mode 100644 index fc4fbdc6c..000000000 --- a/documentation/poky-ref-manual/usingpoky.xml +++ /dev/null @@ -1,348 +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='usingpoky'> -<title>Using Poky</title> - - <para> - This section gives an overview of the components that make up Poky - followed by information about running poky builds and dealing with any - problems that may arise. - </para> - -<section id='usingpoky-components'> - <title>Poky Overview</title> - - <para> - The BitBake task executor together with various types of configuration files form the core of Poky. - This section overviews the BitBake task executor and the - configuration files by describing what they are used for and they they interact. - </para> - - <para> - BitBake handles the parsing and execution of the data files. - The data itself is of various types: - <itemizedlist> - <listitem><para>Recipes: Provides details about particular pieces of software</para></listitem> - <listitem><para>Class Data: An abstraction of common build information (e.g. how to build a - Linux kernel).</para></listitem> - <listitem><para>Configuration Data: Defines machine-specific settings, policy decisions, etc. - Configuration data acts a the glue to bind everything together.</para></listitem> - </itemizedlist> - </para> - - <para> - BitBake knows how to combine multiple data sources together and refers to each data source - as a <link linkend='usingpoky-changes-layers'>'layer'</link>. - </para> - - <para> - Following are some brief details on these core components. - For more detailed information on these components see the - <link linkend='ref-structure'>'Reference: Directory Structure'</link> - appendix. - </para> - - <section id='usingpoky-components-bitbake'> - <title>BitBake</title> - - <para> - BitBake is the tool at the heart of Poky and is responsible - for parsing the metadata, generating a list of tasks from it - and then executing them. To see a list of the options BitBake - supports look at 'bitbake --help'. - </para> - - <para> - The most common usage for BitBake is <filename>bitbake <packagename></filename>, where - packagename is the name of the package you want to build (referred to as the 'target' - in this manual). - The target often equates to the first part of a <filename>.bb</filename> filename. - So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you - might type the following: - <literallayout class='monospaced'> - $ bitbake matchbox-desktop - </literallayout> - Several different versions of <filename>matchbox-desktop</filename> might exist. - BitBake chooses the one selected by the distribution configuration. - You can get more details about how BitBake chooses between different versions - and providers in the <link linkend='ref-bitbake-providers'> - 'Preferences and Providers'</link> section. - </para> - <para> - BitBake also tries to execute any dependent tasks first. - So for example, before building <filename>matchbox-desktop</filename> BitBake - would build a cross compiler and glibc if they had not already been built. - </para> - - </section> - - <section id='usingpoky-components-metadata'> - <title>Metadata (Recipes)</title> - - <para> - The <filename>.bb</filename> files are usually referred to as 'recipes'. - In general, a recipe contains information about a single piece of software such - as from where to download the source patches (if any are needed), which special - configuration options to apply, how to compile the source files, and how to - package the compiled output. - </para> - - <para> - The term 'package' can also be used to describe recipes. - However, since the same word is used for the packaged output from Poky (i.e. .ipk or .deb - files), this document avoids it. - </para> - - </section> - - <section id='usingpoky-components-classes'> - <title>Classes</title> - - <para> - Class files (<filename>.bbclass</filename>) contain information that is useful to share - between metadata files. - An example is the autotools class, which contains - common settings for any application that autotools uses. - The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details - about common classes and how to use them. - </para> - </section> - - <section id='usingpoky-components-configuration'> - <title>Configuration</title> - - <para> - The configuration files (<filename>.conf</filename>) define various configuration variables - that govern what Poky does. - These files are split into several areas that define machine configuration options, - distribution configuration options, compiler tuning options, general common configuration - options and user configuration options (<filename>local.conf</filename>). - </para> - </section> - -</section> - - -<section id='usingpoky-build'> - <title>Running a Build</title> - - <para> - First the Poky build environment needs to be set up using the following command: - </para> - <para> - <literallayout class='monospaced'> - $ source poky-init-build-env [build_dir] - </literallayout> - </para> - <para> - The build_dir is the dir containing all the build's object files. The default - build dir is poky-dir/build. A different build_dir can be used for each of the targets. - For example, ~/build/x86 for a qemux86 target, and ~/build/arm for a qemuarm target. - Please refer to <link linkend="structure-core-script">poky-init-build-env</link> - for more detailed information. - </para> - <para> - Once the Poky build environment is set up, a target can be built using: - </para> - <para> - <literallayout class='monospaced'> - $ bitbake <target> - </literallayout> - </para> - <para> - The target is the name of the recipe you want to build. - Common targets are the images in <filename>meta/recipes-core/images</filename>, - <filename>/meta/recipes-sato/images</filename>, etc. - Or, the target can be the name of a recipe for a specific piece of software such as - <application>busybox</application>. - For more details about the standard images available, see the - <link linkend="ref-images">'Reference: Images'</link> appendix. - </para> - <note> - Building an image without GNU Public License Version 3 (GPLv3) components is - only supported for minimal and base images. - See <link linkend='ref-images'>'Reference: Images'</link> for more information. - </note> - <note> - When building an image using GPL components you need to maintain your original - settings and not switch back and forth applying different versions of the GNU - Public License. If you rebuild using different versions of GPL you can get - dependency errors due to some components not being rebuilt. - </note> -</section> - -<section id='usingpoky-install'> - <title>Installing and Using the Result</title> - - <para> - Once an image has been built it often needs to be installed. - The images/kernels built by Poky are placed in the - <filename class="directory">tmp/deploy/images</filename> directory. - Running qemux86 and qemuarm images is described in the - 'Using Pre-Built Binaries and QEMU' section of the Yocto Project Quick Start. - See <ulink url="http://www.yoctoproject.org//docs/yocto-quick-start/yocto-project-qs.html"/> - for the guide. - For information about how to install these images, see the documentation for your - particular board/machine. - </para> - -</section> - -<section id='usingpoky-debugging'> - <title>Debugging Build Failures</title> - - <para> - The exact method for debugging Poky depends on the nature of the - problem and on the system's area from which the bug originates. - Standard debugging practices such as comparison against the last - known working version with examination of the changes and the re-application of steps - to identify the one causing the problem are - valid for Poky just as they are for any other system. - Even though it is impossible to detail every possible potential failure, - here are some general tips to aid in debugging: - </para> - - <section id='usingpoky-debugging-taskfailures'> - <title>Task Failures</title> - - <para>The log file for shell tasks is available in <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>. - For example, the "compile" task of busybox 1.01 on the ARM spitz machine might be - <filename>tmp/work/armv5te-poky-linux-gnueabi/busybox-1.01/temp/log.do_compile.1234</filename>. - To see what BitBake runs to generate that log, look at the corresponding - <filename>run.do_taskname.pid </filename> file located in the same directory. - </para> - - <para> - Presently, the output from python tasks is sent directly to the console. - </para> - </section> - - <section id='usingpoky-debugging-taskrunning'> - <title>Running Specific Tasks</title> - - <para> - Any given package consists of a set of tasks. - In most cases the series is: fetch, unpack, patch, configure, - compile, install, package, package_write and build. - The default task is "build" and any tasks on which it depends build first - hence, - the standard BitBake behaviour. - Some tasks exist, such as devshell, that are not part of the default build chain. - If you wish to run a task that is not part of the default build chain you can use the - "-c" option in BitBake as follows: - <literallayout class='monospaced'> - $ bitbake matchbox-desktop -c devshell - </literallayout> - </para> - - <para> - If you wish to rerun a task use the force option "-f". - For example, the following sequence forces recompilation after changing files in the - working directory. - </para> - - <para> - <literallayout class='monospaced'> - $ bitbake matchbox-desktop - [make some changes to the source code in the WORKDIR] - $ bitbake matchbox-desktop -c compile -f - $ bitbake matchbox-desktop - </literallayout> - </para> - - <para> - This sequence first builds <filename>matchbox-desktop</filename> and then recompiles it. - The last command reruns all tasks, basically the packaging tasks, after the compile. - BitBake recognizes that the "compile" task was rerun and therefore understands that the other - tasks also need to be run again. - </para> - - <para> - You can view a list of tasks in a given package by running the "listtasks" task. - For example: - <literallayout class='monospaced'> - $ bitbake matchbox-desktop -c - </literallayout> - The results are in the file <filename>${WORKDIR}/temp/log.do_listtasks</filename>. - </para> - </section> - - <section id='usingpoky-debugging-dependencies'> - <title>Dependency Graphs</title> - - <para> - Sometimes it can be hard to see why BitBake wants to build some other packages before a given - package you've specified. - The <filename>bitbake -g targetname</filename> command creates the <filename>depends.dot</filename> and - <filename>task-depends.dot</filename> files in the current directory. - These files show the package and task dependencies and are useful for debugging problems. - You can use the <filename>bitbake -g -u depexp targetname</filename> command to display the results - in a more human-readable form. - </para> - </section> - - <section id='usingpoky-debugging-bitbake'> - <title>General BitBake Problems</title> - - <para> - You can see debug output from BitBake by using the "-D" option. - The debug output gives more information about what BitBake - is doing and the reason behind it. - Each "-D" option you use increases the logging level. - The most common usage is <filename>-DDD</filename>. - </para> - - <para> - The output from <filename>bitbake -DDD -v targetname</filename> can reveal why - BitBake chose a certain version of a package or why BitBake - picked a certain provider. - This command could also help you in a situation where you think BitBake did something - unexpected. - </para> - </section> - - <section id='usingpoky-debugging-buildfile'> - <title>Building with No Dependencies</title> - <para> - If you really want to build a specific <filename>.bb</filename> file, you can use - the command form <filename>bitbake -b somepath/somefile.bb</filename>. - This command form does not check for dependencies so you should use it - only when you know its dependencies already exist. - You can also specify fragments of the filename and BitBake checks for a unique match. - </para> - </section> - - <section id='usingpoky-debugging-variables'> - <title>Variables</title> - <para> - The "-e" option dumps the resulting environment for - either the configuration (no package specified) or for a - specific package when specified with the "-b" option. - </para> - </section> - - <section id='usingpoky-debugging-others'> - <title>Other Tips</title> - <tip> - <para> - When adding new packages it is worth watching for undesireable items making their way - into compiler command lines. - For example, you do not want references to local system files like - <filename>/usr/lib/</filename> or <filename>/usr/include/</filename>. - </para> - </tip> - <tip> - <para> - If you want to remove the psplash boot splashscreen, add "psplash=false" - to the kernel command line. - Doing so prevents psplash from loading thus allowing you to see the console. - It is also possible to switch out of the splashscreen by - switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus). - </para> - </tip> - </section> -</section> - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/poky-ref-manual/white-on-black-yp.png b/documentation/poky-ref-manual/white-on-black-yp.png Binary files differdeleted file mode 100755 index 81f801d0e..000000000 --- a/documentation/poky-ref-manual/white-on-black-yp.png +++ /dev/null |
