diff options
| author |   Richard Purdie <richard.purdie@linuxfoundation.org> | 2011-04-20 14:20:19 +0100 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2011-04-20 15:49:17 +0100 |
| commit | 50021cba20a09b1ed685db5466f940b17d4880ac (patch) | |
| tree | 3bdafb797e6466ad58727b002f1235933010ab11 | |
| parent | 690e87a2ffe8caa16379be26eb356c5bded17c1f (diff) | |
| download | openembedded-core-contrib-50021cba20a09b1ed685db5466f940b17d4880ac.tar.gz | |
Drop documentation directory, this is replaced by the new yocto-docs repository
87 files changed, 0 insertions, 18286 deletions
diff --git a/documentation/adt-manual/Makefile b/documentation/adt-manual/Makefile deleted file mode 100644 index 74e35bcdeb..0000000000 --- a/documentation/adt-manual/Makefile +++ /dev/null @@ -1,42 +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 adt-manual.xml ../template - -## -# These URI should be rewritten by your distribution's xml catalog to -# match your localy installed XSL stylesheets. - -html: -# See http://www.sagehill.net/docbookxsl/HtmlOutput.html - -# xsltproc $(XSLTOPTS) -o adt-manual.html $(XSL_XHTML_URI) adt-manual.xml - xsltproc $(XSLTOPTS) -o adt-manual.html adt-manual-customization.xsl adt-manual.xml - -tarball: html - tar -cvzf adt-manual.tgz adt-manual.html adt-manual.pdf style.css figures/adt-title.png figures/yocto-project-transp.png - -validate: - xmllint --postvalid --xinclude --noout adt-manual.xml - -OUTPUTS = adt-manual.tgz adt-manual.html adt-manual.pdf -SOURCES = *.png *.xml *.css - -publish: - scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/ - -clean: - rm -f $(OUTPUTS) diff --git a/documentation/adt-manual/adt-command.xml b/documentation/adt-manual/adt-command.xml deleted file mode 100644 index e57c15a983..0000000000 --- a/documentation/adt-manual/adt-command.xml +++ /dev/null @@ -1,66 +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='using-the-command-line'> -<title>Using the Command Line</title> - <para> - Recall that earlier we talked about how to use an existing toolchain - tarball that had been installed into <filename>/opt/poky</filename>, - which is outside of the Poky build environment - (see <xref linkend='using-an-existing-toolchain-tarball'> - “Using an Existing Toolchain Tarball”)</xref>. - And, that sourcing your architecture-specific environment setup script - initializes a suitable development environment. - This setup occurs by adding the compiler, QEMU scripts, QEMU binary, - a special version of <filename>pkgconfig</filename> and other useful - utilities to the <filename>PATH</filename> variable. - Variables to assist pkgconfig and autotools are also defined so that, - for example, <filename>configure.sh</filename> can find pre-generated - test results for tests that need target hardware on which to run. - These conditions allow you to easily use the toolchain outside of the - Poky build environment on both autotools-based projects and - makefile-based projects. - </para> - -<section id='autotools-based-projects'> -<title>Autotools-Based Projects</title> - <para> - For an autotools-based project you can use the cross-toolchain by just - passing the appropriate host option to <filename>configure.sh</filename>. - The host option you use is derived from the name of the environment setup - script in <filename>/opt/poky</filename> resulting from unpacking the - cross-toolchain tarball. - For example, the host option for an ARM-based target that uses the GNU EABI - is <filename>armv5te-poky-linux-gnueabi</filename>. - Note that the name of the script is - <filename>environment-setup-armv5te-poky-linux-gnueabi</filename>. - Thus, the following command works: - <literallayout class='monospaced'> - $ configure ‐‐host-armv5te-poky-linux-gnueabi ‐‐with-libtool-sysroot=<sysroot-dir> - </literallayout> - </para> - <para> - This single command updates your project and rebuilds it using the appropriate - cross-toolchain tools. - </para> -</section> - -<section id='makefile-based-projects'> -<title>Makefile-Based Projects</title> - <para> - For a makefile-based project you use the cross-toolchain by making sure - the tools are used. - You can do this as follows: - <literallayout class='monospaced'> - CC=arm-poky-linux-gnueabi-gcc - LD=arm-poky-linux-gnueabi-ld - CFLAGS=”${CFLAGS} ‐‐sysroot=<sysroot-dir>” - CXXFLAGS=”${CXXFLAGS} ‐‐sysroot=<sysroot-dir>” - </literallayout> - </para> -</section> - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/adt-manual/adt-eclipse.xml b/documentation/adt-manual/adt-eclipse.xml deleted file mode 100644 index ee305fe585..0000000000 --- a/documentation/adt-manual/adt-eclipse.xml +++ /dev/null @@ -1,435 +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='adt-eclipse'> -<title>Working Within Eclipse</title> - <para> - The Eclipse IDE is a popular development environment and it fully supports - development using Yocto Project. - When you install and configure the Eclipse Yocto Project Plug-in into - the Eclipse IDE you maximize your Yocto Project design experience. - Installing and configuring the Plug-in results in an environment that - has extensions specifically designed to let you more easily develop software. - These extensions allow for cross-compilation and deployment and execution of - your output into a QEMU emulation session. - You can also perform cross-debugging and profiling. - The environment also has a suite of tools that allows you to perform - remote profiling, tracing, collection of power data, collection of - latency data, and collection of performance data. - </para> - <para> - This section describes how to install and configure the Eclipse IDE - Yocto Plug-in and how to use it to develop your Yocto Project. - </para> - -<section id='setting-up-the-eclipse-ide'> - <title>Setting Up the Eclipse IDE</title> - <para> - To develop within the Eclipse IDE you need to do the following: - <orderedlist> - <listitem><para>Be sure the optimal version of Eclipse IDE - is installed.</para></listitem> - <listitem><para>Install required Eclipse plug-ins prior to installing - the Eclipse Yocto Plug-in.</para></listitem> - <listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem> - </orderedlist> - </para> - - <section id='installing-eclipse-ide'> - <title>Installing Eclipse IDE</title> - <para> - It is recommended that you have the Helios 3.6.1 version of the - Eclipse IDE installed on your development system. - If you don’t have this version you can find it at - <ulink url='http://www.eclipse.org/downloads'></ulink>. - From that site, choose the Eclipse Classic version. - This version contains the Eclipse Platform, the Java Development - Tools (JDT), and the Plug-in Development Environment. - </para> - <para> - Once you have downloaded the tarball, extract it into a clean - directory and complete the installation. - </para> - <para> - One issue exists that you need to be aware of regarding the Java - Virtual machine’s garbage collection (GC) process. - The GC process does not clean up the permanent generation - space (PermGen). - This space stores meta-data descriptions of classes. - The default value is set too small and it could trigger an - out-of-memory error such as the following: - <literallayout class='monospaced'> - Java.lang.OutOfMemoryError: PermGen space - </literallayout> - </para> - <para> - This error causes the application to hang. - </para> - <para> - To fix this issue you can use the ‐‐vmargs 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-required-plug-ins-and-the-eclipse-yocto-plug-in'> - <title>Installing Required Plug-ins and the Eclipse Yocto Plug-in</title> - <para> - Before installing the Yocto Plug-in you need to be sure that the - CDT 7.0, RSE 3.2, and Autotools plug-ins are all installed in the - following order. - After installing these three plug-ins, you can install the - Eclipse Yocto Plug-in. - Use the following URLs for the plug-ins: - <orderedlist> - <listitem><para><emphasis>CDT 7.0</emphasis> – - <ulink url='http://download.eclipse.org/tools/cdt/releases/helios/'></ulink>: - For CDT main features select the checkbox so you get all items. - For CDT optional features expand the selections and check - “C/C++ Remote Launch”.</para></listitem> - <listitem><para><emphasis>RSE 3.2</emphasis> – - <ulink url='http://download.eclipse.org/tm/updates/3.2'></ulink>: - Check the box next to “TM and RSE Main Features” so you select all - those items. - Note that all items in the main features depend on 3.2.1 version. - Expand the items under “TM and RSE Uncategorized 3.2.1” and - select the following: “Remote System Explorer End-User Runtime”, - “Remote System Explorer Extended SDK”, “Remote System Explorer User Actions”, - “RSE Core”, “RSE Terminals UI”, and “Target Management Terminal”.</para></listitem> - <listitem><para><emphasis>Autotools</emphasis> – - <ulink url='http://download.eclipse.org/technology/linuxtools/update/'></ulink>: - Expand the items under “Linux Tools” and select “Autotools support for - CDT (Incubation)”.</para></listitem> - <listitem><para><emphasis>Yocto Plug-in</emphasis> – - <ulink url='http://www.yoctoproject.org/downloads/eclipse-plugin/1.0'></ulink>: - Check the box next to “Development tools & SDKs for Yocto Linux” - to select all the items.</para></listitem> - </orderedlist> - </para> - <para> - Follow these general steps to install a plug-in: - <orderedlist> - <listitem><para>From within the Eclipse IDE select the - “Install New Software” item from the “Help” menu.</para></listitem> - <listitem><para>Click “Add…” in the “Work with:” area.</para></listitem> - <listitem><para>Enter the URL for the repository and leave the “Name” - field blank.</para></listitem> - <listitem><para>Check the boxes next to the software you need to - install and then complete the installation. - For information on the specific software packages you need to include, - see the previous list.</para></listitem> - </orderedlist> - </para> - </section> - - <section id='configuring-the-plug-in'> - <title>Configuring the Plug-in</title> - <para> - Configuring the Eclipse Yocto Plug-in involves choosing the Cross - Compiler Options, selecting the Target Architecture, and choosing - the Target Options. - These settings are the default settings for all projects. - You do have opportunities to change them later if you choose to when - you configure the project. - See “Configuring the Cross Toolchain” section later in the manual. - </para> - <para> - To start, you need to do the following from within the Eclipse IDE: - <itemizedlist> - <listitem><para>Choose Windows -> Preferences to display - the Preferences Dialog</para></listitem> - <listitem><para>Click “Yocto SDK”</para></listitem> - </itemizedlist> - </para> - - <section id='configuring-the-cross-compiler-options'> - <title>Configuring the Cross-Compiler Options</title> - <para> - Choose between ‘SDK Root Mode’ and ‘Poky Tree Mode’ for Cross - Compiler Options. - <itemizedlist> - <listitem><para><emphasis>SDK Root Mode</emphasis> – Select this mode - when you are not concerned with building an image or you do not have - a Poky build tree on your system. - For example, suppose you are an application developer and do not - need to build an image. - You just want to use an architecture-specific toolchain on an - existing kernel and root filesystem. - When you use SDK Root Mode you are using the toolchain installed - in the <filename>/opt/poky</filename> directory.</para></listitem> - <listitem><para><emphasis>Poky Tree Mode</emphasis> – Select this mode - if you are concerned with building images for hardware or your - development environment already has a build tree. - In this case you likely already have a Poky build tree installed on - your system or you (or someone else) will be building one. - When you use the Poky Tree Mode you are using the toolchain bundled - inside the Poky build tree. - If you use this mode you must also supply the Poky Root Location - in the Preferences Dialog.</para></listitem> - </itemizedlist> - </para> - </section> - - <section id='configuring-the-sysroot'> - <title>Configuring the Sysroot</title> - <para> - Specify the sysroot, which is used by both the QEMU user-space - NFS boot process and by the cross-toolchain regardless of the - mode you select (SDK Root Mode or Poky Tree Mode). - For example, sysroot is the location to which you extract the - downloaded image’s root filesystem to through the ADT Installer. - </para> - </section> - - <section id='selecting-the-target-architecture'> - <title>Selecting the Target Architecture</title> - <para> - Use the pull-down Target Architecture menu and select the - target architecture. - </para> - <para> - The Target Architecture is the type of hardware you are - going to use or emulate. - This pull-down menu should have the supported architectures. - If the architecture you need is not listed in the menu then you - will need to re-visit - <xref linkend='adt-prepare'> - “Preparing to Use the Application Development Toolkit (ADT)”</xref> - section earlier in this document. - </para> - </section> - - <section id='choosing-the-target-options'> - <title>Choosing the Target Options</title> - <para> - You can choose to emulate hardware using the QEMU emulator, or you - can choose to use actual hardware. - <itemizedlist> - <listitem><para><emphasis>External HW</emphasis> – Select this option - if you will be using actual hardware.</para></listitem> - <listitem><para><emphasis>QEMU</emphasis> – Select this option if - you will be using the QEMU emulator. - If you are using the emulator you also need to locate the Kernel - and you can specify custom options.</para> - <para>In Poky Tree Mode the kernel you built will be located in the - Poky Build tree in <filename>tmp/deploy/images</filename> directory. - In SDK Root Mode the pre-built kernel you downloaded is located - in the directory you specified when you downloaded the image.</para> - <para>Most custom options are for advanced QEMU users to further - customize their QEMU instance. - These options are specified between paired angled brackets. - Some options must be specified outside the brackets. - In particular, the options <filename>serial</filename>, - <filename>nographic</filename>, and <filename>kvm</filename> must all - be outside the brackets. - Use the <filename>man qemu</filename> command to get help on all the options - and their use. - The following is an example: - <literallayout class='monospaced'> - serial ‘<-m 256 -full-screen>’ - </literallayout> - </para> - <para> - Regardless of the mode, Sysroot is already defined in the “Sysroot” - field.</para></listitem> - </itemizedlist> - </para> - <para> - Click the “OK” button to save your plug-in configurations. - </para> - </section> - </section> -</section> - -<section id='creating-the-project'> -<title>Creating the Project</title> - <para> - You can create two types of projects: Autotools-based, or Makefile-based. - This section describes how to create autotools-based projects from within - the Eclipse IDE. - For information on creating projects in a terminal window see - <xref linkend='using-the-command-line'> “Using the Command Line”</xref> - section. - </para> - <para> - To create a project based on a Yocto template and then display the source code, - follow these steps: - <orderedlist> - <listitem><para>Select File -> New -> Project.</para></listitem> - <listitem><para>Double click “CC++”.</para></listitem> - <listitem><para>Double click “C Project” to create the project.</para></listitem> - <listitem><para>Double click “Yocto SDK Project”.</para></listitem> - <listitem><para>Select “Hello World ANSI C Autotools Project”. - This is an Autotools-based project based on a Yocto Project template.</para></listitem> - <listitem><para>Put a name in the “Project name:” field.</para></listitem> - <listitem><para>Click “Next”.</para></listitem> - <listitem><para>Add information in the “Author” field.</para></listitem> - <listitem><para>Use “GNU General Public License v2.0” for the License.</para></listitem> - <listitem><para>Click “Finish”.</para></listitem> - <listitem><para>Answer ‘Yes” to the open perspective prompt.</para></listitem> - <listitem><para>In the Project Explorer expand your project.</para></listitem> - <listitem><para>Expand ‘src’.</para></listitem> - <listitem><para>Double click on your source file and the code appears - in the window. - This is the template.</para></listitem> - </orderedlist> - </para> -</section> - -<section id='configuring-the-cross-toolchains'> -<title>Configuring the Cross-Toolchains</title> - <para> - The previous section, <xref linkend='configuring-the-cross-compiler-options'> - “Configuring the Cross-Compiler Options”</xref>, set up the default project - configurations. - You can change these settings for a given project by following these steps: - <orderedlist> - <listitem><para>Select Project -> Invoke Yocto Tools -> Reconfigure Yocto. - This brings up the project Yocto Settings Dialog. - Settings are inherited from the default project configuration. - The information in this dialogue is identical to that chosen earlier - for the Cross Compiler Option (SDK Root Mode or Poky Tree Mode), - the Target Architecture, and the Target Options. - The settings are inherited from the Yocto Plug-in configuration performed - after installing the plug-in.</para></listitem> - <listitem><para>Select Project -> Reconfigure Project. - This runs the <filename>autogen.sh</filename> in the workspace for your project. - The script runs <filename>libtoolize</filename>, <filename>aclocal</filename>, - <filename>autoconf</filename>, <filename>autoheader</filename>, - <filename>automake ‐‐a</filename>, and - <filename>./configure</filename>.</para></listitem> - </orderedlist> - </para> -</section> - -<section id='building-the-project'> -<title>Building the Project</title> - <para> - To build the project, select Project -> Build Project. - You should see the console updated and you can note the cross-compiler you are using. - </para> -</section> - -<section id='starting-qemu-in-user-space-nfs-mode'> -<title>Starting QEMU in User Space NFS Mode</title> - <para> - To start the QEMU emulator from within Eclipse, follow these steps: - <orderedlist> - <listitem><para>Select Run -> External Tools -> External Tools Configurations... - This selection brings up the External Tools Configurations Dialogue.</para></listitem> - <listitem><para>Go to the left navigation area and expand ‘Program’. - You should find the image listed. - For example, qemu-x86_64-poky-linux.</para></listitem> - <listitem><para>Click on the image. - This brings up a new environment in the main area of the External - Tools Configurations Dialogue. - The Main tab is selected.</para></listitem> - <listitem><para>Click “Run” next. - This brings up a shell window.</para></listitem> - <listitem><para>Enter your host root password in the shell window at the prompt. - This sets up a Tap 0 connection needed for running in user-space NFS mode.</para></listitem> - <listitem><para>Wait for QEMU to launch.</para></listitem> - <listitem><para>Once QEMU launches you need to determine the IP Address - for the user-space NFS. - You can do that by going to a terminal in the QEMU and entering the - <filename>ipconfig</filename> command.</para></listitem> - </orderedlist> - </para> -</section> - -<section id='deploying-and-debugging-the-application'> -<title>Deploying and Debugging the Application</title> - <para> - Once QEMU is running you can deploy your application and use the emulator - to perform debugging. - Follow these steps to deploy the application. - <orderedlist> - <listitem><para>Select Run -> Debug Configurations...</para></listitem> - <listitem><para>In the left area expand “C/C++Remote Application”.</para></listitem> - <listitem><para>Locate your project and select it to bring up a new - tabbed view in the Debug Configurations dialogue.</para></listitem> - <listitem><para>Enter the absolute path into which you want to deploy - the application. - Use the Remote Absolute File Path for C/C++Application:. - For example, enter <filename>/usr/bin/<programname></filename>.</para></listitem> - <listitem><para>Click on the Debugger tab to see the cross-tool debugger - you are using.</para></listitem> - <listitem><para>Create a new connection to the QEMU instance - by clicking on “new”.</para></listitem> - <listitem><para>Select “TCF, which means Target Communication Framework.</para></listitem> - <listitem><para>Click “Next”.</para></listitem> - <listitem><para>Clear out the “host name” field and enter the IP Address - determined earlier.</para></listitem> - <listitem><para>Click Finish to close the new connections dialogue.</para></listitem> - <listitem><para>Use the drop-down menu now in the “Connection” field and pick - the IP Address you entered.</para></listitem> - <listitem><para>Click “Debug” to bring up a login screen and login.</para></listitem> - <listitem><para>Accept the debug perspective.</para></listitem> - </orderedlist> - </para> -</section> - -<section id='running-user-space-tools'> -<title>Running User-Space Tools</title> - <para> - As mentioned earlier in the manual several tools exist that enhance - your development experience. - These tools are aids in developing and debugging applications and images. - You can run these user-space tools from within the Yocto Eclipse - Plug-in through 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><emphasis>OProfile:</emphasis> 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. - You can locate both the viewer and server from - <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/oprofileui/'></ulink>. - You need to compile and install the oprofile-viewer from the source code - on your local host machine. - The oprofile-server is installed by default in the image.</para></listitem> - <listitem><para><emphasis>Lttng-ust:</emphasis> 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> - <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 - <filename>usttrace /path/to/foo</filename> on the remote target to trace the - program <filename>/path/to/foo</filename>.</para> - <para>"Argument" is passed to <filename>usttrace</filename> - running on the remote target.</para></listitem> - <listitem><para><emphasis>PowerTOP:</emphasis> Selecting this tool runs - "PowerTOP" on the remote target machine and displays the results in a - new view called "powertop".</para> - <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 -p argument - passed to "powertop".</para></listitem> - <listitem><para><emphasis>LatencyTOP and Perf:</emphasis> "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> - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/adt-manual/adt-intro.xml b/documentation/adt-manual/adt-intro.xml deleted file mode 100644 index 8740e5cf3e..0000000000 --- a/documentation/adt-manual/adt-intro.xml +++ /dev/null @@ -1,117 +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='adt-intro'> - -<title>Application Development Toolkit (ADT) User's Guide</title> - -<para> - Welcome to the Application Development Toolkit User’s Guide. This manual provides - information that lets you get going with the ADT to develop projects using the Yocto - Project. -</para> - -<section id='book-intro'> - <title>Introducing the Application Development Toolkit (ADT)</title> - <para> - Fundamentally, the ADT consists of an architecture-specific cross-toolchain and - a matching sysroot that are both built by the Poky build system. - The toolchain and sysroot are based on a metadata configuration and extensions, - which allows you to cross develop for the target on the host machine. - </para> - <para> - Additionally, to provide an effective development platform, the Yocto Project - makes available and suggests other tools as part of the ADT. - These other tools include the Eclipse IDE Yocto Plug-in, an emulator (QEMU), - and various user-space tools that greatly enhance your development experience. - </para> - <para> - The resulting combination of the architecture-specific cross-toolchain and sysroot - along with these additional tools yields a custom-built, cross-development platform - for a user-targeted product. - </para> - - <section id='the-cross-toolchain'> - <title>The Cross-Toolchain</title> - <para> - The cross-toolchain consists of a cross-compiler, cross-linker, and cross-debugger - that are all generated through a Poky build that is based on your metadata - configuration or extension for your targeted device. - The cross-toolchain works with a matching target sysroot. - </para> - </section> - - <section id='sysroot'> - <title>Sysroot</title> - <para> - The matching target sysroot contains needed headers and libraries for generating - binaries that run on the target architecture. - The sysroot is based on the target root filesystem image that is built by - Poky and uses the same metadata configuration used to build the cross-toolchain. - </para> - </section> - - <section id='the-qemu-emulator'> - <title>The QEMU Emulator</title> - <para> - The QEMU emulator allows you to simulate your hardware while running your - application or image. - QEMU is installed several ways: as part of the Poky tree, ADT installation - through a toolchain tarball, or through the ADT Installer. - </para> - </section> - - <section id='user-space-tools'> - <title>User-Space Tools</title> - <para> - User-space tools are included as part of the distribution. - You will find these tools helpful during development. - The tools include LatencyTOP, PowerTOP, OProfile, Perf, SystemTap, and Lttng-ust. - These tools are common development tools for the Linux platform. - <itemizedlist> - <listitem><para><emphasis>LatencyTOP</emphasis> – LatencyTOP focuses on latency - that causes skips in audio, - stutters in your desktop experience, or situations that overload your server - even when you have plenty of CPU power left. - You can find out more about LatencyTOP at - <ulink url='http://www.latencytop.org/'></ulink>. - </para></listitem> - <listitem><para><emphasis>PowerTOP</emphasis> – Helps you determine what - software is using the most power. - You can find out more about PowerTOP at - <ulink url='http://www.linuxpowertop.org/'></ulink>. - </para></listitem> - <listitem><para><emphasis>OProfile</emphasis> – A system-wide profiler for Linux - systems that is capable - of profiling all running code at low overhead. - You can find out more about OProfile at - <ulink url='http://oprofile.sourceforge.net/about/'></ulink>. - </para></listitem> - <listitem><para><emphasis>Perf</emphasis> – Performance counters for Linux used - to keep track of certain - types of hardware and software events. - For more information on these types of counters see - <ulink url='https://perf.wiki.kernel.org/index.php'></ulink> and click - on “Perf tools.” - </para></listitem> - <listitem><para><emphasis>SystemTap</emphasis> – A free software infrastructure - that simplifies - information gathering about a running Linux system. - This information helps you diagnose performance or functional problems. - SystemTap is not available as a user-space tool through the Yocto Eclipse IDE Plug-in. - See <ulink url='http://sourceware.org/systemtap'></ulink> for more information - on SystemTap. - </para></listitem> - <listitem><para><emphasis>Lttng-ust</emphasis> – A User-space Tracer designed to - provide detailed information on user-space activity. - See <ulink url='http://lttng.org/ust'></ulink> for more information on Lttng-ust. - </para></listitem> - </itemizedlist> - </para> - </section> -</section> - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/adt-manual/adt-manual-customization.xsl b/documentation/adt-manual/adt-manual-customization.xsl deleted file mode 100644 index 8eb69050ba..0000000000 --- a/documentation/adt-manual/adt-manual-customization.xsl +++ /dev/null @@ -1,8 +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:param name="generate.toc" select="'article nop'"></xsl:param> --> - -</xsl:stylesheet> diff --git a/documentation/adt-manual/adt-manual.xml b/documentation/adt-manual/adt-manual.xml deleted file mode 100644 index 7182d037ac..0000000000 --- a/documentation/adt-manual/adt-manual.xml +++ /dev/null @@ -1,70 +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='adt-manual' lang='en' - xmlns:xi="http://www.w3.org/2003/XInclude" - xmlns="http://docbook.org/ns/docbook" - > - <bookinfo> - - <mediaobject> - <imageobject> - <imagedata fileref='figures/adt-title.png' - format='SVG' - align='left' scalefit='1' width='100%'/> - </imageobject> - </mediaobject> - - <title></title> - - <authorgroup> - <author> - <firstname>Jessica</firstname> <surname>Zhang</surname> - <affiliation> - <orgname>Intel Corporation</orgname> - </affiliation> - <email>jessica.zhang@intel.com</email> - </author> - </authorgroup> - - <revhistory> - <revision> - <revnumber>1.0</revnumber> - <date>6 April 2011</date> - <revremark>Initial Document released with Yocto Project 1.0 on 6 April 2011.</revremark> - </revision> - </revhistory> - - <copyright> - <year>2010-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="adt-intro.xml"/> - - <xi:include href="adt-prepare.xml"/> - - <xi:include href="adt-package.xml"/> - - <xi:include href="adt-eclipse.xml"/> - - <xi:include href="adt-command.xml"/> - -<!-- <index id='index'> - <title>Index</title> - </index> ---> - -</book> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/adt-manual/adt-package.xml b/documentation/adt-manual/adt-package.xml deleted file mode 100644 index fc2a1a0cba..0000000000 --- a/documentation/adt-manual/adt-package.xml +++ /dev/null @@ -1,82 +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='adt-package'> -<title>Optionally Customizing the Development Packages Installation</title> - <para> - Because the Yocto Project is suited for embedded Linux development it is - likely that you will need to customize your development packages installation. - For example, if you are developing a minimal image then you might not need - certain packages (e.g. graphics support packages). - Thus, you would like to be able to remove those packages from your sysroot. - </para> - -<section id='package-management-systems'> - <title>Package Management Systems</title> - <para> - The Yocto Project supports the generation of root filesystem files using - three different Package Management Systems (PMS): - <itemizedlist> - <listitem><para><emphasis>OPKG</emphasis> – A less well known PMS whose use - originated in the OpenEmbedded and OpenWrt embedded Linux projects. - This PMS works with files packaged in an <filename>.ipk</filename> format. - See <ulink url='http://en.wikipedia.org/wiki/Opkg'></ulink> for more - information about OPKG.</para></listitem> - <listitem><para><emphasis>RPM</emphasis> – A more widely known PMS intended for GNU/Linux - distributions. - This PMS works with files packaged in an <filename>.rms</filename> format. - The Yocto Project currently installs through this PMS by default. - See <ulink url='http://en.wikipedia.org/wiki/RPM_Package_Manager'></ulink> - for more information about RPM.</para></listitem> - <listitem><para><emphasis>Debian</emphasis> – The PMS for Debian-based systems - is built on many PMS tools. - The lower-level PMS tool dpkg forms the base of the Debian PMS. - For information on dpkg see - <ulink url='http://en.wikipedia.org/wiki/Dpkg'></ulink>.</para></listitem> - </itemizedlist> - </para> -</section> - -<section id='configuring-the-pms'> - <title>Configuring the PMS</title> - <para> - Whichever PMS you are using you need to be sure that the - <filename>PACKAGE_CLASSES</filename> variable in the <filename>conf/local.conf</filename> - file is set to reflect that system. - The first value you choose for the variable specifies the package file format for the root - filesystem. - Additional values specify additional formats for convenience or testing. - See the configuration file for details. - </para> - <para> - As an example, consider a scenario where you are using OPKG and you want to add - the libglade package to sysroot. - </para> - <para> - First, you should generate the ipk file for the libglade package and add it - into a working opkg repository. - Use these commands: - <literallayout class='monospaced'> - $ bitbake libglade - $ bitbake package-index - </literallayout> - </para> - <para> - Next, source the environment setup script. - Follow that by setting up the installation destination to point to your - sysroot as <filename><sysroot dir></filename>. - Finally, have an opkg configuration file <filename><conf file></filename> - that corresponds to the opkg repository you have just created. - The following command forms should now work: - <literallayout class='monospaced'> - $ opkg-cl –f <conf file> -o <sysroot dir> update - $ opkg-cl –f <conf file>> -o <sysroot dir> --force-overwrite install libglade - $ opkg-cl –f <conf file> -o <sysroot dir> --force-overwrite install libglade-dbg - $ opkg-cl –f <conf file> -o <sysroot dir> --force-overwrite install libglade-dev - </literallayout> - </para> -</section> -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/adt-manual/adt-prepare.xml b/documentation/adt-manual/adt-prepare.xml deleted file mode 100644 index f27f603e1d..0000000000 --- a/documentation/adt-manual/adt-prepare.xml +++ /dev/null @@ -1,244 +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='adt-prepare'> - -<title>Preparing to Use the Application Development Toolkit (ADT)</title> - -<para> - In order to use the ADT it must be installed, the environment setup script must be - sourced, and the kernel and filesystem image specific to the target architecture must exist. - This section describes how to install the ADT, set up the environment, and provides - some reference information on kernels and filesystem images. -</para> - -<section id='installing-the-adt'> - <title>Installing the ADT</title> - <para> - You can install the ADT three ways. - However, we recommend configuring and running the ADT Installer script. - Running this script automates much of the process for you. - For example, the script allows you to install the QEMU emulator and - user-space NFS, define which root filesystem profiles to download, - and allows you to define the target sysroot location. - </para> - <note> - If you need to generate the ADT tarball you can do so using the following command: - <literallayout class='monospaced'> - $ bitbake adt-installer - </literallayout> - This command generates the file <filename>adt-installer.tar.bz2</filename> - in the <filename>../build/tmp/deploy/sdk</filename> directory. - </note> - - <section id='configuring-and-running-the-adt-installer'> - <title>Configuring and Running the ADT Installer</title> - <para> - The ADT Installer is contained in a tarball that can be built using - <filename>bitbake adt-installer</filename>. - Yocto Project has a pre-built ADT Installer tarball that you can download - from <filename>tmp/deploy/sdk</filename> located in the build directory. - </para> - - <note> - You can install and run the ADT Installer tarball in any directory you want. - </note> - - <para> - Before running the ADT Installer you need to configure it by editing - the <filename>adt-installer.conf</filename> file, which is located in the - directory where the ADT Installer tarball was installed. - Your configurations determine which kernel and filesystem image are downloaded. - The following list describes the variables you can define for the ADT Installer. - For configuration values and restrictions see the comments in - the <filename>adt-installer.conf</filename> file: - - <itemizedlist> - <listitem><para><filename>YOCTOADT_IPKG_REPO</filename> – This area - includes the IPKG-based packages and the root filesystem upon which - the installation is based. - If you want to set up your own IPKG repository pointed to by - <filename>YOCTOADT_IPKG_REPO</filename>, you need to be sure that the - directory structure follows the same layout as the reference directory - set up at <ulink url='http://adtrepo.yoctoproject.org'></ulink>. - Also, your repository needs to be accessible through HTTP. - </para></listitem> - <listitem><para><filename>YOCTOADT-TARGETS</filename> – The machine - target architectures for which you want to set up cross-development - environments. - </para></listitem> - <listitem><para><filename>YOCTOADT_QEMU</filename> – Indicates whether - or not to install the emulator QEMU. - </para></listitem> - <listitem><para><filename>YOCTOADT_NFS_UTIL</filename> – Indicates whether - or not to install user-mode NFS. - If you plan to use the Yocto Eclipse IDE plug-in against QEMU, - you should install NFS. - <note> - To boot QEMU images using our userspace NFS server, you need - to be running portmap or rpcbind. - If you are running rpcbind, you will also need to add the -i - option when rpcbind starts up. - Please make sure you understand the security implications of doing this. - Your firewall settings may also have to be modified to allow - NFS booting to work. - </note> - </para></listitem> - <listitem><para><filename>YOCTOADT_ROOTFS_<arch></filename> - The root - filesystem images you want to download. - </para></listitem> - <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_IMAGE_<arch></filename> - The - root filesystem used to extract and create the target sysroot. - </para></listitem> - <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_LOC_<arch></filename> - The - location of the target sysroot that will be set up on the development machine. - </para></listitem> - </itemizedlist> - </para> - - <para> - After you have configured the <filename>adt-installer.conf</filename> file, - run the installer using the following command: - <literallayout class='monospaced'> - $ adt_installer - </literallayout> - </para> - - <para> - Once the installer begins to run you are asked whether you want to run in - interactive or silent mode. - If you want to closely monitor the installation then choose “I” for interactive - mode rather than “S” for silent mode. - Follow the prompts from the script to complete the installation. - </para> - - <para> - Once the installation completes, the cross-toolchain is installed in - <filename>/opt/poky/$SDKVERSION</filename>. - </para> - - <para> - Before using the ADT you need to run the environment setup script for - your target architecture also located in <filename>/opt/poky/$SDKVERSION</filename>. - See the <xref linkend='setting-up-the-environment'>“Setting Up the Environment”</xref> - section for information. - </para> - </section> - - <section id='using-an-existing-toolchain-tarball'> - <title>Using an Existing Toolchain Tarball</title> - <para> - If you do not want to use the ADT Installer you can install the toolchain - and the sysroot by hand. - Follow these steps: - <orderedlist> - <listitem><para>Locate and download the architecture-specific toolchain - tarball from <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.0'></ulink>. - Look in the ‘toolchain’ folder and then open up the folder that matches your - host development system (i.e. 'i686' for 32-bit machines or 'x86_64' - for 64-bit machines). - Then, select the toolchain tarball whose name includes the appropriate - target architecture. - <note> - If you need to build the toolchain tarball use the - <filename>bitbake meta-toolchain</filename> command after you have - sourced the poky-build-init script. - The tarball will be located in the build directory at - <filename>tmp/deploy/sdk</filename> after the build. - </note> - </para></listitem> - <listitem><para>Make sure you are in the root directory and then expand - the tarball. - The tarball expands into the <filename>/opt/poky/$SDKVERSION</filename> directory. - </para></listitem> - <listitem><para>Set up the environment by sourcing the environment set up - script. - See the <xref linkend='setting-up-the-environment'>“Setting Up the Environment”</xref> - for information. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='using-the-toolchain-from-within-the-build-tree'> - <title>Using the Toolchain from Within the Build Tree</title> - <para> - A final way of accessing the toolchain is from the build tree. - The build tree can be set up to contain the architecture-specific cross toolchain. - To populate the build tree with the toolchain you need to run the following command: - <literallayout class='monospaced'> - $ bitbake meta-ide-support - </literallayout> - </para> - - <para> - Before running the command you need to be sure that the - <filename>conf/local.conf</filename> file in the build directory has - the desired architecture specified for the <filename>MACHINE</filename> - variable. - See the <filename>local.conf</filename> file for a list of values you - can supply for this variable. - You can populate the build tree with the cross-toolchains for more - than a single architecture. - You just need to edit the <filename>local.conf</filename> file and re-run - the BitBake command. - </para> - - <para> - Once the build tree has the toolchain you need to source the environment - setup script so that you can run the cross-tools without having to locate them. - See the <xref linkend='setting-up-the-environment'>“Setting Up the Environment”</xref> - for information. - </para> - </section> -</section> - -<section id='setting-up-the-environment'> - <title>Setting Up the Environment</title> - <para> - Before you can use the cross-toolchain you need to set up the environment by - sourcing the environment setup script. - If you used adt_installer or used an existing ADT tarball to install the ADT, - then you can find this script in the <filename>/opt/poky/$SDKVERSION</filename> - directory. - If you are using the ADT from a Poky build tree, then look in the build - directory in <filename>tmp</filename> for the setup script. - </para> - - <para> - Be sure to run the environment setup script that matches the architecture for - which you are developing. - Environment setup scripts begin with the string “environment-setup” and include as - part of their name the architecture. - For example, the environment setup script for a 64-bit IA-based architecture would - be the following: - <literallayout class='monospaced'> - /opt/poky/environment-setup-x86_64-poky-linux - </literallayout> - </para> -</section> - -<section id='kernels-and-filesystem-images'> - <title>Kernels and Filesystem Images</title> - <para> - You will need to have a kernel and filesystem image to boot using your - hardware or the QEMU emulator. - That means you either have to build them or know where to get them. - You can find lots of details on how to get or build images and kernels for your - architecture in the "Yocto Project Quick Start" found at - <ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html'></ulink>. - <note> - Yocto Project provides basic kernels and filesystem images for several - architectures (x86, x86-64, mips, powerpc, and arm) that can be used - unaltered in the QEMU emulator. - These kernels and filesystem images reside in the Yocto Project release - area - <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.0/'></ulink> - and are ideal for experimentation within Yocto Project. - </note> - </para> -</section> - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/adt-manual/figures/adt-title.png b/documentation/adt-manual/figures/adt-title.png Binary files differdeleted file mode 100644 index fe6ed26dc4..0000000000 --- a/documentation/adt-manual/figures/adt-title.png +++ /dev/null diff --git a/documentation/adt-manual/figures/yocto-project-transp.png b/documentation/adt-manual/figures/yocto-project-transp.png Binary files differdeleted file mode 100755 index 31d2b147fd..0000000000 --- a/documentation/adt-manual/figures/yocto-project-transp.png +++ /dev/null diff --git a/documentation/adt-manual/style.css b/documentation/adt-manual/style.css deleted file mode 100644 index 7c24fe5d2d..0000000000 --- a/documentation/adt-manual/style.css +++ /dev/null @@ -1,968 +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/adt-title.png"); - background-position: left top; - margin-top: -256px; - padding-right: 50px; - margin-left: 0px; - text-align: right; - width: 740px; -} - -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{ -} - -/* -Example of how to stick an image as part of the title. - -div.article .titlepage .title -{ - background-image: url("figures/white-on-black.png"); - background-position: center; - background-repeat: repeat-x; -} -*/ - -div.preface .titlepage .title, -div.colophon .title, -div.chapter .titlepage .title, -div.article .titlepage .title -{ -} - -div.section div.section .titlepage .title, -div.sect2 .titlepage .title { - background: none; -} - - -h1.title { - background-color: transparent; - background-image: url("figures/yocto-project-bw.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/bsp-guide/Makefile b/documentation/bsp-guide/Makefile deleted file mode 100644 index fdb45ecd13..0000000000 --- a/documentation/bsp-guide/Makefile +++ /dev/null @@ -1,35 +0,0 @@ -XSLTOPTS = --stringparam html.stylesheet style.css \ - --stringparam chapter.autolabel 1 \ - --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 bsp-guide.xml ../template - -html: -# See http://www.sagehill.net/docbookxsl/HtmlOutput.html - xsltproc $(XSLTOPTS) -o bsp-guide.html bsp-guide-customization.xsl bsp-guide.xml - -tarball: html - tar -cvzf bsp-guide.tgz style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png - -validate: - xmllint --postvalid --xinclude --noout bsp-guide.xml - -OUTPUTS = bsp-guide.pdf bsp-guide.html -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/bsp-guide/bsp-guide-customization.xsl b/documentation/bsp-guide/bsp-guide-customization.xsl deleted file mode 100644 index 362ebed131..0000000000 --- a/documentation/bsp-guide/bsp-guide-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/bsp-guide/bsp-guide.xml b/documentation/bsp-guide/bsp-guide.xml deleted file mode 100644 index fd409bc74c..0000000000 --- a/documentation/bsp-guide/bsp-guide.xml +++ /dev/null @@ -1,68 +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='bsp-guide' lang='en' - xmlns:xi="http://www.w3.org/2003/XInclude" - xmlns="http://docbook.org/ns/docbook" - > - <bookinfo> - - <mediaobject> - <imageobject> - <imagedata fileref='figures/bsp-title.png' - format='SVG' - align='center' scalefit='1' width='100%'/> - </imageobject> - </mediaobject> - - <title></title> - - <authorgroup> - <author> - <firstname>Richard</firstname> <surname>Purdie</surname> - <affiliation> - <orgname>Intel Corporation</orgname> - </affiliation> - <email>richard.purdie@linuxfoundation.org</email> - </author> - </authorgroup> - - <revhistory> - <revision> - <revnumber>0.9</revnumber> - <date>27 October 2010</date> - <revremark>This manual revision is the initial manual and corresponds to the - Yocto Project 0.9 Release.</revremark> - </revision> - <revision> - <revnumber>1.0</revnumber> - <date>6 April 2011</date> - <revremark>This manual revision corresponds to the Yocto Project 1.0 Release.</revremark> - </revision> - </revhistory> - - <copyright> - <year>2010-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-nc-sa/2.0/uk/">Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England & Wales</ulink> as published by Creative Commons. - </para> - </legalnotice> - - </bookinfo> - - <xi:include href="bsp.xml"/> - -<!-- <index id='index'> - <title>Index</title> - </index> ---> - -</book> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml deleted file mode 100644 index 36715f33b7..0000000000 --- a/documentation/bsp-guide/bsp.xml +++ /dev/null @@ -1,654 +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='bsp'> - - <title>Board Support Packages (BSP) - Developers Guide</title> - - <para> - A Board Support Package (BSP) is a collection of information that - defines how to support a particular hardware device, set of devices, or - hardware platform. - The BSP includes information about the hardware features - present on the device and kernel configuration information along with any - additional hardware drivers required. - The BSP also lists any additional software - components required in addition to a generic Linux software stack for both - essential and optional platform features. - </para> - - <para> - This section (or document if you are reading the BSP Developer's Guide) defines - a structure for these components - so that BSPs follow a commonly understood layout. - Providing a common form allows end-users to understand and become familiar - with the layout. - A common form also encourages standardization - of software support of hardware. - </para> - - <para> - The proposed format does have elements that are specific to the Poky and - OpenEmbedded build systems. - It is intended that this information can be - used by other systems besides Poky and OpenEmbedded and that it will be simple - to extract information and convert it to other formats if required. - Poky, through its standard layers mechanism, can directly accept the format - described as a layer. - The BSP captures all - the hardware-specific details in one place in a standard format, which is - useful for any person wishing to use the hardware platform regardless of - the build system they are using. - </para> - - <para> - The BSP specification does not include a build system or other tools - - it is concerned with the hardware-specific components only. - At the end - distribution point you can ship the BSP combined with a build system - and other tools. - However, it is important to maintain the distinction that these - are separate components that happen to be combined in certain end products. - </para> - - <section id="bsp-filelayout"> - <title>Example Filesystem Layout</title> - - <para> - The BSP consists of a file structure inside a base directory, which uses the following - naming convention: - <literallayout class='monospaced'> - meta-<bsp_name> - </literallayout> - "bsp_name" is a placeholder for the machine or platform name. - Here are some example base directory names: - <literallayout class='monospaced'> - meta-emenlow - meta-intel_n450 - meta-beagleboard - </literallayout> - </para> - - <para> - Below is the common form for the file structure inside a base directory. - While you can use this basic form for the standard, realize that the actual structures - for specific BSPs could differ. - - <programlisting> -meta-<bsp_name>/ -meta-<bsp_name>/<bsp_license_file> -meta-<bsp_name>/README -meta-<bsp_name>/binary/<bootable_images> -meta-<bsp_name>/conf/layer.conf -meta-<bsp_name>/conf/machine/*.conf -meta-<bsp_name>/recipes-bsp/* -meta-<bsp_name>/recipes-graphics/* -meta-<bsp_name>/recipes-kernel/linux/linux-yocto_git.bbappend - </programlisting> - </para> - - <para> - Below is an example of the crownbay BSP: - - <programlisting> -meta-crownbay/COPYING.MIT -meta-crownbay/README -meta-crownbay/binary/.gitignore -meta-crownbay/conf/layer.conf -meta-crownbay/conf/machine/crownbay.conf -meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig -meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xcorg.conf -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd-bin/.gitignore -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd-bin_1.7.99.2.bb -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/crosscompile.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/fix_open_max_preprocessor_error.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/macro_tweak.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/nodolt.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb -meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend - </programlisting> - </para> - - <para> - The following sections describe each part of the proposed BSP format. - </para> - - <section id="bsp-filelayout-license"> - <title>License Files</title> - <programlisting> -meta-<bsp_name>/<bsp_license_file> - </programlisting> - - <para> - These optional files satisfy licensing requirements for the BSP. - The type or types of files here can vary depending on the licensing requirements. - For example, in the crownbay BSP all licensing requirements are handled with the - <filename>COPYING.MIT</filename> file. - </para> - - <para> - Licensing files can be MIT, BSD, GPLv*, and so forth. - These files are recommended for the BSP but are optional and totally up to the BSP developer. - </para> - </section> - - <section id="bsp-filelayout-readme"> - <title>README File</title> - <programlisting> -meta-<bsp_name>/README - </programlisting> - - <para> - This file provides information on how to boot the live images that are optionally - included in the <filename>/binary</filename> directory. - The <filename>README</filename> file also provides special information needed for - building the image. - </para> - - <para> - Technically speaking a <filename>README</filename> is optional but it is highly - recommended that every BSP has one. - </para> - </section> - - <section id="bsp-filelayout-binary"> - <title>Pre-built User Binaries</title> - <programlisting> -meta-<bsp_name>/binary/<bootable_images> - </programlisting> - - <para> - This optional area contains useful pre-built kernels and user-space filesystem - images appropriate to the target system. - This directory contains the Application Development Toolkit (ADT) and minimal - live images when the BSP is has been "tar-balled" and placed on the Yocto Project website. - You can use these kernels and images to get a system running and quickly get started - on development tasks. - </para> - - <para> - The exact types of binaries present are highly hardware-dependent. - However, a README file should be present in the BSP file structure that explains how to use - the kernels and images with the target hardware. - If pre-built binaries are present, source code to meet licensing requirements must also - be provided in some form. - </para> - </section> - - <section id='bsp-filelayout-layer'> - <title>Layer Configuration File</title> - <programlisting> -meta-<bsp_name>/conf/layer.conf - </programlisting> - - <para> - This file identifies the structure as a Poky layer, identifies the - contents of the layer, and contains information about how Poky should use it. - Generally, a standard boilerplate file such as the following works. - In the following example you would replace "bsp" and "_bsp" with the actual name - of the BSP (i.e. <bsp_name> from the example template). - </para> - - <para> - <programlisting> -# We have a conf directory, add to BBPATH -BBPATH := "${BBPATH}:${LAYERDIR}" - -# We have a recipes directory containing .bb and .bbappend files, add to BBFILES -BBFILES := "${BBFILES} ${LAYERDIR}/recipes/*/*.bb \ ${LAYERDIR}/recipes/*/*.bbappend" - -BBFILE_COLLECTIONS += "bsp" -BBFILE_PATTERN_bsp := "^${LAYERDIR}/" -BBFILE_PRIORITY_bsp = "5" - </programlisting> - </para> - - <para> - This file simply makes BitBake aware of the recipes and configuration directories. - This file must exist so that Poky can recognize the BSP. - </para> - </section> - - <section id="bsp-filelayout-machine"> - <title>Hardware Configuration Options</title> - <programlisting> -meta-<bsp_name>/conf/machine/*.conf - </programlisting> - - <para> - The machine files bind together all the information contained elsewhere - in the BSP into a format that Poky can understand. - If the BSP supports multiple machines, multiple machine configuration files - can be present. - These filenames correspond to the values to which users have set the MACHINE variable. - </para> - - <para> - These files define things such as the kernel package to use - (PREFERRED_PROVIDER of virtual/kernel), the hardware drivers to - include in different types of images, any special software components - that are needed, any bootloader information, and also any special image - format requirements. - </para> - - <para> - At least one machine file is required for a BSP layer. - However, you can supply more than one file. - </para> - - <para> - This directory could also contain shared hardware "tuning" definitions that are commonly used to - pass specific optimization flags to the compiler. - An example is <filename>tune-atom.inc</filename>: - </para> - <para> - <programlisting> -BASE_PACKAGE_ARCH = "core2" -TARGET_CC_ARCH = "-m32 -march=core2 -msse3 -mtune=generic -mfpmath=sse" - </programlisting> - </para> - <para> - This example defines a new package architecture called "core2" and uses the - specified optimization flags, which are carefully chosen to give best - performance on atom processors. - </para> - <para> - The tune file would be included by the machine definition and can be - contained in the BSP or referenced from one of the standard core set of - files included with Poky itself. - </para> - <para> - Both the base package architecture file and the tune file are optional for a Poky BSP layer. - </para> - </section> - - <section id='bsp-filelayout-misc-recipes'> - <title>Miscellaneous Recipe Files</title> - <programlisting> -meta-<bsp_name>/recipes-bsp/* - </programlisting> - - <para> - This optional directory contains miscellaneous recipe files for the BSP. - Most notably would be the formfactor files. - For example, in the crownbay BSP there is a <filename>machconfig</filename> file and a - <filename>formfactor_0.0.bbappend</filename> file: - <programlisting> -meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig -meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend - </programlisting> - </para> - - <note><para> - If a BSP does not have a formfactor entry, defaults are established according to - the configuration script. - </para></note> - </section> - - <section id='bsp-filelayout-recipes-graphics'> - <title>Display Support Files</title> - <programlisting> -meta-<bsp_name>/recipes-graphics/* - </programlisting> - - <para> - This optional directory contains recipes for the BSP if it has - special requirements for graphics support. - All files that are needed for the BSP to support a display are kept here. - For example, in the crownbay BSP several display support files exist: - <programlisting> -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xcorg.conf -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd-bin/.gitignore -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd-bin_1.7.99.2.bb -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/crosscompile.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/fix_open_max_preprocessor_error.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/macro_tweak.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd/nodolt.patch -meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-emgd_1.7.99.2.bb - </programlisting> - </para> - </section> - - <section id='bsp-filelayout-kernel'> - <title>Linux Kernel Configuration</title> - <programlisting> -meta-<bsp_name>/recipes-kernel/linux/linux-yocto_git.bbappend - </programlisting> - - <para> - This file appends your specific changes to the kernel you are using. - </para> - <para> - For your BSP you typically want to use an existing Poky kernel found in the - Poky repository at <filename class='directory'>meta/recipes-kernel/kernel</filename>. - You can append your specific changes to the kernel recipe by using an append file, - which is located in the - <filename class='directory'>meta-<bsp_name>/recipes-kernel/linux</filename> - directory. - </para> - <para> - Suppose you use a BSP that uses the <filename>linux-yocto_git.bb</filename> kernel, - which is the preferred kernel to use for developing a new BSP using the Yocto Project. - In other words, you have selected the kernel in your - <filename><bsp_name>.conf</filename> file by adding the following statement: - <programlisting> -PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" - </programlisting> - You would use the <filename>linux-yocto_git.bbappend</filename> file to append - specific BSP settings to the kernel, thus configuring the kernel for your particular BSP. - </para> - <para> - Now take a look at the existing "crownbay" BSP. - The append file used is: - <programlisting> -meta-crownbay/recipes-kernel/linux/linux-yocto_git.bbappend - </programlisting> - The file contains the following: - <programlisting> -FILESEXTRAPATHS := "${THISDIR}/${PN}" -COMPATIBLE_MACHINE_crownbay = "crownbay" -KMACHINE_crownbay = "yocto/standard/crownbay" - </programlisting> - This append file adds "crownbay" as a compatible machine, - and additionally sets a Yocto Kernel-specific variable that identifies the name of the - BSP branch to use in the GIT repository to find configuration information. - </para> - <para> - One thing missing in this particular BSP, which you will typically need when - developing a BSP, is the kernel configuration (.config) for your BSP. - When developing a BSP, you probably have a kernel configuration file or a set of kernel - configuration files that, when taken together, define the kernel configuration for your BSP. - You can accomplish this definition by putting the configurations in a file or a set of files - inside a directory located at the same level as your append file and having the same name - as the kernel. - With all these conditions met simply reference those files in a SRC_URI statement in the append - file. - </para> - <para> - For example, suppose you had a set of configuration options in a file called - <filename>defconfig</filename>. - If you put that file inside a directory named - <filename class='directory'>/linux-yocto</filename> and then added - a SRC_URI statement such as the following to the append file, those configuration - options will be picked up and applied when the kernel is built. - <programlisting> -SRC_URI += "file://defconfig" - </programlisting> - </para> - <para> - As mentioned earlier, you can group related configurations into multiple files and - name them all in the SRC_URI statement as well. - For example, you could group separate configurations specifically for Ethernet and graphics - into their own files and add those by using a SRC_URI statement like the - following in your append file: - <programlisting> -SRC_URI += "file://defconfig \ - file://eth.cfg \ - file://gfx.cfg" - </programlisting> - </para> - <para> - The FILESEXTRAPATHS variable is in boilerplate form here in order to make it easy - to do that. - It basically allows those configuration files to be found by the build process. - </para> - <note><para> - Other methods exist to accomplish grouping and defining configuration options. - For example, you could directly add configuration options to the Yocto kernel - <filename class='directory'>meta</filename> branch for your BSP. - The configuration options will likely end up in that location anyway if the BSP gets - added to the Yocto Project. - For information on how to add these configurations directly, see the - "Yocto Project Kernel Architecture and Use Manual" on the - <ulink url="http://yoctoproject.org/community/documentation">Yocto Project website - Documentation Page</ulink> - </para> - <para> - In general, however, the Yocto Project maintainers take care of moving the SRC_URI-specified - configuration options to the <filename class='directory'>meta</filename> branch. - Not only is it easier for BSP developers to not have to worry about putting those - configurations in the branch, but having the maintainers do it allows them to apply - 'global' knowledge about the kinds of common configuration options multiple BSPs in - the tree are typically using. - This allows for promotion of common configurations into common features. - </para></note> - </section> - -<!-- <section id='bsp-filelayout-packages'> - <title>Other Software (meta-<bsp_name>/recipes-kernel/*)</title> - - <para> - This section describes other pieces of software that the hardware might need for best - operation. - Examples show some of the things you could encounter. - The examples are standard <filename>.bb</filename> file recipes in the - usual Poky format. - You can include the source directly by referring to it in the source control system or - the released tarballs of external software projects. - You only need to provide these types of files if the platform requires them. - </para> - <para> - The following file is a bootloader recipe that can be used to generate a new - bootloader binary. - Sometimes these files are included in the final image format and are needed to re-flash hardware. - </para> - <para> - <programlisting> -meta-Emenlow/recipes-kernel/bootloader/bootloader_0.1.bb - </programlisting> - </para> - <para> - These next two files are examples of a hardware driver and a hardware daemon that might need - to be included in images to make the hardware useful. - Although the example uses "modem" there may be other components needed, such as firmware. - </para> - <para> - <programlisting> -meta-Emenlow/recipes-Emenlow/modem/modem-driver_0.1.bb -meta-Emenlow/recipes-Emenlow/modem/modem-daemon_0.1.bb - </programlisting> - </para> - <para> - Sometimes the device needs an image in a very specific format so that the update - mechanism can accept and re-flash it. - Recipes to build the tools needed to do this can be included with the BSP. - Following is an example. - </para> - <para> - <programlisting> -meta-Emenlow/recipes-Emenlow/image-creator/image-creator-native_0.1.bb - </programlisting> - </para> - </section> - - <section id='bs-filelayout-bbappend'> - <title>Append BSP-Specific Information to Existing Recipes</title> - <para> - Suppose you have a recipe such as "pointercal" that requires machine-specific information. - At the same time, you have your new BSP code nicely partitioned into a layer through which - you would also like to specify any machine-specific information associated with your new machine. - Before the <filename>.bbappend</filename> extension was introduced, you would have to copy the whole - pointercal recipe and files into your layer and then add the single file for your machine. - </para> - <para> - With the <filename>.bbappend</filename> extension, however, your work becomes much easier. - This extension allows you to easily merge BSP-specific information with the original recipe. - Whenever BitBake finds any <filename>.bbappend</filename> files BitBake will include them after - it loads the associated <filename>.bb</filename> file but before any finalize - or anonymous methods are run. - This allows the BSP layer to do whatever it might want to do to customize the original recipe. - </para> - <para> - If your recipe needs to reference extra files it can use the FILESEXTRAPATHS variable - to specify their location. - The example below shows extra files contained in a folder called ${PN} (the package name). - </para> - <programlisting> -FILESEXTRAPATHS := "${THISDIR}/${PN}" - </programlisting> - <para> - This technique allows the BSP to add machine-specific configuration files to the layer directory, - which will be picked up by BitBake. - For an example see <filename>meta-emenlow/packages/formfactor</filename>. - </para> - </section> - - <section id="bsp-filelayout-prebuilds"> - <title>Pre-build Data (meta-<bsp_name>/prebuilds/*)</title> - <para> - This location can contain precompiled representations of the source code - contained elsewhere in the BSP layer. - Assuming a compatible configuration is used, Poky can process and use these optional pre-compiled - representations to provide much faster build times. - </para> - </section> --> - </section> - - <section id='bsp-click-through-licensing'> - <title>BSP 'Click-Through' Licensing Procedure</title> - - <note><para> This section describes how - click-through licensing is expected to work. - Currently, this functionality is not yet implemented. - </para></note> - - <para> - In some cases, a BSP contains separately licensed IP - (Intellectual Property) for a component that imposes - upon the user a requirement to accept the terms of a - 'click-through' license. - Once the license is accepted the - Poky build system can then build and include the - corresponding component in the final BSP image. - Some affected components might be essential to the normal - functioning of the system and have no 'free' replacement - (i.e. the resulting system would be non-functional - without them). - On the other hand, other components might be simply - 'good-to-have' or purely elective, or if essential - nonetheless have a 'free' (possibly less-capable) - version that could be used as a in the BSP recipe. - </para> - - <para> - For cases where you can substitute something and still maintain functionality, - the Yocto Project website at - <ulink url='http://yoctoproject.org/download/board-support-package-bsp-downloads'></ulink> - will make available a 'de-featured' BSP completely free of the encumbered IP. - In that case you can use the substitution directly and without any further licensing - requirements. - If present, this fully 'de-featured' BSP will be named appropriately different - than the normal encumbered BSP. - If available, this substitution is the simplest and most preferred option. - This, of course, assumes the resulting functionality meets requirements. - </para> - - <para> - If however, a non-encumbered version is unavailable or the 'free' version - would provide unsuitable functionality or quality, you can use - an encumbered version. - </para> - - <para> - Several methods exist within the Poky build system to satisfy the licensing - requirements for an encumbered BSP. - The following list describes them in preferential order: - </para> - - <orderedlist> - <listitem> - - <para> - Get a license key (or keys) for the encumbered BSP by visiting - a website and providing the name of the BSP and your email address - through a web form. - </para> - -<!-- - <ulink url='https://pokylinux.org/bsp-keys.html'>https://pokylinux.org/bsp-keys.html</ulink> - and give the name of the BSP and your e-mail address in the web form. - </para> - - COMMENT: This link is not implemented at this point. - - <programlisting> - [screenshot of dialog box] - </programlisting> - ---> - - <para> - After agreeing to any applicable license terms, the - BSP key(s) will be immediately sent to the address - you gave and you can use them by specifying BSPKEY_<keydomain> - environment variables when building the image: - </para> - - <programlisting> - $ BSPKEY_<keydomain>=<key> bitbake poky-image-sato - </programlisting> - - <para> - These steps allow the encumbered image to be built - with no change at all to the normal build process. - </para> - - <para> - Equivalently and probably more conveniently, a line - for each key can instead be put into the user's - <filename>local.conf</filename> file. - </para> - - <para> - The <keydomain> component of the - BSPKEY_<keydomain> is required because there - might be multiple licenses in effect for a given BSP. - In such cases, a given <keydomain> corresponds to - a particular license. In order for an encumbered - BSP that encompasses multiple key domains to be built - successfully, a <keydomain> entry for each - applicable license must be present in <filename>local.conf</filename> or - supplied on the command-line. - </para> - </listitem> - <listitem> - <para> - Do nothing - build as you normally would. - When a license is needed the build will stop and prompt you with instructions. - Follow the license prompts that originate from the - encumbered BSP. - These prompts usually take the form of instructions - needed to manually fetch the encumbered package(s) - and md5 sums into the required directory - (e.g. the <filename>poky/build/downloads</filename>). - Once the manual package fetch has been - completed, restart the build to continue where - it left off. - During the build the prompt will not appear again since you have satisfied the - requirement. - </para> - </listitem> - <listitem> - <para> - Get a full-featured BSP recipe rather than a key. - You can do this by visiting the applicable BSP download page from the Yocto - Project website at - <ulink url='http://yoctoproject.org/download/board-support-package-bsp-downloads'></ulink>. - BSP tarballs that have proprietary information can be downloaded after agreeing - to licensing requirements as part of the download process. - Obtaining the code this way allows you to build an encumbered image with - no changes at all as compared to the normal build. - </para> - </listitem> - </orderedlist> - <para> - Note that the third method is also the only option available - when downloading pre-compiled images generated from non-free BSPs. - Those images are likewise available at from the Yocto Project website. - </para> - </section> - -</chapter> diff --git a/documentation/bsp-guide/figures/bsp-title.png b/documentation/bsp-guide/figures/bsp-title.png Binary files differdeleted file mode 100644 index ee383141f0..0000000000 --- a/documentation/bsp-guide/figures/bsp-title.png +++ /dev/null diff --git a/documentation/bsp-guide/figures/poky-ref-manual.png b/documentation/bsp-guide/figures/poky-ref-manual.png Binary files differdeleted file mode 100644 index 333442e0d6..0000000000 --- a/documentation/bsp-guide/figures/poky-ref-manual.png +++ /dev/null diff --git a/documentation/bsp-guide/style.css b/documentation/bsp-guide/style.css deleted file mode 100644 index 9d068a0f56..0000000000 --- a/documentation/bsp-guide/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/bsp-title.png"); - background-position: left top; - margin-top: -256px; - padding-right: 50px; - margin-left: 0px; - text-align: right; - width: 740px; -} - -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/kernel-manual/Makefile b/documentation/kernel-manual/Makefile deleted file mode 100644 index a2eaced586..0000000000 --- a/documentation/kernel-manual/Makefile +++ /dev/null @@ -1,42 +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 kernel-manual.xml ../template - -## -# These URI should be rewritten by your distribution's xml catalog to -# match your localy installed XSL stylesheets. - -html: -# See http://www.sagehill.net/docbookxsl/HtmlOutput.html - -# xsltproc $(XSLTOPTS) -o yocto-project-qs.html $(XSL_XHTML_URI) yocto-project-qs.xml - xsltproc $(XSLTOPTS) -o kernel-manual.html yocto-project-kernel-manual-customization.xsl kernel-manual.xml - -tarball: html - tar -cvzf kernel-manual.tgz kernel-manual.html kernel-manual.pdf style.css figures/kernel-title.png figures/kernel-big-picture.png figures/kernel-architecture-overview.png - -validate: - xmllint --postvalid --xinclude --noout kernel-manual.xml - -OUTPUTS = kernel-manual.tgz kernel-manual.html kernel-manual.pdf -SOURCES = *.png *.xml *.css - -publish: - scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/ - -clean: - rm -f $(OUTPUTS) diff --git a/documentation/kernel-manual/figures/kernel-architecture-overview.png b/documentation/kernel-manual/figures/kernel-architecture-overview.png Binary files differdeleted file mode 100755 index 2aad172db3..0000000000 --- a/documentation/kernel-manual/figures/kernel-architecture-overview.png +++ /dev/null diff --git a/documentation/kernel-manual/figures/kernel-big-picture.png b/documentation/kernel-manual/figures/kernel-big-picture.png Binary files differdeleted file mode 100755 index 49bac618ec..0000000000 --- a/documentation/kernel-manual/figures/kernel-big-picture.png +++ /dev/null diff --git a/documentation/kernel-manual/figures/kernel-title.png b/documentation/kernel-manual/figures/kernel-title.png Binary files differdeleted file mode 100644 index 965264ccc5..0000000000 --- a/documentation/kernel-manual/figures/kernel-title.png +++ /dev/null diff --git a/documentation/kernel-manual/figures/yocto-project-transp.png b/documentation/kernel-manual/figures/yocto-project-transp.png Binary files differdeleted file mode 100755 index 31d2b147fd..0000000000 --- a/documentation/kernel-manual/figures/yocto-project-transp.png +++ /dev/null diff --git a/documentation/kernel-manual/kernel-concepts.xml b/documentation/kernel-manual/kernel-concepts.xml deleted file mode 100644 index f26e2903eb..0000000000 --- a/documentation/kernel-manual/kernel-concepts.xml +++ /dev/null @@ -1,335 +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='kernel-concepts'> - -<title>Yocto Project Kernel Concepts</title> - -<section id='concepts-org'> - <title>Introduction</title> - <para> - This chapter provides conceptual information about the Yocto Project kernel: - <itemizedlist> - <listitem><para>Kernel Goals</para></listitem> - <listitem><para>Yocto Project Kernel Development and Maintenance Overview</para></listitem> - <listitem><para>Kernel Architecture</para></listitem> - <listitem><para>Kernel Tools</para></listitem> - </itemizedlist> - </para> -</section> - - <section id='kernel-goals'> - <title>Kernel Goals</title> - <para> - The complexity of embedded kernel design has increased dramatically. - Whether it is managing multiple implementations of a particular feature or tuning and - optimizing board specific features, flexibility and maintainability are key concerns. - The Yocto Project Linux kernel is presented with the embedded - developer's needs in mind and has evolved to assist in these key concerns. - For example, prior methods such as applying hundreds of patches to an extracted - tarball have been replaced with proven techniques that allow easy inspection, - bisection and analysis of changes. - Application of these techniques also creates a platform for performing integration and - collaboration with the thousands of upstream development projects. - </para> - <para> - With all these considerations in mind, the Yocto Project kernel and development team - strives to attain these goals: - <itemizedlist> - <listitem><para>Allow the end user to leverage community best practices to seamlessly - manage the development, build and debug cycles.</para></listitem> - <listitem><para>Create a platform for performing integration and collaboration with the - thousands of upstream development projects that exist.</para></listitem> - <listitem><para>Provide mechanisms that support many different work flows, front-ends and - management techniques.</para></listitem> - <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that - the baseline kernel is the most stable official release.</para></listitem> - <listitem><para>Include major technological features as part of Yocto Project's up-rev - strategy.</para></listitem> - <listitem><para>Present a git tree, that just like the upstream kernel.org tree, has a - clear and continuous history.</para></listitem> - <listitem><para>Deliver a key set of supported kernel types, where each type is tailored - to a specific use case (i.g. networking, consumer, devices, and so forth).</para></listitem> - <listitem><para>Employ a git branching strategy that from a customer's point of view - results in a linear path from the baseline kernel.org, through a select group of features and - ends with their BSP-specific commits.</para></listitem> - </itemizedlist> - </para> - </section> - - <section id='kernel-big-picture'> - <title>Yocto Project Kernel Development and Maintenance Overview</title> - <para> - Yocto Project kernel, like other kernels, is based off the Linux kernel release - from <ulink url='http://www.kernel.org'></ulink>. - At the beginning of our major development cycle, we choose our Yocto Project kernel - based on factors like release timing, the anticipated release timing of "final" (i.e. non "rc") - upstream kernel.org versions, and Yocto Project feature requirements. - Typically this will be a kernel that is in the - final stages of development by the community (i.e. still in the release - candidate or "rc" phase) and not yet a final release. - But by being in the final stages of external development, we know that the - kernel.org final release will clearly land within the early stages of - the Yocto Project development window. - </para> - <para> - This balance allows us to deliver the most up-to-date kernel - as possible, while still ensuring that we have a stable official release as - our baseline kernel version. - </para> - <para> - The ultimate source for the Yocto Project kernel is a released kernel - from kernel.org. - In addition to a foundational kernel from kernel.org the released - Yocto Project kernel contains a mix of important new mainline - developments, non-mainline developments (when there is no alternative), - Board Support Package (BSP) developments, - and custom features. - These additions result in a commercially released Yocto Project kernel that caters - to specific embedded designer needs for targeted hardware. - </para> -<!-- <para> - The following figure represents the overall place the Yocto Project kernel fills. - </para> - <para> - <imagedata fileref="figures/kernel-big-picture.png" width="6in" depth="6in" align="center" scale="100" /> - </para> - <para> - In the figure the ultimate source for the Yocto Project kernel is a released kernel - from kernel.org. - In addition to a foundational kernel from kernel.org the commercially released - Yocto Project kernel contains a mix of important new mainline - developments, non-mainline developments, Board Support Package (BSP) developments, - and custom features. - These additions result in a commercially released Yocto Project kernel that caters - to specific embedded designer needs for targeted hardware. - </para> --> - <para> - Once a Yocto Project kernel is officially released the Yocto Project team goes into - their next development cycle, or "uprev" cycle while continuing maintenance on the - released kernel. - It is important to note that the most sustainable and stable way - to include feature development upstream is through a kernel uprev process. - Back-porting of hundreds of individual fixes and minor features from various - kernel versions is not sustainable and can easily compromise quality. - During the uprev cycle, the Yocto Project team uses an ongoing analysis of - kernel development, BSP support, and release timing to select the best - possible kernel.org version. - The team continually monitors community kernel - development to look for significant features of interest. -<!-- The illustration depicts this by showing the team looking back to kernel.org for new features, - BSP features, and significant bug fixes. --> - The team does consider back-porting large features if they have a significant advantage. - User or community demand can also trigger a back-port or creation of new - functionality in the Yocto Project baseline kernel during the uprev cycle. - </para> - <para> - Generally speaking, every new kernel both adds features and introduces new bugs. - These consequences are the basic properties of upstream kernel development and are - managed by the Yocto Project team's kernel strategy. - It is the Yocto Project team's policy to not back-port minor features to the released kernel. - They only consider back-porting significant technological jumps - and, that is done - after a complete gap analysis. - The reason for this policy is that simply back-porting any small to medium sized change - from an evolving kernel can easily create mismatches, incompatibilities and very - subtle errors. - </para> - <para> - These policies result in both a stable and a cutting - edge kernel that mixes forward ports of existing features and significant and critical - new functionality. - Forward porting functionality in the Yocto Project kernel can be thought of as a - "micro uprev." - The many “micro uprevs” produce a kernel version with a mix of - important new mainline, non-mainline, BSP developments and feature integrations. - This kernel gives insight into new features and allows focused - amounts of testing to be done on the kernel, which prevents - surprises when selecting the next major uprev. - The quality of these cutting edge kernels is evolving and the kernels are used in leading edge - feature and BSP development. - </para> - </section> - - <section id='kernel-architecture'> - <title>Kernel Architecture</title> - <para> - This section describes the architecture of the Yocto Project kernel and provides information - on the mechanisms used to achieve that architecture. - </para> - - <section id='architecture-overview'> - <title>Overview</title> - <para> - As mentioned earlier, a key goal of Yocto Project is to present the developer with - a kernel that has a clear and continuous history that is visible to the user. - The architecture and mechanisms used achieve that goal in a manner similar to the - upstream kernel.org. - - </para> - <para> - You can think of the Yocto Project kernel as consisting of a baseline kernel with - added features logically structured on top of the baseline. - The features are tagged and organized by way of a branching strategy implemented by the - source code manager (SCM) git. - The result is that the user has the ability to see the added features and - the commits that make up those features. - In addition to being able to see added features, the user can also view the history of what - made up the baseline kernel as well. - </para> - <para> - The following illustration shows the conceptual Yocto Project kernel. - </para> - <para> - <imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" /> - </para> - <para> - In the illustration, the "kernel.org Branch Point" marks the specific spot (or release) from - which the Yocto Project kernel is created. From this point "up" in the tree features and - differences are organized and tagged. - </para> - <para> - The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel - type and BSP that is organized further up the tree. Placing these common features in the - tree this way means features don't have to be duplicated along individual branches of the - structure. - </para> - <para> - From the Yocto Project Baseline Kernel branch points represent specific functionality - for individual BSPs as well as real-time kernels. - The illustration represents this through three BSP-specific branches and a real-time - kernel branch. - Each branch represents some unique functionality for the BSP or a real-time kernel. - </para> - <para> - In this example structure, the real-time kernel branch has common features for all - real-time kernels and contains - more branches for individual BSP-specific real-time kernels. - The illustration shows three branches as an example. - Each branch points the way to specific, unique features for a respective real-time - kernel as they apply to a given BSP. - </para> - <para> - The resulting tree structure presents a clear path of markers (or branches) to the user - that for all practical purposes is the kernel needed for any given set of requirements. - </para> - </section> - - <section id='branching-and-workflow'> - <title>Branching Strategy and Workflow</title> - <para> - The Yocto Project team creates kernel branches at points where functionality is - no longer shared and thus, needs to be isolated. - For example, board-specific incompatibilities would require different functionality - and would require a branch to separate the features. - Likewise, for specific kernel features the same branching strategy is used. - This branching strategy results in a tree that has features organized to be specific - for particular functionality, single kernel types, or a subset of kernel types. - This strategy results in not having to store the same feature twice internally in the - tree. - Rather we store the unique differences required to apply the feature onto the kernel type - in question. - </para> - <note><para> - The Yocto Project team strives to place features in the tree such that they can be - shared by all boards and kernel types where possible. - However, during development cycles or when large features are merged this practice - cannot always be followed. - In those cases isolated branches are used for feature merging. - </para></note> - <para> - BSP-specific code additions are handled in a similar manner to kernel-specific additions. - Some BSPs only make sense given certain kernel types. - So, for these types, we create branches off the end of that kernel type for all - of the BSPs that are supported on that kernel type. - From the perspective of the tools that create the BSP branch, the BSP is really no - different than a feature. - Consequently, the same branching strategy applies to BSPs as it does to features. - So again, rather than store the BSP twice, only the unique differences for the BSP across - the supported multiple kernels are uniquely stored. - </para> - <para> - While this strategy can result in a tree with a significant number of branches, it is - important to realize that from the user's point of view, there is a linear - path that travels from the baseline kernel.org, through a select group of features and - ends with their BSP-specific commits. - In other words, the divisions of the kernel are transparent and are not relevant - to the developer on a day-to-day basis. - From the user's perspective, this is the "master" branch. - They do not need not be aware of the existence of any other branches at all. - Of course there is value in the existence of these branches - in the tree, should a person decide to explore them. - For example, a comparison between two BSPs at either the commit level or at the line-by-line - code diff level is now a trivial operation. - </para> - <para> - Working with the kernel as a structured tree follows recognized community best practices. - In particular, the kernel as shipped with the product should be - considered an 'upstream source' and viewed as a series of - historical and documented modifications (commits). - These modifications represent the development and stabilization done - by the Yocto Project kernel development team. - </para> - <para> - Because commits only change at significant release points in the product life cycle, - developers can work on a branch created - from the last relevant commit in the shipped Yocto Project kernel. - As mentioned previously, the structure is transparent to the user - because the kernel tree is left in this state after cloning and building the kernel. - </para> - </section> - - <section id='source-code-manager-git'> - <title>Source Code Manager - git</title> - <para> - The Source Code Manager (SCM) is git and it is the obvious mechanism for meeting the - previously mentioned goals. - Not only is it the SCM for kernel.org but git continues to grow in popularity and - supports many different work flows, front-ends and management techniques. - </para> - <note><para> - It should be noted that you can use as much, or as little, of what git has to offer - as is appropriate to your project. - </para></note> - </section> - </section> - - <section id='kernel-tools'> - <title>Kernel Tools</title> - <para> -Since most standard workflows involve moving forward with an existing tree by -continuing to add and alter the underlying baseline, the tools that manage -Yocto Project's kernel construction are largely hidden from the developer to -present a simplified view of the kernel for ease of use. -</para> -<para> -The fundamental properties of the tools that manage and construct the -kernel are: -<itemizedlist> - <listitem><para>the ability to group patches into named, reusable features</para></listitem> - <listitem><para>to allow top down control of included features</para></listitem> - <listitem><para>the binding of kernel configuration to kernel patches/features</para></listitem> - <listitem><para>the presentation of a seamless git repository that blends Yocto Project value with the kernel.org history and development</para></listitem> -</itemizedlist> -</para> -<!--<para> -The tools that construct a kernel tree will be discussed later in this -document. The following tools form the foundation of the Yocto Project -kernel toolkit: -<itemizedlist> - <listitem><para>git : distributed revision control system created by Linus Torvalds</para></listitem> - <listitem><para>guilt: quilt on top of git</para></listitem> - <listitem><para>*cfg : kernel configuration management and classification</para></listitem> - <listitem><para>kgit*: Yocto Project kernel tree creation and management tools</para></listitem> - <listitem><para>scc : series & configuration compiler</para></listitem> -</itemizedlist> -</para> --> - </section> - - - - - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/kernel-manual/kernel-doc-intro.xml b/documentation/kernel-manual/kernel-doc-intro.xml deleted file mode 100644 index 05e5443b85..0000000000 --- a/documentation/kernel-manual/kernel-doc-intro.xml +++ /dev/null @@ -1,57 +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='kernel-doc-intro'> - -<title>Yocto Project Kernel Architecture and Use Manual</title> - -<section id='book-intro'> - <title>Introduction</title> - <para> - The Yocto Project presents the kernel as a fully patched, history-clean git - repository. - The git tree represents the selected features, board support, - and configurations extensively tested by Yocto Project. - The Yocto Project kernel allows the end user to leverage community - best practices to seamlessly manage the development, build and debug cycles. - </para> - <para> - This manual describes the Yocto Project kernel by providing information - on its history, organization, benefits, and use. - The manual consists of two sections: - <itemizedlist> - <listitem><para>Concepts - Describes concepts behind the kernel. - You will understand how the kernel is organized and why it is organized in - the way it is. You will understand the benefits of the kernel's organization - and the mechanisms used to work with the kernel and how to apply it in your - design process.</para></listitem> - <listitem><para>Using the Kernel - Describes best practices and "how-to" information - that lets you put the kernel to practical use. Some examples are "How to Build a - Project Specific Tree", "How to Examine Changes in a Branch", and "Saving Kernel - Modifications."</para></listitem> - </itemizedlist> - </para> - <para> - For more information on the kernel, see the following links: - <itemizedlist> - <listitem><para><ulink url='http://ldn.linuxfoundation.org/book/1-a-guide-kernel-development-process'></ulink></para></listitem> - <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem> - <listitem><para><ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem> - </itemizedlist> - <para> - You can find more information on Yocto Project by visiting the website at - <ulink url='http://www.yoctoproject.org'></ulink>. - </para> - </para> -</section> - - - - - - - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/kernel-manual/kernel-how-to.xml b/documentation/kernel-manual/kernel-how-to.xml deleted file mode 100644 index 96325fe2a5..0000000000 --- a/documentation/kernel-manual/kernel-how-to.xml +++ /dev/null @@ -1,2178 +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='kernel-how-to'> - -<title>Working with the Yocto Project Kernel</title> - - -<section id='actions-org'> - <title>Introduction</title> - <para> - This chapter describes how to accomplish tasks involving the kernel's tree structure. - The information covers the following: - <itemizedlist> - <listitem><para>Tree construction</para></listitem> - <listitem><para>Build strategies</para></listitem> -<!-- <listitem><para>Series & Configuration Compiler</para></listitem> - <listitem><para>kgit</para></listitem> --> - <listitem><para>Workflow examples</para></listitem> -<!-- <listitem><para>Source Code Manager (SCM)</para></listitem> - <listitem><para>Board Support Package (BSP) template migration</para></listitem> - <listitem><para>BSP creation</para></listitem> - <listitem><para>Patching</para></listitem> - <listitem><para>Updating BSP patches and configuration</para></listitem> - <listitem><para>guilt</para></listitem> - <listitem><para>scc file example</para></listitem> - <listitem><para>"dirty" string</para></listitem> - <listitem><para>Transition kernel layer</para></listitem> --> - </itemizedlist> - </para> -</section> - - <section id='tree-construction'> - <title>Tree Construction</title> - <para> - The Yocto Project kernel repository, as shipped with the product, is created by - compiling and executing the set of feature descriptions for every BSP/feature - in the product. - Those feature descriptions list all necessary patches, - configuration, branching, tagging and feature divisions found in the kernel. - </para> - <para> - You can find the files used to describe all the valid features and BSPs in the Yocto Project - kernel in any clone of the kernel git tree. - The directory <filename>meta/cfg/kernel-cache/</filename> is a snapshot of all the kernel - configuration and feature descriptions (.scc) used to build the kernel repository. - You should realize, however, that browsing the snapshot of feature - descriptions and patches is not an effective way to determine what is in a - particular kernel branch. - Instead, you should use git directly to discover the changes - in a branch. - Using git is a efficient and flexible way to inspect changes to the kernel. - For examples showing how to use git to inspect kernel commits, see the following sections - in this chapter. - </para> - <note><para> - Ground up reconstruction of the complete kernel tree is an action only taken by the - Yocto Project team during an active development cycle. - Creating a project simply clones this tree to make it efficiently available for building - and development. - </para></note> - <para> - The general flow for constructing a project-specific kernel tree is as follows: - <orderedlist> - <listitem><para>A top-level kernel feature is passed to the kernel build subsystem. - Normally, this is a BSP for a particular kernel type.</para></listitem> - - <listitem><para>The file that describes the top-level feature is located by searching - these system directories:</para> - - <itemizedlist> - <listitem><para>The in-tree kernel-cache directories</para></listitem> -<!-- <listitem><para>kernel-*-cache directories in layers</para></listitem> --> - <listitem><para>Recipe SRC_URIs</para></listitem> -<!-- <listitem><para>configured and default templates</para></listitem> --> - </itemizedlist> - - <para>For a typical build a feature description of the format: - <bsp name>-<kernel type>.scc is the target of the search. - </para></listitem> - - <listitem><para>Once located, the feature description is either compiled into a simple script - of actions, or an existing equivalent script that was part of the - shipped kernel is located.</para></listitem> - - <listitem><para>Extra features are appended to the top-level feature description. - These features can come from the KERNEL_FEATURES variable in recipes.</para></listitem> - - <listitem><para>Each extra feature is located, compiled and appended to the script from - step #3</para></listitem> - - <listitem><para>The script is executed, and a meta-series is produced. - The meta-series is a description of all the branches, tags, patches and configuration that - needs to be applied to the base git repository to completely create the - BSP source (build) branch.</para></listitem> - - <listitem><para>The base repository is cloned, and the actions - listed in the meta-series are applied to the tree.</para></listitem> - - <listitem><para>The git repository is left with the desired branch checked out and any - required branching, patching and tagging has been performed.</para></listitem> - </orderedlist> - </para> - - <para> - The tree is now ready for configuration and compilation. - </para> - - <note><para>The end-user generated meta-series adds to the kernel as shipped with - the Yocto Project release. - Any add-ons and configuration data are applied to the end of an existing branch. - The full repository generation that is found in the - official Yocto Project kernel repositories is the combination of all - supported boards and configurations.</para> - - <para>This technique is flexible and allows the seamless blending of an immutable - history with additional deployment specific patches. - Any additions to the kernel become an integrated part of the branches. - </para></note> - -<!-- <note><para>It is key that feature descriptions indicate if any branches are - required, since the build system cannot automatically decide where a - BSP should branch or if that branch point needs a name with - significance. There is a single restriction enforced by the compilation - phase: - </para> - <para>A BSP must create a branch of the format <bsp name>-<kernel type>.</para> - - <para>This means that all merged/support BSPs must indicate where to start - its branch from, with the right name, in its .scc files. The scc - section describes the available branching commands in more detail. - </para> -</note> --> - -<!-- <para> -A summary of end user tree construction activities follow: -<itemizedlist> - <listitem><para>compile and link a full top-down kernel description from feature descriptions</para></listitem> - <listitem><para>execute the complete description to generate a meta-series</para></listitem> - <listitem><para>interpret the meta-series to create a customized git repository for the - board</para></listitem> - <listitem><para>migrate configuration fragments and configure the kernel</para></listitem> - <listitem><para>checkout the BSP branch and build</para></listitem> -</itemizedlist> -</para> --> - </section> - - <section id='build-strategy'> - <title>Build Strategy</title> - <para> - There are some prerequisites that must be met before starting the compilation - phase of the kernel build system: - </para> - - <itemizedlist> - <listitem><para>There must be a kernel git repository indicated in the SRC_URI.</para></listitem> - <listitem><para>There must be a BSP build branch - <bsp name>-<kernel type> in 0.9 or - <kernel type>/<bsp name> in 1.0.</para></listitem> - </itemizedlist> - - <para> - You can typically meet these prerequisites by running the tree construction/patching phase - of the build system. - However, other means do exist. - For examples of alternate workflows such as bootstrapping a BSP, see - the<link linkend='workflow-examples'> Workflow Examples</link> section in this manual. - </para> - - <para> - Before building a kernel it is configured by processing all of the - configuration "fragments" specified by the scc feature descriptions. - As the features are compiled, associated kernel configuration fragments are noted - and recorded in the meta-series in their compilation order. - The fragments are migrated, pre-processed and passed to the Linux Kernel - Configuration subsystem (lkc) as raw input in the form of a <filename>.config</filename> file. - The lkc uses its own internal dependency constraints to do the final - processing of that information and generates the final <filename>.config</filename> file - that is used during compilation. - </para> - - <para> - Using the board's architecture and other relevant values from the board's template - the Kernel compilation is started and a kernel image is produced. - </para> - - <para>The other thing that you will first see once you configure a kernel is that - it will generate a build tree that is separate from your git source tree. - This build tree has the name using the following form: - <literallayout class='monospaced'> - linux-<BSPname>-<kerntype>-build - </literallayout> - "kerntype" is one of the standard kernel types. - </para> - - <para> - The existing support in the kernel.org tree achieves this default functionality. - </para> - - <para> - What this means, is that all the generated files for a particular BSP are now in this directory. - The files include the final <filename>.config</filename>, all the <filename>.o</filename> - files, the <filename>.a</filename> files, and so forth. - Since each BSP has its own separate build directory in its own separate branch - of the git tree you can easily switch between different BSP builds. - </para> - </section> - -<!-- <section id='scc'> - <title>Series & Configuration Compiler (SCC)</title> -<para> -In early versions of the product, kernel patches were simply listed in a flat -file called "patches.list", and then quilt was added as a tool to help -traverse this list, which in quilt terms was called a "series" file. -</para> -<para> -Before the 2.0 release, it was already apparent that a static series file was -too inflexible, and that the series file had to become more dynamic and rely -on certain state (like kernel type) in order to determine whether a patch was -to be used or not. The 2.0 release already made use of some stateful -construction of series files, but since the delivery mechanism was unchanged -(tar + patches + series files), most people were not aware of anything really -different. The 3.0 release continues with this stateful construction of -series files, but since the delivery mechanism is changed (git + branches) it -now is more apparent to people. -</para> -<para> -As was previously mentioned, scc is a "series and configuration -compiler". Its role is to combine feature descriptions into a format that can -be used to generate a meta-series. A meta series contains all the required -information to construct a complete set of branches that are required to -build a desired board and feature set. The meta series is interpreted by the -kgit tools to create a git repository that could be built. -</para> -<para> -To illustrate how scc works, a feature description must first be understood. -A feature description is simply a small bash shell script that is executed by -scc in a controlled environment. Each feature description describes a set of -operations that add patches, modify existing patches or configure the -kernel. It is key that feature descriptions can include other features, and -hence allow the division of patches and configuration into named, reusable -containers. -</para> -<para> -Each feature description can use any of the following valid scc commands: -<itemizedlist> - <listitem><para>shell constructs: bash conditionals and other utilities can be used in a feature - description. During compilation, the working directory is the feature - description itself, so any command that is "raw shell" and not from the - list of supported commands, can not directly modify a git repository.</para></listitem> - - <listitem><para>patch <relative path>/<patch name>: outputs a patch to be included in a feature's patch set. Only the name of - the patch is supplied, the path is calculated from the currently set - patch directory, which is normally the feature directory itself.</para></listitem> - - <listitem><para>patch_trigger >condition< >action< <tgt>: indicate that a trigger should be set to perform an action on a - patch.</para> - -<para>The conditions can be: - - <itemizedlist> - <listitem><para>arch:<comma separated arch list or "all"></para></listitem> - <listitem><para>plat:<comma separated platform list or "all"></para></listitem> - </itemizedlist></para> -<para>The action can be: - <itemizedlist> - <listitem><para>exclude: This is used in exceptional situations where a patch - cannot be applied for certain reasons (arch or platform). - When the trigger is satisfied the patch will be removed from - the patch list.</para></listitem> - <listitem><para>include: This is used to include a patch only for a specific trigger. - Like exclude, this should only be used when necessary. - It takes 1 argument, the patch to include.</para></listitem> - </itemizedlist></para></listitem> - - <listitem><para>include <feature name> [after <feature>]: includes a feature for processing. The feature is "expanded" at the - position of the include directive. This means that any patches, - configuration or sub-includes of the feature will appear in the final - series before the commands that follow the include.</para> - <para> - include searches the include directories for a matching feature name, - include directories are passed to scc by the caller using -I <path> and - is transparent to the feature script. This means that <feature name> must - be relative to one of the search paths. For example, if - /opt/kernel-cache/feat/sched.scc is to be included and scc is invoked - with -I /opt/kernel-cache, then a feature would issue "include - feat/sched.scc" to include the feature. -</para> -<para> - The optional "after" directive allows a feature to modify the existing - order of includes and insert a feature after the named feature is - processed. Note: the "include foo after bar" must be issued before "bar" - is processed, so is normally only used by a new top level feature to - modify the order of features in something it is including.</para></listitem> - - <listitem><para>exclude <feature name>: Indicates that a particular feature should *not* be included even if an - 'include' directive is found. The exclude must be issued before the - include is processed, so is normally only used by a new top level feature - to modify the order of features in something it is including.</para></listitem> - - <listitem><para>git <command>: Issues any git command during tree construction. Note: this command is - not validated/sanitized so care must be taken to not damage the - tree. This can be used to script branching, tagging, pulls or other git - operations.</para></listitem> - - <listitem><para>dir <directory>: changes the working directory for "patch" directives. This can be used to - shorten a long sequence of patches by not requiring a common relative - directory to be issued each time.</para></listitem> - - <listitem><para>kconf <type> <fragment name>: associates a kernel config frag with the feature. - <type> can be - "hardware" or "non-hardware" and is used by the kernel configuration - subsystem to audit configuration. <fragment name> is the name of a file - in the current feature directory that contains a series of kernel - configuration options. There is no restriction on the chosen fragment - name, although a suffix of ".cfg" is recommended. Multiple fragment - specifications are supported.</para></listitem> - - <listitem><para>branch <branch name>: creates a branch in the tree. All subsequent patch commands will be - applied to the new branch and changes isolated from the rest of the - repository.</para></listitem> - - <listitem><para>scc_leaf <base feature> <branch name>: Performs a combination feature include and branch. This is mainly a - convenience directive, but has significance to some build system bindings - as a sentinel to indicate that this intends to create a branch that is - valid for kernel compilation.</para></listitem> - - <listitem><para>tag <tag name>: Tags the tree. The tag will be applied in processing order, so will - be after already applied patches and precede patches yet to be applied.</para></listitem> - - <listitem><para>define <var> <value>: Creates a variable with a particular value that can be used in subsequent - feature descriptions.</para></listitem> -</itemizedlist> - -</para> - </section> --> - -<!-- <section id='kgit-tools'> - <title>kgit Tools</title> -<para> -The kgit tools are responsible for constructing and maintaining the Wind -River kernel repository. These activities include importing, exporting, and -applying patches as well as sanity checking and branch management. From the -developers perspective, the kgit tools are hidden and rarely require -interactive use. But one tool in particular that warrants further description -is "kgit-meta". -</para> -<para> -kgit-meta is the actual application of feature description(s) to a kernel repo. -In other words, it is responsible for interpreting the meta series generated -from a scc compiled script. As a result, kgit-meta is coupled to the set of -commands permitted in a .scc feature description (listed in the scc section). -kgit-meta understands both the meta series format and how to use git and -guilt to modify a base git repository. It processes a meta-series line by -line, branching, tagging, patching and tracking changes that are made to the -base git repository. -</para> -<para> -Once kgit-meta has processed a meta-series, it leaves the repository with the -last branch checked out, and creates the necessary guilt infrastructure to -inspect the tree, or add to it via using guilt. As was previously mentioned, -guilt is not required, but is provided as a convenience. Other utilities such -as quilt, stgit, git or others can also be used to manipulate the git -repository. -</para> - </section> --> - - <section id='workflow-examples'> - <title>Workflow Examples</title> - - <para> - As previously noted, the Yocto Project kernel has built in git integration. - However, these utilities are not the only way to work with the kernel repository. - Yocto Project has not made changes to git or to other tools that - would invalidate alternate workflows. - Additionally, the way the kernel repository is constructed results in using - only core git functionality thus allowing any number of tools or front ends to use the - resulting tree. - </para> - - <para> - This section contains several workflow examples. - </para> - - <section id='change-inspection-kernel-changes-commits'> - <title>Change Inspection: Kernel Changes/Commits</title> - - <para> - A common question when working with a BSP or kernel is: - "What changes have been applied to this tree?" - </para> - - <para> - In projects that have a collection of directories that - contain patches to the kernel it is possible to inspect or "grep" the contents - of the directories to get a general feel for the changes. - This sort of patch inspection is not an efficient way to determine what has been done to the - kernel. - The reason it is inefficient is because there are many optional patches that are - selected based on the kernel type and the feature description. - Additionally, patches could exist in directories that are not included in the search. - </para> - - <para> - A more efficient way to determine what has changed in the kernel is to use - git and inspect or search the kernel tree. - This method gives you a full view of not only the source code modifications, - but also provides the reasons for the changes. - </para> - - <section id='what-changed-in-a-bsp'> - <title>What Changed in a BSP?</title> - - <para> - Following are a few examples that show how to use git to examine changes. - Note that because the Yocto Project git repository does not break existing git - functionality and because there exists many permutations of these types of - commands there are many more methods to discover changes. - </para> - - <note><para> - Unless you provide a commit range - (<kernel-type>..<bsp>-<kernel-type>), kernel.org history - is blended with Yocto Project changes. - </para></note> - - <literallayout class='monospaced'> - # full description of the changes - > git whatchanged <kernel type>..<kernel type>/<bsp> - > eg: git whatchanged yocto/standard/base..yocto/standard/common-pc/base - - # summary of the changes - > git log --pretty=oneline --abbrev-commit <kernel type>..<kernel type>/<bsp> - - # source code changes (one combined diff) - > git diff <kernel type>..<kernel type>/<bsp> - > git show <kernel type>..<kernel type>/<bsp> - - # dump individual patches per commit - > git format-patch -o <dir> <kernel type>..<kernel type>/<bsp> - - # determine the change history of a particular file - > git whatchanged <path to file> - - # determine the commits which touch each line in a file - > git blame <path to file> - </literallayout> - </section> - - <section id='show-a-particular-feature-or-branch-change'> - <title>Show a Particular Feature or Branch Change</title> - - <para> - Significant features or branches are tagged in the Yocto Project tree to divide - changes. - Remember to first determine (or add) the tag of interest. - </para> - - <note><para> - Because BSP branch, kernel.org, and feature tags are all present, there are many tags. - </para></note> - - <literallayout class='monospaced'> - # show the changes tagged by a feature - > git show <tag> - > eg: git show yaffs2 - - # determine which branches contain a feature - > git branch --contains <tag> - - # show the changes in a kernel type - > git whatchanged yocto/base..<kernel type> - > eg: git whatchanged yocto/base..yocto/standard/base - </literallayout> - - <para> - You can use many other comparisons to isolate BSP changes. - For example, you can compare against kernel.org tags (e.g. v2.6.27.18, etc), or - you can compare against subsystems (e.g. git whatchanged mm). - </para> - </section> - </section> - - <section id='development-saving-kernel-modifications'> - <title>Development: Saving Kernel Modifications</title> - - <para> - Another common operation is to build a BSP supplied by Yocto Project, make some - changes, rebuild and then test. - Those local changes often need to be exported, shared or otherwise maintained. - </para> - - <para> - Since the Yocto Project kernel source tree is backed by git, this activity is - much easier as compared to with previous releases. - Because git tracks file modifications, additions and deletions, it is easy - to modify the code and later realize that the changes should be saved. - It is also easy to determine what has changed. - This method also provides many tools to commit, undo and export those modifications. - </para> - - <para> - There are many ways to save kernel modifications. - The technique employed - depends on the destination for the patches: - - <itemizedlist> - <listitem><para>Bulk storage</para></listitem> - <listitem><para>Internal sharing either through patches or by using git</para></listitem> - <listitem><para>External submissions</para></listitem> - <listitem><para>Exporting for integration into another SCM</para></listitem> - </itemizedlist> - </para> - - <para> - Because of the following list of issues, the destination of the patches also influences - the method for gathering them: - - <itemizedlist> - <listitem><para>Bisectability</para></listitem> - <listitem><para>Commit headers</para></listitem> - <listitem><para>Division of subsystems for separate submission or review</para></listitem> - </itemizedlist> - </para> - - <section id='bulk-export'> - <title>Bulk Export</title> - - <para> - This section describes how you can export in "bulk" changes that have not - been separated or divided. - This situation works well when you are simply storing patches outside of the kernel - source repository, either permanently or temporarily, and you are not committing - incremental changes during development. - </para> - - <note><para> - This technique is not appropriate for full integration of upstream submission - because changes are not properly divided and do not provide an avenue for per-change - commit messages. - Therefore, this example assumes that changes have not been committed incrementally - during development and that you simply must gather and export them. - </para></note> - - <literallayout class='monospaced'> - # bulk export of ALL modifications without separation or division - # of the changes - - > git add . - > git commit -s -a -m >commit message< - or - > git commit -s -a # and interact with $EDITOR - </literallayout> - - <para> - The previous operations capture all the local changes in the project source - tree in a single git commit. - And, that commit is also stored in the project's source tree. - </para> - - <para> - Once the changes are exported, you can restore them manually using a template - or through integration with the <filename>default_kernel</filename>. - </para> - - </section> - - <section id='incremental-planned-sharing'> - <title>Incremental/Planned Sharing</title> - - <para> - This section describes how to save modifications when you are making incremental - commits or practicing planned sharing. - The examples in this section assume that changes have been incrementally committed - to the tree during development and now need to be exported. The sections that follow - describe how you can export your changes internally through either patches or by - using git commands. - </para> - - <para> - During development the following commands are of interest. - For full git documentation, refer to the git man pages or to an online resource such - as <ulink url='http://github.com'></ulink>. - - <literallayout class='monospaced'> - # edit a file - > vi >path</file - # stage the change - > git add >path</file - # commit the change - > git commit -s - # remove a file - > git rm >path</file - # commit the change - > git commit -s - - ... etc. - </literallayout> - </para> - - <para> - Distributed development with git is possible when you use a universally - agreed-upon unique commit identifier (set by the creator of the commit) that maps to a - specific change set with a specific parent. - This identifier is created for you when - you create a commit, and is re-created when you amend, alter or re-apply - a commit. - As an individual in isolation, this is of no interest. - However, if you - intend to share your tree with normal git push and pull operations for - distributed development, you should consider the ramifications of changing a - commit that you have already shared with others. - </para> - - <para> - Assuming that the changes have not been pushed upstream, or pulled into - another repository, you can update both the commit content and commit messages - associated with development by using the following commands: - - <literallayout class='monospaced'> - > git add >path</file - > git commit --amend - > git rebase or git rebase -i - </literallayout> - </para> - - <para> - Again, assuming that the changes have not been pushed upstream, and that - no pending works-in-progress exist (use "git status" to check) then - you can revert (undo) commits by using the following commands: - - <literallayout class='monospaced'> - # remove the commit, update working tree and remove all - # traces of the change - > git reset --hard HEAD^ - # remove the commit, but leave the files changed and staged for re-commit - > git reset --soft HEAD^ - # remove the commit, leave file change, but not staged for commit - > git reset --mixed HEAD^ - </literallayout> - </para> - - <para> - You can create branches, "cherry-pick" changes or perform any number of git - operations until the commits are in good order for pushing upstream - or for pull requests. - After a push or pull, commits are normally considered - "permanent" and you should not modify them. - If they need to be changed you can incrementally do so with new commits. - These practices follow the standard "git" workflow and the kernel.org best - practices, which Yocto Project recommends. - </para> - - <note><para> - It is recommended to tag or branch before adding changes to a Yocto Project - BSP or before creating a new one. - The reason for this recommendation is because the branch or tag provides a - reference point to facilitate locating and exporting local changes. - </para></note> - - <section id='export-internally-via-patches'> - <title>Exporting Changes Internally by Using Patches</title> - - <para> - This section describes how you can extract committed changes from a working directory - by exporting them as patches. - Once extracted, you can use the patches for upstream submission, - place them in a Yocto Project template for automatic kernel patching, - or apply them in many other common uses. - </para> - - <para> - This example shows how to create a directory with sequentially numbered patches. - Once the directory is created, you can apply it to a repository using the - <filename>git am</filename> command to reproduce the original commit and all - the related information such as author, date, commit log, and so forth. - </para> - - <note><para> - The new commit identifiers (ID) will be generated upon re-application. - This action reflects that the commit is now applied to an underlying commit - with a different ID. - </para></note> - - <para> - <literallayout class='monospaced'> - # <first-commit> can be a tag if one was created before development - # began. It can also be the parent branch if a branch was created - # before development began. - - > git format-patch -o <dir> <first commit>..<last commit> - </literallayout> - </para> - - <para> - In other words: - <literallayout class='monospaced'> - # Identify commits of interest. - - # If the tree was tagged before development - > git format-patch -o <save dir> <tag> - - # If no tags are available - > git format-patch -o <save dir> HEAD^ # last commit - > git format-patch -o <save dir> HEAD^^ # last 2 commits - > git whatchanged # identify last commit - > git format-patch -o <save dir> <commit id> - > git format-patch -o <save dir> <rev-list> - </literallayout> - </para> - - <!--<para> - See the "template patching" example for how to use the patches to - automatically apply to a new kernel build. - </para>--> - </section> - - <section id='export-internally-via-git'> - <title>Exporting Changes Internally by Using git</title> - - <para> - This section describes how you can export changes from a working directory - by pushing the changes into a master repository or by making a pull request. - Once you have pushed the changes in the master repository you can then - pull those same changes into a new kernel build at a later time. - </para> - - <para> - Use this command form to push the changes: - <literallayout class='monospaced'> - git push ssh://<master server>/<path to repo> <local branch>:<remote branch> - </literallayout> - </para> - - <para> - For example, the following command pushes the changes from your local branch - <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name - in the master repository <filename>//git.mycompany.com/pub/git/kernel-2.6.37</filename>. - <literallayout class='monospaced'> - > push ssh://git.mycompany.com/pub/git/kernel-2.6.37 yocto/standard/common-pc/base:yocto/standard/common-pc/base - </literallayout> - </para> - - <para> - A pull request entails using "git request-pull" to compose an email to the - maintainer requesting that a branch be pulled into the master repository, see - <ulink url='http://github.com/guides/pull-requests'></ulink> for an example. - </para> - - <note><para> - Other commands such as 'git stash' or branching can also be used to save - changes, but are not covered in this document. - </para></note> - - <!--<para> - See the section "importing from another SCM" for how a git push to the - default_kernel, can be used to automatically update the builds of all users - of a central git repository. - </para>--> - </section> - </section> - - <section id='export-for-external-upstream-submission'> - <title>Exporting Changes for External (Upstream) Submission</title> - - <para> - This section describes how to export changes for external upstream submission. - If the patch series is large or the maintainer prefers to pull - changes, you can submit these changes by using a pull request. - However, it is common to sent patches as an email series. - This method allows easy review and integration of the changes. - </para> - - <note><para> - Before sending patches for review be sure you understand the - community standards for submitting and documenting changes and follow their best practices. - For example, kernel patches should follow standards such as: - <itemizedlist> - <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem> - <listitem><para><ulink url='http://linux.yyz.us/patch-format.html'></ulink></para></listitem> - <listitem><para>Documentation/SubmittingPatches (in any linux kernel source tree)</para></listitem> - </itemizedlist> - </para></note> - - <para> - The messages used to commit changes are a large part of these standards. - Consequently, be sure that the headers for each commit have the required information. - If the initial commits were not properly documented or do not meet those standards, - you can re-base by using the "git rebase -i" command to manipulate the commits and - get them into the required format. - Other techniques such as branching and cherry-picking commits are also viable options. - </para> - - <para> - Once you complete the commits, you can generate the email that sends the patches - to the maintainer(s) or lists that review and integrate changes. - The command "git send-email" is commonly used to ensure that patches are properly - formatted for easy application and avoid mailer-induced patch damage. - </para> - - <para> - The following is an example of dumping patches for external submission: - <literallayout class='monospaced'> - # dump the last 4 commits - > git format-patch --thread -n -o ~/rr/ HEAD^^^^ - > git send-email --compose --subject '[RFC 0/N] <patch series summary>' \ - --to foo@yoctoproject.org --to bar@yoctoproject.org \ - --cc list@yoctoproject.org ~/rr - # the editor is invoked for the 0/N patch, and when complete the entire - # series is sent via email for review - </literallayout> - </para> - </section> - - <section id='export-for-import-into-other-scm'> - <title>Exporting Changes for Import into Another SCM</title> - - <para> - When you want to export changes for import into another - Source Code Manager (SCM) you can use any of the previously discussed - techniques. - However, if the patches are manually applied to a secondary tree and then - that tree is checked into the SCM you can lose change information such as - commit logs. - Yocto Project does not recommend this process. - </para> - - <para> - Many SCMs can directly import git commits, or can translate git patches so that - information is not lost. - Those facilities are SCM-dependent and you should use them whenever possible. - </para> - </section> - </section> - - <section id='scm-working-with-the-yocto-project-kernel-in-another-scm'> - <title>Working with the Yocto Project Kernel in Another SCM</title> - - <para> - This section describes kernel development in another SCM, which is not the same - as exporting changes to another SCM. - For this scenario you use the Yocto Project build system to - develop the kernel in a different SCM. - The following must be true for you to accomplish this: - <itemizedlist> - <listitem><para>The delivered Yocto Project kernel must be exported into the second - SCM.</para></listitem> - <listitem><para>Development must be exported from that secondary SCM into a - format that can be used by the Yocto Project build system.</para></listitem> - </itemizedlist> - </para> - - <section id='exporting-delivered-kernel-to-scm'> - <title>Exporting the Delivered Kernel to the SCM</title> - - <para> - Depending on the SCM it might be possible to export the entire Yocto Project - kernel git repository, branches and all, into a new environment. - This method is preferred because it has the most flexibility and potential to maintain - the meta data associated with each commit. - </para> - - <para> - When a direct import mechanism is not available, it is still possible to - export a branch (or series of branches) and check them into a new repository. - </para> - - <para> - The following commands illustrate some of the steps you could use to - import the yocto/standard/common-pc/base kernel into a secondary SCM: - <literallayout class='monospaced'> - > git checkout yocto/standard/common-pc/base - > cd .. ; echo linux/.git > .cvsignore - > cvs import -m "initial import" linux MY_COMPANY start - </literallayout> - </para> - - <para> - You could now relocate the CVS repository and use it in a centralized manner. - </para> - - <para> - The following commands illustrate how you can condense and merge two BSPs into a second SCM: - <literallayout class='monospaced'> - > git checkout yocto/standard/common-pc/base - > git merge yocto/standard/common-pc-64/base - # resolve any conflicts and commit them - > cd .. ; echo linux/.git > .cvsignore - > cvs import -m "initial import" linux MY_COMPANY start - </literallayout> - </para> - </section> - - <section id='importing-changes-for-build'> - <title>Importing Changes for the Build</title> - - <para> - Once development has reached a suitable point in the second development - environment, you need to export the changes as patches. - To export them place the changes in a recipe and - automatically apply them to the kernel during patching. - </para> -<!--<para> -If changes are imported directly into git, they must be propagated to the -wrll-linux-2.6.27/git/default_kernel bare clone of each individual build -to be present when the kernel is checked out. -</para> -<para> -The following example illustrates one variant of this workflow: -<literallayout class='monospaced'> - # on master git repository - > cd linux-2.6.27 - > git tag -d common_pc-standard-mark - > git pull ssh://<foo>@<bar>/pub/git/kernel-2.6.27 common_pc-standard:common_pc-standard - > git tag common_pc-standard-mark - - # on each build machine (or NFS share, etc) - > cd wrll-linux-2.6.27/git/default_kernel - > git fetch ssh://<foo>@<master server>/pub/git/kernel-2.6.27 - - # in the build, perform a from-scratch build of Linux and the new changes - # will be checked out and built. - > make linux -</literallayout> -</para> --> - </section> - </section> - -<!-- <section id='bsp-template-migration-from-2'> - <title>BSP: Template Migration from 2.0</title> -<para> -The move to a git-backed kernel build system in 3.0 introduced a small new -requirement for any BSP that is not integrated into the GA release of the -product: branching information. -</para> -<para> -As was previously mentioned in the background sections, branching information -is always required, since the kernel build system cannot make intelligent -branching decisions and must rely on the developer. This branching -information is provided via a .scc file. -</para> -<para> -A BSP template in 2.0 contained build system information (config.sh, etc) and -kernel patching information in the 'linux' subdirectory. The same holds true -in 3.0, with only minor changes in the kernel patching directory. -The ".smudge" files are now ".scc" files and now contain a full description - of the kernel branching, patching and configuration for the BSP. Where in - 2.0, they only contained kernel patching information. -</para> -<para> -The following illustrates the migration of a simple 2.0 BSP template to the -new 3.0 kernel build system. -</para> -<note><para> -Note: all operations are from the root of a customer layer. -</para></note> -<literallayout class='monospaced'> - templates/ - `‐‐ board - `‐‐ my_board - |‐‐ config.sh - |‐‐ include - `‐‐ linux - `‐‐ 2.6.x - |‐‐ knl-base.cfg - |‐‐ bsp.patch - `‐‐ my_bsp.smudge - - > mv templates/board/my_board/linux/2.6.x/* templates/board/my_board/linux - > rm -rf templates/board/my_board/linux/2.6.x/ - > mv templates/board/my_board/linux/my_bsp.smudge \ - templates/board/my_board/linux/my_bsp-standard.scc - > echo "kconf hardware knl-base.cfg" >> \ - templates/board/my_board/linux/my_bsp-standard.scc - > vi templates/board/my_board/linux/my_bsp-standard.scc - # add the following at the top of the file - scc_leaf ktypes/standard my_bsp-standard - - templates/ - `‐‐ board - `‐‐ my_board - |‐‐ config.sh - |‐‐ include - `‐‐ linux - |‐‐ knl-base.cfg - |‐‐ bsp.patch - `‐‐ my_bsp-standard.scc -</literallayout> -<para> -That's it. Configure and build. -</para> -<note><para>There is a naming convention for the .scc file, which allows the build - system to locate suitable feature descriptions for a board: -</para></note> -<literallayout class='monospaced'> - <bsp name>-<kernel type>.scc -</literallayout> -<para> - if this naming convention isn't followed your feature description will - not be located and a build error thrown. -</para> - </section> --> - - - - <section id='bsp-creating'> - <title>Creating a BSP Based on an Existing Similar BSP</title> - - <para> - This section provides an example for creating a BSP - that is based on an existing, and hopefully, similar - one. It assumes you will be using a local kernel - repository and will be pointing the kernel recipe at - that. Follow these steps and keep in mind your - particular situation and differences: - - <orderedlist> - <listitem><para> - Identify a machine configuration file that matches your machine. - </para> - - <para> - You can start with something in <filename>meta/conf/machine</filename> - <filename> - meta/conf/machine/atom-pc.conf</filename> for example. Or, you can start with a machine - configuration from any of the BSP layers in the meta-intel repository at - <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/'></ulink>, such as - <filename>meta-intel/meta-emenlow/conf/machine/emenlow.conf</filename>. - </para> - - <para> - The main difference between the two is that "emenlow" is in its own layer. - It is in its own layer because it needs extra machine-specific packages such as its - own video driver and other supporting packages. - The "atom-pc" is simpler and does not need any special packages - everything it needs can - be specified in the configuration file. - The "atom-pc" machine also supports all of Asus eee901, Acer Aspire One, Toshiba NB305, - and the Intel® Embedded Development Board 1-N450 with no changes. - </para> - - <para> - If you want to make minor changes to support a slightly different machine, you can - create a new configuration file for it and add it alongside the others. - You might consider keeping the common information separate and including it. - </para> - - <para> - Similarly, you can also use multiple configuration files for different machines even - if you do it as a separate layer like meta-emenlow. - </para> - - <para> - As an example consider this: - <itemizedlist> - <listitem><para>Copy meta-emenlow to meta-mymachine</para></listitem> - <listitem><para>Fix or remove anything you do not need. - For this example the only thing left was the kernel directory with a - <filename>linux-yocto_git.bbappend</filename> - file - and <filename>meta-mymachine/conf/machine/mymachine.conf</filename> - (linux-yocto is the kernel listed in - <filename>meta-emenlow/conf/machine/emenlow.conf</filename>)</para></listitem>. - <listitem><para>Add a new entry in the <filename>build/conf/bblayers.conf</filename> - so the new layer can be found by BitBake.</para></listitem> - </itemizedlist> - </para></listitem> - - <listitem><para> - Create a machine branch for your machine. - </para> - - <para> - For the kernel to compile successfully, you need to create a branch in the git repository - specifically named for your machine. - To create this branch first create a bare clone of the Yocto Project git repository. - Next, create a local clone of that: - <literallayout class='monospaced'> - $ git clone --bare git://git.yoctoproject.org/linux-yocto-2.6.37.git - linux-yocto-2.6.37.git - $ git clone linux-yocto-2.6.37.git linux-yocto-2.6.37 - </literallayout> - </para> - - <para> - Now create a branch in the local clone and push it to the bare clone: - <literallayout class='monospaced'> - $ git checkout -b yocto/standard/mymachine origin/yocto/standard/base - $ git push origin yocto/standard/mymachine:yocto/standard/mymachine - </literallayout> - </para></listitem> - - <listitem><para> - In a layer, create a <filename>linux-yocto_git.bbappend</filename> - file with the following: - </para> - - <para> - <literallayout class='monospaced'> - FILESEXTRAPATHS := "${THISDIR}/${PN}" - COMPATIBLE_MACHINE_mymachine = "mymachine" - - # It is often nice to have a local clone of the kernel repository, to - # allow patches to be staged, branches created, and so forth. Modify - # KSRC to point to your local clone as appropriate. - - KSRC ?= /path/to/your/bare/clone/for/example/linux-yocto-2.6.37.git - - # KMACHINE is the branch to be built, or alternatively - # KBRANCH can be directly set. - # KBRANCH is set to KMACHINE in the main linux-yocto_git.bb - # KBRANCH ?= "${LINUX_KERNEL_TYPE}/${KMACHINE}" - - KMACHINE_mymachine = "yocto/standard/mymachine" - - SRC_URI = "git://${KSRC};nocheckout=1;branch=${KBRANCH},meta;name=machine,meta" - </literallayout> - </para> - - <para> - After doing that, select the machine in <filename>build/conf/local.conf</filename>: - <literallayout class='monospaced'> - # - MACHINE ?= "mymachine" - # - </literallayout> - </para> - - <para> - You should now be able to build and boot an image with the new kernel: - <literallayout class='monospaced'> - $ bitbake poky-image-sato-live - </literallayout> - </para></listitem> - - <listitem><para> - Modify the kernel configuration for your machine. - </para> - - <para> - Of course, that will give you a kernel with the default configuration file, which is probably - not what you want. - If you just want to set some kernel configuration options, you can do that by - putting them in a file. - For example, inserting the following into some <filename>.cfg</filename> file: - <literallayout class='monospaced'> - CONFIG_NETDEV_1000=y - CONFIG_E1000E=y - </literallayout> - </para> - - <para> - And, another <filename>.cfg</filename> file would contain: - <literallayout class='monospaced'> - CONFIG_LOG_BUF_SHIFT=18 - </literallayout> - - <para> - These config fragments could then be picked up and - applied to the kernel .config by appending them to the kernel SRC_URI: - </para> - - <literallayout class='monospaced'> - SRC_URI_append_mymachine = " file://some.cfg \ - file://other.cfg \ - " - </literallayout> - </para> - - <para> - You could also add these directly to the git repository <filename>meta</filename> - branch as well. - However, the former method is a simple starting point. - </para></listitem> - - <listitem><para> - If you're also adding patches to the kernel, you can do the same thing. - Put your patches in the SRC_URI as well (plus <filename>.cfg</filename> for their kernel - configuration options if needed). - </para> - - <para> - Practically speaking, to generate the patches, you'd go to the source in the build tree: - <literallayout class='monospaced'> - build/tmp/work/mymachine-poky-linux/linux-yocto-2.6.37+git0+d1cd5c80ee97e81e130be8c3de3965b770f320d6_0+ -0431115c9d720fee5bb105f6a7411efb4f851d26-r13/linux - </literallayout> - </para> - - <para> - Then, modify the code there, using quilt to save the changes, and recompile until - it works: - <literallayout class='monospaced'> - $ bitbake -c compile -f linux-yocto - </literallayout> - </para></listitem> - - <listitem><para> - Once you have the final patch from quilt, copy it to the - SRC_URI location. - The patch is applied the next time you do a clean build. - Of course, since you have a branch for the BSP in git, it would be better to put it there instead. - For example, in this case, commit the patch to the "yocto/standard/mymachine" branch, and during the - next build it is applied from there. - </para></listitem> - </orderedlist> - </para> - </section> - - <section id='bsp-creating-bsp-without-a-local-kernel-repo'> - <title>Creating a BSP Based on an Existing Similar BSP Without a Local Kernel Repository</title> - - <para> - If you are creating a BSP based on an existing similar BSP but you do not have - a local kernel repository, the process is very similar to the process in - the previous section (<xref linkend='bsp-creating'/>). - </para> - - <para> - Follow the exact same process as described in the previous section with - these slight modifications: - </para> - <orderedlist> - <listitem><para>Perform Step 1 as is from the previous section.</para></listitem> - <listitem><para>Perform Step 2 as is from the previous section.</para></listitem> - <listitem><para>Perform Step 3 but do not modify the - KSRC line in the bbappend file.</para></listitem> - <listitem><para>Edit the <filename>local.conf</filename> so - that it contains the following: - <literallayout class='monospaced'> - YOCTO_KERNEL_EXTERNAL_BRANCH="<your-machine>-standard - </literallayout></para> - <para>Adding this statement to the file triggers BSP bootstrapping - to occur and the correct branches and base configuration to be used. - </para></listitem> - <listitem><para>Perform Step 4 as is from the previous section.</para></listitem> - <listitem><para>Perform Step 5 as is from the previous section.</para></listitem> - </orderedlist> - </section> - - -<!-- <section id='bsp-creating-a-new-bsp'> - <title>BSP: Creating a New BSP</title> -<para> -Although it is obvious that the structure of a new BSP uses the migrated -directory structure from the previous example,the first question is whether -or not the BSP is started from scratch. -</para> -<para> -If Yocto Project has a similar BSP, it is often easier to clone and update, -rather than start from scratch. If the mainline kernel has support, it is -easier to branch from the -standard kernel and begin development (and not be -concerned with undoing existing changes). This section covers both options. -</para> -<para> -In almost every scenario, the LDAT build system bindings must be completed -before either cloning or starting a new BSP from scratch. This is simply -because the board template files are required to configure a project/build -and create the necessary environment to begin working directly with the -kernel. If it is desired to start immediately with kernel development and -then add LDAT bindings, see the "bootstrapping a BSP" section. -</para> - <section id='creating-from-scratch'> - <title>Creating the BSP from Scratch</title> -<para> -To create the BSP from scratch you need to do the following: -<orderedlist> - <listitem><para>Create a board template for the new BSP in a layer.</para></listitem> - <listitem><para>Configure a build with the board.</para></listitem> - <listitem><para>Configure a kernel.</para></listitem> -</orderedlist> -</para> -<para> -Following is an example showing all three steps. You start by creating a board template for the new BSP in a layer. -<literallayout class='monospaced'> - templates/ - `‐‐ board - `‐‐ my_bsp - |‐‐ include - |‐‐ config.sh - `‐‐ linux - |‐‐ my_bsp.cfg - `‐‐ my_bsp-standard.scc - - > cat config.sh - TARGET_BOARD="my_bsp" - TARGET_LINUX_LINKS="bzImage" - TARGET_SUPPORTED_KERNEL="standard" - TARGET_SUPPORTED_ROOTFS="glibc_std" - BANNER="This BSP is *NOT* supported" - TARGET_PROCFAM="pentium4" - TARGET_PLATFORMS="GPP" - - > cat include - cpu/x86_32_i686 - karch/i386 - - > cat linux/my_bsp-standard.scc - scc_leaf ktypes/standard/standard.scc my_bsp-standard - - > cat linux/my_bsp.cfg - CONFIG_X86=y - CONFIG_SMP=y - CONFIG_VT=y - # etc, etc, etc -</literallayout> -</para> -<para> -Something like the following can now be added to a board build, and -a project can be started: -<literallayout class='monospaced'> - ‐‐enable-board=my_bsp \ - ‐‐with-layer=custom_bsp -</literallayout> -</para> -<para> -Now you can configure a kernel: -<literallayout class='monospaced'> - > make -C build linux.config -</literallayout> -</para> -<para> -You now have a kernel tree, which is branched and has no patches, ready for -development. -</para> - </section> --> - -<!-- <section id='cloning-an-existing-bsp'> - <title>Cloning an Existing BSP</title> -<para> -Cloning an existing BSP from the shipped product is similar to the "from -scratch" option and there are two distinct ways to achieve this goal: -<itemizedlist> - <listitem><para>Create a board template for the new BSP in a layer.</para></listitem> - <listitem><para>Clone the .scc and board config.</para></listitem> -</itemizedlist> -</para> -<para> -The first method is similar to the from scratch BSP where you create a board template for the new -BSP. Although in this case, copying an existing board template from -wrll-wrlinux/templates/board would be appropriate, since we are cloning an -existing BSP. Edit the config.sh, include and other board options for the new -BSP. -</para> -<para> -The second method is to clone the .scc and board config. -To do this, in the newly created board template, create a linux subdirectory and export -the .scc and configuration from the source BSP in the published Yocto Project -kernel. During construction, all of the configuration and patches were -captured, so it is simply a matter of extracting them. -</para> -<para> -Extraction can be accomplished using four different techniques: -<itemizedlist> - <listitem><para>Config and patches from the bare default_kernel.</para></listitem> - <listitem><para>Clone default_kernel and checkout wrs_base.</para></listitem> - <listitem><para>Clone default_kernel and checkout BSP branch.</para></listitem> - <listitem><para>Branch from the Yocto Project BSP.</para></listitem> -</itemizedlist> -</para> -<para> -Technique 1: config and patches from the bare default_kernel -<literallayout class='monospaced'> - > cd layers/wrll-linux-2.6.27/git/default_kernel - > git show checkpoint_end | filterdiff -i '*common_pc*' | patch -s -p2 -d /tmp - - # This will create two directories: cfg and patches. - - > cd /tmp/cfg/kernel-cache/bsp/common_pc/ - - # This directory contains all the patches and .scc files used to construct - # the BSP in the shipped tree. Copy the patches to the new BSP template, - # and add them to the .scc file created above. See "template patching" if - # more details are required. -</literallayout> -</para> -<para> -Technique 2: clone default_kernel and checkout wrs_base -<literallayout class='monospaced'> - > git clone layers/wrll-linux-2.6.27/git/default_kernel windriver-2.6.27 - > cd windriver-2.6.27 - > git checkout wrs_base - > cd wrs/cfg/kernel-cache/bsp/common_pc - -# again, this directory has all the patches and .scc files used to construct -# the BSP -</literallayout> -</para> -<para> -Technique 3: clone default_kernel and checkout BSP branch -<literallayout class='monospaced'> - > git clone layers/wrll-linux-2.6.27/git/default_kernel windriver-2.6.27 - > cd windriver-2.6.27 - > git checkout common_pc-standard - > git whatchanged - # browse patches and determine which ones are of interest, say there are - # 3 patches of interest - > git format-patch -o <path to BSP template>/linux HEAD^^^ - # update the .scc file to add the patches, see "template patches" if - # more details are required -</literallayout> -</para> -<para> -Technique #4: branch from the Yocto Project BSP -<note><para>This is potentially the most "different" technique, but is actually - the easiest to support and leverages the infrastructure. rtcore BSPs - are created in a similar manner to this. -</para></note> -</para> -<para> -In this technique the .scc file in the board template is slightly different - and indicates that the BSP should branch after the base Yocto Project BSP - of the correct kernel type, so to start a new BSP that inherits the - kernel patches of the common_pc-standard, the following would be done: -<literallayout class='monospaced'> - > cat linux/my_bsp-standard.scc - scc_leaf bsp/common_pc/common_pc-standard.scc my_bsp-standard -</literallayout> -</para> -<para> - And only kernel configuration (not patches) need be contained in the - board template. -</para> -<para> - This has the advantage of automatically picking up updates to the BSP - and not duplicating any patches for a similar board. -</para> - </section> --> - - <!-- <section id='bsp-bootstrapping'> - <title>BSP: Bootstrapping</title> -<para> -The previous examples created the board templates and configured a build -before beginning work on a new BSP. It is also possible for advanced users to -simply treat the Yocto Project git repository as an upstream source and begin -BSP development directly on the repository. This is the closest match to how -the kernel community at large would operate. -</para> -<para> -Two techniques exist to accomplish this: -</para> -<para> -Technique 1: upstream workflow -<literallayout class='monospaced'> - > git clone layers/wrll-linux-2.6.27/git/default_kernel windriver-2.6.27 - > cd windriver-2.6.27 - > git checkout -b my_bsp-standard common_pc-standard - - # edit files, import patches, generally do BSP development - - # at this point we can create the BSP template, and export the kernel - # changes using one of the techniques discussed in that section. For - # example, It is possible to push these changes, directly into the - # default_kernel and never directly manipulate or export patch files -</literallayout> -</para> -<para> -Technique 2: Yocto Project kernel build workflow -</para> -<para> - Create the BSP branch from the appropriate kernel type -<literallayout class='monospaced'> - > cd linux - # the naming convention for auto-build is <bsp>-<kernel type> - > git checkout -b my_bsp-standard standard -</literallayout> -</para> -<para> -Make changes, import patches, etc. -<literallayout class='monospaced'> - > ../../host-cross/bin/guilt init - # 'wrs/patches/my_bsp-standard' has now been created to - # manage the branches patches - - # option 1: edit files, guilt import - > ../../host-cross/bin/guilt new extra-version.patch - > vi Makefile - > ../../host-cross/bin/guilt refresh - # add a header - > ../../host-cross/bin/guilt header -e - # describe the patch using best practices, like the example below: - - ‐‐‐>‐‐‐>‐‐‐> cut here - From: Bruce Ashfield <bruce.ashfield@windriver.com> - - Adds an extra version to the kernel - - Modify the main EXTRAVERSION to show our bsp name - - Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> - ‐‐‐>‐‐‐>‐‐‐> cut here - - # option 2: import patches - > git am <patch> - or - > git apply <patch> - > git add <files> - > git commit -s - - # configure the board, save relevant options - > make ARCH=<arch> menuconfig - - # save the cfg changes for reconfiguration - > mkdir wrs/cfg/<cache>/my_bsp - > vi wrs/cfg/<cache>/my_bsp/my_bsp.cfg - - # classify the patches - > ../../host-cross/bin/kgit classify create <kernel-foo-cache>/my_bsp/my_bsp - # test build - > cd .. - > make linux TARGET_BOARD=my_bsp kprofile=my_bsp use_current_branch=1 -</literallayout> -</para> -<para> - Assuming the patches have been exported to the correct location, Future - builds will now find the board, apply the patches to the base tree and make - the relevant branches and structures and the special build options are no - longer required. -</para> - </section> - </section> --> - -<!-- <section id='patching'> - <title>Patching</title> -<para> -The most common way to apply patches to the kernel is via a template. -However, for more advanced applications (such as the sharing of patches between -multiple sub-features) it is possible to patch the kernel-cache. -This section covers both scenarios. -</para> - <section id='patching-template'> - <title>Patching: Template</title> -<para> -kernel -templates follow the same rules as any LDAT template. A directory should be -created in a recognized template location, with a 'linux' subdirectory. The -'linux' directory triggers LDAT to pass the dir as a potential patch location -to the kernel build system. Any .scc files found in that directory, will be -automatically appended to the end of the BSP branch (for the configured -board). -</para> -<para> -This behavior is essentially the same since previous product -releases. The only exception is the use of ".scc", which allows kernel -configuration AND patches to be applied in a template. -</para> -<note><para> -If creating a full template is not required, a .scc file can be placed at -the top of the build, along with configuration and patches. The build -system will pickup the .scc and add it onto the patch list automatically -</para></note> -<para> -As an example, consider a simple template to update a BP: -<literallayout class='monospaced'> - > cat templates/feature/extra_version/linux/extra_version.scc - patch 0001-extraversion-add-Wind-River-identifier.patch -</literallayout> -</para> -<para> -To illustrate how the previous template patch was created, the following -steps were performed: -<literallayout class='monospaced'> - > cd <board build>/build/linux - > vi Makefile - # modify EXTRAVERSION to have a unique string - > git commit -s -m "extraversion: add Yocto Project identifier" Makefile - > git format-patch -o <path to layer>/templates/feature/extra_version/linux/ - > echo "patch 0001-extraversion-add-Wind-River-identifier.patch" > \ - <path to layer>/templates/feature/extra_version/linux/extra_version.scc -</literallayout> -</para> -<para> -This next example creates a template with a linux subdirectory, just as we - always have for previous releases. -<literallayout class='monospaced'> - > mkdir templates/features/my_feature/linux -</literallayout> -</para> -<para> - In that directory place your feature description, your - patch and configuration (if required). -<literallayout class='monospaced'> - > ls templates/features/my_feature/linux - - version.patch - my_feature.scc - my_feature.cfg -</literallayout> -</para> -<para> - The .scc file describes the patches, configuration and - where in the patch order the feature should be inserted. -<literallayout class='monospaced'> - patch version.patch - kconf non-hardware my_feature.cfg -</literallayout> -</para> -<para> - Configure your build with the new template -<literallayout class='monospaced'> - ‐‐with-template=features/my_feature -</literallayout> -</para> -<para> -Build the kernel -<literallayout class='monospaced'> - > make linux -</literallayout> -</para> - </section> - - <section id='patching-kernel-cache'> - <title>Patching: Kernel Cache</title> -<para> -As previously mentioned, this example is included for completeness, and is for more advanced -applications (such as the sharing of patches between multiple sub-features). -Most patching should be done via templates, since that interface is -guaranteed not to change and the kernel-cache interface carries no such -guarantee. -</para> -<para> -At the top of a layer, create a kernel cache. The build system will recognize -any directory of the name 'kernel-*-cache' as a kernel cache. -<literallayout class='monospaced'> - > cd <my layer> - >mkdir kernel-temp-cache -</literallayout> -</para> -<para> -Make a directory with the BSP -<literallayout class='monospaced'> - > mkdir kernel-temp-cache - > mkdir kernel-temp-cache/my_feat -</literallayout> -</para> -<para> -Create the feature files as they were in technique #1 -<literallayout class='monospaced'> - > echo "patch my_patch.path" > kernel-temp-cache/my_feat/my_feature.scc -</literallayout> -</para> -<para> -Configure the build with the feature added to the kernel type -<literallayout class='monospaced'> - ‐‐with-kernel=standard+my_feat/my_feature.scc -</literallayout> -</para> -<para> -Build the kernel -<literallayout class='monospaced'> - > make linux -</literallayout> -</para> - </section> - </section> - - <section id='bsp-updating-patches-and-configuration'> - <title>BSP: Updating Patches and Configuration</title> -<para> -As was described in the "template patching" example, it is simple -to add patches to a BSP via a template, but often, it is desirable -to experiment and test patches before committing them to a template. -You can do this by modifying the BSP source. -</para> -<para> -Start as follows: -<literallayout class='monospaced'> - > cd linux - > git checkout <bspname>-<kernel name> - - > git am <patch> -</literallayout> -</para> -<para> -Or you can do this: -<literallayout class='monospaced'> - > kgit-import -t patch <patch> - - > cd .. - > make linux -</literallayout> -</para> -<para> -For details on conflict resolution and patch application, see the -git manual, or other suitable online references. -<literallayout class='monospaced'> - > git am <mbox> - # conflict - > git apply ‐‐reject .git/rebase-apply/0001 - # resolve conflict - > git am ‐‐resolved (or git am ‐‐skip, git am ‐‐abort) - # continue until complete -</literallayout> -</para> -<para> -Here is another example: -<literallayout class='monospaced'> - # merge the patches - # 1) single patch - > git am <mbox> - > git apply <patch< - > kgit import -t patch <patch> - - # 2) multiple patches - > git am <mbox> - > kgit import -t dir <dir> - - # if kgit -t dir is used, a patch resolution cycle such - # as this can be used: - - > kgit import -t dir <dir> - # locate rejects and resolve - # options: - > wiggle ‐‐replace <path to file> <path to reject> - > guilt refresh - or - > # manual resolution - > git add <files> - > git commit -s - or - > git apply ‐‐reject .git/rebase-apply/0001 - > git add <files> - > git am ‐‐resolved - or - > # merge tool of choice - - # continue series: - - > kgit import -t dir <dir> - or - > git am ‐‐continue -</literallayout> -</para> -<para> -Once all the patches have been tested and are satisfactory, they -should be exported via the techniques described in "saving kernel -modifications." -</para> -<para> -Once the kernel has been patched and configured for a BSP, it's -configuration commonly needs to be modified. This can be done by -running [menu|x]config on the kernel tree, or working with -configuration fragments. -</para> -<para> -Using menuconfig, the operation is as follows: -<literallayout class='monospaced'> - > make linux.menuconfig - > make linux.rebuild -</literallayout> -</para> -<para> -Once complete, the changes are in linux-<bsp>-<kernel type>-build/.config. -To permanently save these changes, compare the .config before and after the -menuconfig, and place those changes in a configuration fragment in the -template of your choice. -</para> -<para> -Using configuration fragments, the operation is as follows (using the -si_is8620 as an example BSP): -<literallayout class='monospaced'> - > vi linux/wrs/cfg/kernel-cache/bsp/si_is8620/si_is8620.cfg - > make linux.reconfig - > make linux.rebuild -</literallayout> -</para> -<para> -The modified configuration fragment can simply be copied out of the -linux/wrs/.. directory and placed in the appropriate template for future -application. -</para> - </section> - - <section id='tools-guilt'> - <title>Tools: guilt</title> -<para> -Yocto Project has guilt integrated as a kernel tool; therefore users that are -familiar with quilt may wish to use this tool to pop, push and refresh -their patches. Note: guilt should only be used for local operations, once -a set of changes has been pushed or pulled, they should no longer be popped -or refresh by guilt, since popping, refreshing and re-pushing patches -changes their commit IDs and creating non-fast forward branches. -</para> -<para> -The following example illustrates how to add patches a Yocto Project -BSP branch via guilt: -<literallayout class='monospaced'> - > cd build/linux - > git checkout common_pc-standard - > guilt new extra.patch - # edit files, make changes, etc - > guilt refresh - > guilt top - extra.patch - - # export that patch to an external location - > kgit export -p top /tmp -</literallayout> -</para> -<para> -Other guilt operations of interest are: -<literallayout class='monospaced'> - > guilt push, guilt push -a - > guilt pop - > guilt applied, guilt unapplied - > guilt top - > guilt refresh - > guilt header -e - > guilt next -</literallayout> -</para> -<note><para> -Guilt only uses git commands and git plumbing to perform its operations, -anything that guilt does can also be done using git directly. It is provided -as a convenience utility, but is not required and the developer can use whatever -tools or workflow they wish. -</para></note> -<para> -The following builds from the above instructions to show how guilt can be -used to assist in getting your BSP kernel patches ready. You should follow -the above instructions up to and including 'make linux.config'. In this -example I will create a new commit (patch) from scratch and import another -fictitious patch from some external public git tree (ie, a commit with full -message, signoff etc.). Please ensure you have host-cross/bin in your path. -<literallayout class='monospaced'> - %> cd linux - %> guilt-init - %> guilt-new -m fill_me_in_please first_one.patch - %> touch somefile.txt - %> guilt-add somefile.txt - %> guilt-header -e - %> guilt-refresh - %> guilt-import path_to_some_patch/patch_filename - %> guilt-push -</literallayout> -</para> -<para> -Here are a few notes about the above: -<itemizedlist> - <listitem><para>guilt-header -e ‐‐ this will open editing of the patch header in - EDITOR. As with a git commit the first line is the short log and - should be just that short and concise message about the commit. Follow - the short log with lines of text that will be the long description but - note Do not put a blank line after the short log. As usual you will - want to follow this with a blank line and then a signoff line.</para></listitem> - - <listitem><para>The last line in the example above has 2 dots on the end. If you - don't add the 2 periods on the end guilt will think you are sending - just one patch. The wrong one!</para></listitem> - - <listitem><para>The advantage to using guilt over not using guilt is that if you have a - review comment in the first patch (first_one.patch in the case of this - example) it is very easy to use guilt to pop the other patches off - allowing you to make the necessary changes without having to use more - inventive git type strategies.</para></listitem> -</itemizedlist> -</para> - </section> - - <section id='tools-scc-file-example'> - <title>Tools: scc File Example</title> -<para> -This section provides some scc file examples: leaf node, 'normal' mode, and transforms. -</para> - <section id='leaf-node'> - <title>Leaf Node</title> -<para> -The following example is a BSP branch with no child branches - a leaf on the tree. -<literallayout class='monospaced'> - # these are optional, but allow standalone tree construction - define WRS_BOARD <name> - define WRS_KERNEL <kern type> - define WRS_ARCH <arch> - - scc_leaf ktypes/standard common_pc-standard - # ^ ^ - # +‐‐ parent + branch name - - include common_pc.scc - # ^ - # +‐‐‐ include another feature -</literallayout> -</para> - </section> - - <section id='normal-mode'> - <title>'Normal' Mode</title> -<para> -Here is an example of 'normal' mode: -<literallayout class='monospaced'> - # +‐‐‐‐ name of file to read - # v - kconf hardware common_pc.cfg - # ^ ^ - # | +‐‐ 'type: hardware or non-hardware - # | - # +‐‐‐ kernel config - - # patches - patch 0002-atl2-add-atl2-driver.patch - patch 0003-net-remove-LLTX-in-atl2-driver.patch - patch 0004-net-add-net-poll-support-for-atl2-driver.patch -</literallayout> -</para> - - </section> - - <section id='transforms'> - <title>Transforms</title> -<para> -This section shows an example of transforms: -<literallayout class='monospaced'> - # either of the next two options will trigger an 'auto' - # branch from existing ones, since they change the commit - # order and hence must construct their own branch - - # this changes the order of future includes, if the - # passed feature is detected, the first feature is - # included AFTER it - include features/rt/rt.scc after features/kgdb/kgdb - # this also changes the order of existing branches - # this prevents the named feature from ever being - # included - exclude features/dynamic_ftrace/dynamic_ftrace.scc - - # inherit the standard kernel - include ktypes/standard/standard - - - # LTT supplies this, so we don't want the sub-chunk from RT. - patch_trigger arch:all exclude ftrace-upstream-tracepoints.patch - # ...but we still want the one unique tracepoint it added. - patch tracepoint-add-for-sched_resched_task.patch - - # these will change the named patches in the series into - # <patch name>.patch.<feature name> - # where the substituted patch is in this directory - patch_trigger arch:all ctx_mod dynamic_printk.patch - patch_trigger arch:all ctx_mod 0001-Implement-futex-macros-for-ARM.patch - # unconditionally exclude a patch - patch_trigger arch:all exclude ftrace-fix-ARM-crash.patch -</literallayout> -</para> - </section> - </section> --> - - <section id='tip-dirty-string'> - <title>"-dirty" String</title> - - <para> - If kernel images are being built with "-dirty" on the end of the version - string, this simply means that modifications in the source - directory have not been committed. - <literallayout class='monospaced'> - > git status - </literallayout> - </para> - - <para> - You can use the git command above to report modified, removed, or added files. - You should commit those changes to the tree regardless of whether they will be saved, - exported, or used. - Once you commit the changes you need to rebuild the kernel. - </para> - - <para> - To brute force pickup and commit all such pending changes enter the following: - <literallayout class='monospaced'> - > git add . - > git commit -s -a -m "getting rid of -dirty" - </literallayout> - </para> - - <para> - Next, rebuild the kernel. - </para> - </section> - -<!-- <section id='kernel-transition-kernel-layer'> - <title>Creating a Transition Kernel Layer</title> - - <para> - You can temporarily use a different base kernel in Yocto Project by doing the following: - - <orderedlist> - <listitem><para>Create a custom kernel layer.</para></listitem> - <listitem><para>Create a git repository of the transition kernel.</para></listitem> - </orderedlist> - </para> - - <para> - Once you meet those requirements you can build multiple boards and kernels. - You pay the setup cost only once. - You can then add additional BSPs and options. - </para> - - <para> - Once you have the transition kernel layer in place you can evaluate - another kernel's functionality with the goal of easing transition to an integrated and validated - Yocto Project kernel. - </para> --> - -<!--<para> -The next few sections describe the process: -</para> --> - <!-- <section id='creating-a-custom-kernel-layer'> - <title>Creating a Custom Kernel Layer</title> -<para> -The custom kernel layer must have the following minimum -elements: -<itemizedlist> - <listitem><para>An include of the shipped Yocto Project kernel layer.</para></listitem> - <listitem><para>A kernel-cache with an override of the standard kernel type.</para></listitem> -</itemizedlist> -</para> -<para> -This allows the inheritance of the kernel build infrastructure, -while overriding the list of patches that should be applied to -the base kernel. -</para> -<para> -The kernel layer can optionally include an override to the base -Yocto Project Linux BSP to inhibit the application of BSP specific -patches. If a custom BSP is being used, this is not required. -</para> - </section> --> - - <!-- <section id='git-repo-of-the-transition-kernel'> - <title>git Repo of the Transition Kernel</title> -<para> -The kernel build system requires a base kernel repository to -seed the build process. This repository must be found in the -same layer as the build infrastructure (i.e wrll-linux-2.6.27) -in the 'git' subdir, with the name 'default_kernel' -</para> -<para>Since Yocto Project Linux ships with a default_kernel -(the validated Yocto Project kernel) in the wrll-linux-2.6.27 -kernel layer, that must be removed and replaced with the -transition kernel. -</para> -<para>If the Yocto Project install cannot be directly modified -with the new default kernel, then the path to the transition -kernel layer's 'git' subdir must be passed to the build -process via: -<programlisting> -linux_GIT_BASE=<absolute path to layer>/git -</programlisting> -</para> -<para> -If the transition kernel has not been delivered via git, -then a git repo should be created, and bare cloned into -place. Creating this repository is as simple as: -<literallayout class='monospaced'> - > tar zxvf temp_kernel.tgz - > cd temp_kernel - > git init - > git add . - > git commit -a -m "Transition kernel baseline" - - 'temp_kernel' can now be cloned into place via: - - > cd <path to git base>/git - > git clone ‐‐bare <path to temp_kernel/temp_kernel default_kernel -</literallayout> -</para> - </section> --> - - <!-- <section id='building-the-kernel'> - <title>Building the Kernel</title> -<para> -Once these prerequisites have been met, the kernel can be -built with: -<literallayout class='monospaced'> - > make linux -</literallayout> -</para> -<para> -The new base kernel will be cloned into place and have any patches -indicated in the transition kernel's cache (or templates) applied. -The kernel build will detect the non-Yocto Project base repo and -use the HEAD of the tree for the build. -</para> - </section> --> - - <!-- <section id='example'> - <title>Example</title> -<para> -This example creates a kernel layer to build the latest -kernel.org tree as the 'common_pc' BSP. -<literallayout class='monospaced'> - > cd <path to layers> - > mkdir wrll-linux-my_version - > cd wrll-linux-my_version - > echo "wrll-linux-2.6.27" > include - > mkdir -p kernel-cache/ktypes/standard - > mkdir -p kernel-cache/bsp/common_pc - > echo "v2.6.29" > kernel-cache/kver - > echo "branch common_pc-standard" > kernel-cache/bsp/common_pc/common_pc.scc - > echo "kconf hardware common_pc.cfg" >> kernel-cache/bsp/common_pc/common_pc.scc - > echo "CONFIG_FOO=y" > kernel-cache/bsp/common_pc/common_pc.cfg - > mkdir git - > cd git - > git clone ‐‐bare git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git default_kernel -</literallayout> -</para> -<para> -Configure a build to use the new layer. This means that: -<literallayout class='monospaced'> - ‐‐enable-kernel-version=my_version -</literallayout> -</para> -<para> -Should be used to override the shipped default. -</para> -<para> -To build the kernel: -<literallayout class='monospaced'> - > cd build - > make linux_GIT_BASE=<layer path>/wrll-linux-my_version/git linux -</literallayout> -</para> -<para> -If this is to build without some user intervention (passing of the -GIT_BASE), you must do the clone into the wrll-linux-2.6.27/git directory. -</para> -<note><para>Unless you define valid "hardware.kcf" and "non-hardware.kcf" some -non fatal warnings will be seen. They can be fixed by populating these -files in the kernel-cache with valid hardware and non hardware config -options. -</para></note> - </section> --> -<!-- </section> --> - </section> - - - - - -<!-- <itemizedlist> - <listitem><para>Introduction to this section.</para></listitem> - <listitem><para>Constructing a project-specific kernel tree.</para></listitem> - <listitem><para>Building the kernel.</para></listitem> - <listitem><para>Seeing what has changed.</para></listitem> - <listitem><para>Seeing what has changed in a particular branch.</para></listitem> - <listitem><para>Modifying the kernel.</para></listitem> - <listitem><para>Saving modifications.</para></listitem> - <listitem><para>Storing patches outside of the kernel source repository (bulk export).</para></listitem> - <listitem><para>Working with incremental changes.</para></listitem> - <listitem><para>Extracting commited changes from a working directory (exporting internally through - patches.</para></listitem> - <listitem><para>Pushing commited changes.</para></listitem> - <listitem><para>Exporting for external (upstream) submission.</para></listitem> - <listitem><para>Exporting for import into another Source Control Manager (SCM).</para></listitem> - <listitem><para>Working with the Yocto Project kernel in another SCM.</para> - <itemizedlist> - <listitem><para>Exporting the delivered kernel to an SCM.</para></listitem> - <listitem><para>Importing changed for the build.</para></listitem> - </itemizedlist></listitem> - <listitem><para>Migrating templates from version 2.0.</para></listitem> - <listitem><para>Creating a new Board Support Package (BSP).</para> - <itemizedlist> - <listitem><para>Creating from scratch.</para></listitem> - <listitem><para>Cloning.</para></listitem> - </itemizedlist></listitem> - <listitem><para>BSP bootstrapping.</para></listitem> - <listitem><para>Applying patches to the kernel through a template.</para></listitem> - <listitem><para>Applying patches to the kernel without using a template.</para></listitem> - <listitem><para>Updating patches and configurations for a BSP.</para></listitem> - <listitem><para>Using guilt to add and export patches.</para></listitem> - <listitem><para>Using scc.</para></listitem> - <listitem><para>Building a 'dirty' image.</para></listitem> - <listitem><para>Temporarily using a different base kernel.</para></listitem> - <listitem><para>Creating a custom kernel layer.</para></listitem> - <listitem><para>Creating the git repository of the transition kernel.</para></listitem> - </itemizedlist> --> - - -</chapter> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/kernel-manual/kernel-manual.xml b/documentation/kernel-manual/kernel-manual.xml deleted file mode 100644 index 875cbe314e..0000000000 --- a/documentation/kernel-manual/kernel-manual.xml +++ /dev/null @@ -1,72 +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='kernel-manual' lang='en' - xmlns:xi="http://www.w3.org/2003/XInclude" - xmlns="http://docbook.org/ns/docbook" - > - <bookinfo> - - <mediaobject> - <imageobject> - <imagedata fileref='figures/kernel-title.png' - format='SVG' - align='left' scalefit='1' width='100%'/> - </imageobject> - </mediaobject> - - <title></title> - - <authorgroup> - <author> - <firstname>Bruce</firstname> <surname>Ashfield</surname> - <affiliation> - <orgname>Wind River Corporation</orgname> - </affiliation> - <email>bruce.ashfield@windriver.com</email> - </author> - </authorgroup> - - <revhistory> - <revision> - <revnumber>0.9</revnumber> - <date>24 November 2010</date> - <revremark>This revision is the initial document draft and corresponds with - the Yocto Project 0.9 Release.</revremark> - </revision> - <revision> - <revnumber>1.0</revnumber> - <date>6 April 2011</date> - <revremark>This revision corresponds with the Yocto Project 1.0 Release.</revremark> - </revision> - </revhistory> - - <copyright> - <year>2010-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="kernel-doc-intro.xml"/> - - <xi:include href="kernel-concepts.xml"/> - - <xi:include href="kernel-how-to.xml"/> - -<!-- <index id='index'> - <title>Index</title> - </index> ---> - -</book> -<!-- -vim: expandtab tw=80 ts=4 ---> diff --git a/documentation/kernel-manual/style.css b/documentation/kernel-manual/style.css deleted file mode 100644 index 33a01d125a..0000000000 --- a/documentation/kernel-manual/style.css +++ /dev/null @@ -1,968 +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/kernel-title.png"); - background-position: left top; - margin-top: -256px; - padding-right: 50px; - margin-left: 0px; - text-align: right; - width: 740px; -} - -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{ -} - -/* -Example of how to stick an image as part of the title. - -div.article .titlepage .title -{ - background-image: url("figures/white-on-black.png"); - background-position: center; - background-repeat: repeat-x; -} -*/ - -div.preface .titlepage .title, -div.colophon .title, -div.chapter .titlepage .title, -div.article .titlepage .title -{ -} - -div.section div.section .titlepage .title, -div.sect2 .titlepage .title { - background: none; -} - - -h1.title { - background-color: transparent; - background-image: url("figures/yocto-project-bw.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/kernel-manual/yocto-project-kernel-manual-customization.xsl b/documentation/kernel-manual/yocto-project-kernel-manual-customization.xsl deleted file mode 100644 index 8eb69050ba..0000000000 --- a/documentation/kernel-manual/yocto-project-kernel-manual-customization.xsl +++ /dev/null @@ -1,8 +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:param name="generate.toc" select="'article nop'"></xsl:param> --> - -</xsl:stylesheet> diff --git a/documentation/poky-ref-manual/Makefile b/documentation/poky-ref-manual/Makefile deleted file mode 100644 index 2ed7cd423f..0000000000 --- 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 ee0db977cc..0000000000 --- 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 45df028f86..0000000000 --- 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 5c5332f731..0000000000 --- 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 fc7169b7b8..0000000000 --- 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 d815b1ed73..0000000000 --- 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 2710189b2a..0000000000 --- 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 b21dc653af..0000000000 --- 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 5bf22e547a..0000000000 --- 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 f4b5ae0fd1..0000000000 --- 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 561333b146..0000000000 --- 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 333442e0d6..0000000000 --- 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 31d2b147fd..0000000000 --- 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 90eaf014c0..0000000000 --- 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 9f9e6cf996..0000000000 --- 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 d0be402870..0000000000 --- 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 362ebed131..0000000000 --- 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 874d9a1c72..0000000000 --- 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 75b3bf5e54..0000000000 --- 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 8eb94c268b..0000000000 --- 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 cde9588116..0000000000 --- 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 03cc624504..0000000000 --- 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 4cfd08fae6..0000000000 --- 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 2e3dbb6686..0000000000 --- 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 87ef0833d7..0000000000 --- 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 dd4b58db53..0000000000 --- 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 4e92012af5..0000000000 --- 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 2c9bfb3bbd..0000000000 --- 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 fa7d1dfa4f..0000000000 --- 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 5a05709245..0000000000 --- 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 138d485f5b..0000000000 --- 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 fc4fbdc6ce..0000000000 --- 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 81f801d0e7..0000000000 --- a/documentation/poky-ref-manual/white-on-black-yp.png +++ /dev/null diff --git a/documentation/template/Vera.ttf b/documentation/template/Vera.ttf Binary files differdeleted file mode 100644 index 58cd6b5e61..0000000000 --- a/documentation/template/Vera.ttf +++ /dev/null diff --git a/documentation/template/Vera.xml b/documentation/template/Vera.xml deleted file mode 100644 index 3c82043e35..0000000000 --- a/documentation/template/Vera.xml +++ /dev/null @@ -1 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?><font-metrics type="TYPE0"><font-name>BitstreamVeraSans</font-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>928</ascender><descender>-235</descender><bbox><left>-183</left><bottom>-235</bottom><right>1287</right><top>928</top></bbox><flags>32</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="600"/><wx w="0"/><wx w="317"/><wx w="317"/><wx w="400"/><wx w="459"/><wx w="837"/><wx w="636"/><wx w="950"/><wx w="779"/><wx w="274"/><wx w="390"/><wx w="390"/><wx w="500"/><wx w="837"/><wx w="317"/><wx w="360"/><wx w="317"/><wx w="336"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="636"/><wx w="336"/><wx w="336"/><wx w="837"/><wx w="837"/><wx w="837"/><wx w="530"/><wx w="1000"/><wx w="684"/><wx w="686"/><wx w="698"/><wx w="770"/><wx w="631"/><wx w="575"/><wx w="774"/><wx w="751"/><wx w="294"/><wx w="294"/><wx w="655"/><wx w="557"/><wx w="862"/><wx w="748"/><wx w="787"/><wx w="603"/><wx w="787"/><wx w="694"/><wx w="634"/><wx w="610"/><wx w="731"/><wx w="684"/><wx w="988"/><wx w="685"/><wx w="610"/><wx w="685"/><wx w="390"/><wx w="336"/><wx w="390"/><wx w="837"/><wx w="500"/><wx w="500"/><wx w="612"/><wx w="634"/><wx w="549"/><wx w="634"/><wx w="615"/><wx w="352"/><wx w="634"/><wx w="633"/><wx w="277"/><wx w="277"/><wx w="579"/><wx w="277"/><wx w="974"/><wx w="633"/><wx w="611"/><wx w="634"/><wx w="634"/><wx w="411"/><wx w="520"/><wx w="392"/><wx w="633"/><wx w="591"/><wx w="817"/><wx w="591"/><wx w="591"/><wx w="524"/><wx w="636"/><wx w="336"/><wx w="636"/><wx w="837"/><wx w="684"/><wx w="684"/><wx w="698"/><wx w="631"/><wx w="748"/><wx w="787"/><wx w="731"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="612"/><wx w="549"/><wx w="615"/><wx w="615"/><wx w="615"/><wx w="615"/><wx w="277"/><wx w="277"/><wx w="277"/><wx w="277"/><wx w="633"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="611"/><wx w="633"/><wx w="633"/><wx w="633"/><wx w="633"/><wx w="500"/><wx w="500"/><wx w="636"/><wx w="636"/><wx w="500"/><wx w="589"/><wx w="636"/><wx w="629"/><wx w="1000"/><wx w="1000"/><wx w="1000"/><wx w="500"/><wx w="500"/><wx w="837"/><wx w="974"/><wx w="787"/><wx w="833"/><wx w="837"/><wx w="837"/><wx w="837"/><wx w="636"/><wx w="636"/><wx w="517"/><wx w="673"/><wx w="756"/><wx w="588"/><wx w="520"/><wx w="471"/><wx w="471"/><wx w="764"/><wx w="981"/><wx w="611"/><wx w="530"/><wx w="400"/><wx w="837"/><wx w="637"/><wx w="636"/><wx w="837"/><wx w="668"/><wx w="611"/><wx w="611"/><wx w="1000"/><wx w="636"/><wx w="684"/><wx w="684"/><wx w="787"/><wx w="1069"/><wx w="1022"/><wx w="500"/><wx w="1000"/><wx w="518"/><wx w="518"/><wx w="317"/><wx w="317"/><wx w="837"/><wx w="494"/><wx w="591"/><wx w="610"/><wx w="166"/><wx w="636"/><wx w="399"/><wx w="399"/><wx w="629"/><wx w="629"/><wx w="500"/><wx w="317"/><wx w="317"/><wx w="518"/><wx w="1341"/><wx w="684"/><wx w="631"/><wx w="684"/><wx w="631"/><wx w="631"/><wx w="294"/><wx w="294"/><wx w="294"/><wx w="294"/><wx w="787"/><wx w="787"/><wx w="787"/><wx w="731"/><wx w="731"/><wx w="731"/><wx w="277"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="562"/><wx w="284"/><wx w="634"/><wx w="520"/><wx w="685"/><wx w="524"/><wx w="336"/><wx w="774"/><wx w="611"/><wx w="610"/><wx w="591"/><wx w="604"/><wx w="634"/><wx w="837"/><wx w="837"/><wx w="400"/><wx w="400"/><wx w="400"/><wx w="969"/><wx w="969"/><wx w="969"/><wx w="774"/><wx w="634"/><wx w="294"/><wx w="634"/><wx w="520"/><wx w="698"/><wx w="549"/><wx w="698"/><wx w="549"/><wx w="634"/><wx w="360"/><wx w="317"/><wx w="636"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="500"/><wx w="400"/><wx w="500"/><wx w="500"/></cid-widths></multibyte-extras><kerning kpx1="246"><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="169"/><pair kern="-26" kpx2="197"/><pair kern="-35" kpx2="55"/><pair kern="-49" kpx2="60"/><pair kern="-49" kpx2="187"/><pair kern="-21" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-49" kpx2="234"/></kerning><kerning kpx1="235"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="43"><pair kern="-35" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-35" kpx2="197"/><pair kern="-30" kpx2="181"/></kerning><kerning kpx1="16"><pair kern="36" kpx2="246"/><pair kern="-17" kpx2="235"/><pair kern="-21" kpx2="199"/><pair kern="18" kpx2="123"/><pair kern="27" kpx2="208"/><pair kern="-118" kpx2="187"/><pair kern="-49" kpx2="59"/><pair kern="18" kpx2="124"/><pair kern="-21" kpx2="201"/><pair kern="-118" kpx2="60"/><pair kern="36" kpx2="52"/><pair kern="18" kpx2="125"/><pair kern="36" kpx2="42"/><pair kern="-118" kpx2="234"/><pair kern="18" kpx2="122"/><pair kern="27" kpx2="210"/><pair kern="-21" kpx2="36"/><pair kern="18" kpx2="82"/><pair kern="-40" kpx2="58"/><pair kern="-91" kpx2="55"/><pair kern="-17" kpx2="186"/><pair kern="27" kpx2="175"/><pair kern="27" kpx2="50"/><pair kern="27" kpx2="209"/><pair kern="27" kpx2="103"/><pair kern="-21" kpx2="98"/><pair kern="55" kpx2="45"/><pair kern="-21" kpx2="173"/><pair kern="-17" kpx2="92"/><pair kern="-26" kpx2="89"/><pair kern="18" kpx2="121"/><pair kern="-58" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-21" kpx2="174"/></kerning><kerning kpx1="112"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="123"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="251"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="213"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="208"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="187"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="113"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="144"><pair kern="-40" kpx2="180"/><pair kern="-54" kpx2="197"/><pair kern="-44" kpx2="181"/></kerning><kerning kpx1="59"><pair kern="-72" kpx2="100"/><pair kern="-63" kpx2="210"/><pair kern="-17" kpx2="55"/><pair kern="-44" kpx2="114"/><pair kern="-44" kpx2="72"/><pair kern="-63" kpx2="175"/><pair kern="-49" kpx2="16"/><pair kern="-63" kpx2="50"/><pair kern="-63" kpx2="209"/><pair kern="-44" kpx2="112"/><pair kern="-72" kpx2="251"/><pair kern="-63" kpx2="103"/><pair kern="-63" kpx2="208"/><pair kern="-44" kpx2="113"/><pair kern="-40" kpx2="181"/><pair kern="-77" kpx2="180"/><pair kern="-54" kpx2="169"/><pair kern="-21" kpx2="197"/><pair kern="-72" kpx2="38"/><pair kern="-72" kpx2="253"/><pair kern="-44" kpx2="115"/></kerning><kerning kpx1="73"><pair kern="31" kpx2="180"/><pair kern="-17" kpx2="90"/><pair kern="-72" kpx2="17"/><pair kern="-17" kpx2="235"/><pair kern="-35" kpx2="169"/><pair kern="-114" kpx2="197"/><pair kern="-17" kpx2="186"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="87"/><pair kern="-54" kpx2="16"/><pair kern="-35" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="41"><pair kern="-17" kpx2="227"/><pair kern="-54" kpx2="126"/><pair kern="-91" kpx2="107"/><pair kern="-91" kpx2="235"/><pair kern="-54" kpx2="72"/><pair kern="-91" kpx2="199"/><pair kern="-35" kpx2="123"/><pair kern="-54" kpx2="112"/><pair kern="-54" kpx2="113"/><pair kern="-17" kpx2="54"/><pair kern="-21" kpx2="180"/><pair kern="-91" kpx2="105"/><pair kern="-54" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-91" kpx2="201"/><pair kern="-72" kpx2="85"/><pair kern="-91" kpx2="106"/><pair kern="-77" kpx2="29"/><pair kern="-35" kpx2="125"/><pair kern="-54" kpx2="115"/><pair kern="-54" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-91" kpx2="68"/><pair kern="-91" kpx2="36"/><pair kern="-35" kpx2="82"/><pair kern="-91" kpx2="186"/><pair kern="-17" kpx2="55"/><pair kern="-54" kpx2="114"/><pair kern="-54" kpx2="127"/><pair kern="-91" kpx2="108"/><pair kern="-91" kpx2="98"/><pair kern="-72" kpx2="76"/><pair kern="-160" kpx2="17"/><pair kern="-54" kpx2="128"/><pair kern="-91" kpx2="173"/><pair kern="-91" kpx2="109"/><pair kern="-183" kpx2="197"/><pair kern="-91" kpx2="92"/><pair kern="-35" kpx2="121"/><pair kern="-91" kpx2="110"/><pair kern="-91" kpx2="174"/><pair kern="-17" kpx2="249"/></kerning><kerning kpx1="124"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="169"><pair kern="-17" kpx2="90"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="246"/><pair kern="-17" kpx2="235"/><pair kern="-17" kpx2="58"/><pair kern="-17" kpx2="186"/><pair kern="-54" kpx2="55"/><pair kern="-17" kpx2="251"/><pair kern="-72" kpx2="187"/><pair kern="-17" kpx2="39"/><pair kern="73" kpx2="144"/><pair kern="-17" kpx2="45"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="38"/><pair kern="-72" kpx2="60"/><pair kern="-17" kpx2="89"/><pair kern="-17" kpx2="253"/><pair kern="-54" kpx2="57"/><pair kern="-17" kpx2="37"/><pair kern="-17" kpx2="42"/><pair kern="-72" kpx2="234"/></kerning><kerning kpx1="201"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="60"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="85"><pair kern="-21" kpx2="254"/><pair kern="-21" kpx2="72"/><pair kern="-63" kpx2="16"/><pair kern="-21" kpx2="112"/><pair kern="-21" kpx2="123"/><pair kern="-17" kpx2="80"/><pair kern="-21" kpx2="113"/><pair kern="-17" kpx2="71"/><pair kern="-21" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-21" kpx2="252"/><pair kern="-21" kpx2="70"/><pair kern="-17" kpx2="85"/><pair kern="-17" kpx2="29"/><pair kern="-21" kpx2="125"/><pair kern="-21" kpx2="115"/><pair kern="-21" kpx2="111"/><pair kern="-21" kpx2="122"/><pair kern="-21" kpx2="82"/><pair kern="-17" kpx2="75"/><pair kern="-21" kpx2="114"/><pair kern="-26" kpx2="91"/><pair kern="-17" kpx2="81"/><pair kern="41" kpx2="181"/><pair kern="-91" kpx2="17"/><pair kern="-151" kpx2="197"/><pair kern="-17" kpx2="74"/><pair kern="-17" kpx2="84"/><pair kern="-21" kpx2="121"/><pair kern="-17" kpx2="247"/><pair kern="-17" kpx2="120"/></kerning><kerning kpx1="61"><pair kern="-17" kpx2="180"/><pair kern="-17" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="234"><pair kern="-114" kpx2="126"/><pair kern="-137" kpx2="107"/><pair kern="-132" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-118" kpx2="16"/><pair kern="-132" kpx2="123"/><pair kern="-132" kpx2="112"/><pair kern="-54" kpx2="251"/><pair kern="-54" kpx2="208"/><pair kern="-132" kpx2="113"/><pair kern="-54" kpx2="180"/><pair kern="-137" kpx2="105"/><pair kern="-114" kpx2="129"/><pair kern="-132" kpx2="124"/><pair kern="-109" kpx2="169"/><pair kern="-77" kpx2="201"/><pair kern="-54" kpx2="253"/><pair kern="-137" kpx2="106"/><pair kern="-132" kpx2="29"/><pair kern="-132" kpx2="125"/><pair kern="-72" kpx2="170"/><pair kern="-132" kpx2="115"/><pair kern="-114" kpx2="88"/><pair kern="-132" kpx2="122"/><pair kern="-54" kpx2="100"/><pair kern="-137" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-77" kpx2="36"/><pair kern="-132" kpx2="82"/><pair kern="-132" kpx2="114"/><pair kern="-54" kpx2="175"/><pair kern="-114" kpx2="127"/><pair kern="-54" kpx2="50"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-137" kpx2="108"/><pair kern="-77" kpx2="98"/><pair kern="-35" kpx2="76"/><pair kern="-17" kpx2="181"/><pair kern="-202" kpx2="17"/><pair kern="-114" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-137" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-54" kpx2="38"/><pair kern="-132" kpx2="121"/><pair kern="-137" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="100"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="122"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="47"><pair kern="-17" kpx2="126"/><pair kern="-91" kpx2="235"/><pair kern="-49" kpx2="104"/><pair kern="-17" kpx2="72"/><pair kern="22" kpx2="199"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-49" kpx2="213"/><pair kern="-35" kpx2="208"/><pair kern="-132" kpx2="187"/><pair kern="-17" kpx2="113"/><pair kern="-202" kpx2="180"/><pair kern="-17" kpx2="129"/><pair kern="-17" kpx2="124"/><pair kern="22" kpx2="201"/><pair kern="-132" kpx2="60"/><pair kern="-49" kpx2="211"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="115"/><pair kern="-132" kpx2="234"/><pair kern="-17" kpx2="88"/><pair kern="-17" kpx2="122"/><pair kern="-35" kpx2="210"/><pair kern="22" kpx2="36"/><pair kern="-17" kpx2="82"/><pair kern="-91" kpx2="58"/><pair kern="-91" kpx2="186"/><pair kern="-137" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-35" kpx2="175"/><pair kern="-17" kpx2="127"/><pair kern="-35" kpx2="50"/><pair kern="-35" kpx2="209"/><pair kern="-35" kpx2="103"/><pair kern="22" kpx2="98"/><pair kern="-262" kpx2="181"/><pair kern="-17" kpx2="128"/><pair kern="22" kpx2="173"/><pair kern="-49" kpx2="212"/><pair kern="-91" kpx2="92"/><pair kern="-17" kpx2="121"/><pair kern="-109" kpx2="57"/><pair kern="22" kpx2="174"/><pair kern="-49" kpx2="56"/></kerning><kerning kpx1="210"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="58"><pair kern="-35" kpx2="126"/><pair kern="-63" kpx2="107"/><pair kern="-17" kpx2="235"/><pair kern="-58" kpx2="72"/><pair kern="-54" kpx2="199"/><pair kern="-40" kpx2="16"/><pair kern="-58" kpx2="112"/><pair kern="-58" kpx2="123"/><pair kern="-58" kpx2="113"/><pair kern="-17" kpx2="180"/><pair kern="-63" kpx2="105"/><pair kern="-35" kpx2="129"/><pair kern="-58" kpx2="124"/><pair kern="-54" kpx2="169"/><pair kern="-54" kpx2="201"/><pair kern="-44" kpx2="85"/><pair kern="-63" kpx2="106"/><pair kern="-58" kpx2="29"/><pair kern="-58" kpx2="125"/><pair kern="-17" kpx2="170"/><pair kern="-58" kpx2="115"/><pair kern="-35" kpx2="88"/><pair kern="-58" kpx2="122"/><pair kern="-63" kpx2="68"/><pair kern="-54" kpx2="36"/><pair kern="-58" kpx2="82"/><pair kern="-17" kpx2="186"/><pair kern="-58" kpx2="114"/><pair kern="-35" kpx2="127"/><pair kern="-63" kpx2="108"/><pair kern="-54" kpx2="98"/><pair kern="-21" kpx2="76"/><pair kern="-114" kpx2="17"/><pair kern="-35" kpx2="128"/><pair kern="-54" kpx2="173"/><pair kern="-63" kpx2="109"/><pair kern="-128" kpx2="197"/><pair kern="-17" kpx2="92"/><pair kern="-58" kpx2="121"/><pair kern="-63" kpx2="110"/><pair kern="-54" kpx2="174"/></kerning><kerning kpx1="82"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="186"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="175"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="209"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="103"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="81"><pair kern="-72" kpx2="180"/><pair kern="-44" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="98"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="212"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="229"><pair kern="-17" kpx2="180"/><pair kern="-17" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="38"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="121"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="57"><pair kern="-67" kpx2="126"/><pair kern="-77" kpx2="107"/><pair kern="-26" kpx2="235"/><pair kern="-77" kpx2="72"/><pair kern="-63" kpx2="199"/><pair kern="-58" kpx2="16"/><pair kern="-77" kpx2="123"/><pair kern="-77" kpx2="112"/><pair kern="-17" kpx2="208"/><pair kern="-77" kpx2="113"/><pair kern="-77" kpx2="105"/><pair kern="-67" kpx2="129"/><pair kern="-77" kpx2="124"/><pair kern="-86" kpx2="169"/><pair kern="-63" kpx2="201"/><pair kern="-77" kpx2="106"/><pair kern="-81" kpx2="29"/><pair kern="-77" kpx2="125"/><pair kern="-54" kpx2="170"/><pair kern="-77" kpx2="115"/><pair kern="-67" kpx2="88"/><pair kern="-77" kpx2="122"/><pair kern="-77" kpx2="68"/><pair kern="-17" kpx2="210"/><pair kern="-63" kpx2="36"/><pair kern="-77" kpx2="82"/><pair kern="-26" kpx2="186"/><pair kern="-77" kpx2="114"/><pair kern="-17" kpx2="175"/><pair kern="-67" kpx2="127"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-77" kpx2="108"/><pair kern="-63" kpx2="98"/><pair kern="-21" kpx2="76"/><pair kern="-128" kpx2="17"/><pair kern="-67" kpx2="128"/><pair kern="-63" kpx2="173"/><pair kern="-77" kpx2="109"/><pair kern="-137" kpx2="197"/><pair kern="-26" kpx2="92"/><pair kern="-77" kpx2="121"/><pair kern="-77" kpx2="110"/><pair kern="-63" kpx2="174"/></kerning><kerning kpx1="37"><pair kern="-17" kpx2="227"/><pair kern="-17" kpx2="246"/><pair kern="-17" kpx2="251"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-17" kpx2="54"/><pair kern="-54" kpx2="180"/><pair kern="-30" kpx2="169"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="170"/><pair kern="-54" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="210"/><pair kern="-35" kpx2="58"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-54" kpx2="181"/><pair kern="-40" kpx2="197"/><pair kern="-17" kpx2="38"/><pair kern="-30" kpx2="57"/><pair kern="-17" kpx2="249"/></kerning><kerning kpx1="120"><pair kern="-72" kpx2="180"/><pair kern="-44" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="249"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="227"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="51"><pair kern="-17" kpx2="126"/><pair kern="-44" kpx2="107"/><pair kern="-35" kpx2="72"/><pair kern="-63" kpx2="199"/><pair kern="-21" kpx2="16"/><pair kern="-35" kpx2="123"/><pair kern="-35" kpx2="112"/><pair kern="-21" kpx2="187"/><pair kern="-35" kpx2="113"/><pair kern="-17" kpx2="86"/><pair kern="18" kpx2="180"/><pair kern="-44" kpx2="105"/><pair kern="-17" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-17" kpx2="169"/><pair kern="-63" kpx2="201"/><pair kern="-17" kpx2="85"/><pair kern="-21" kpx2="60"/><pair kern="-44" kpx2="106"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="115"/><pair kern="-21" kpx2="234"/><pair kern="-17" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-44" kpx2="68"/><pair kern="-63" kpx2="36"/><pair kern="-35" kpx2="82"/><pair kern="-35" kpx2="114"/><pair kern="-17" kpx2="250"/><pair kern="-17" kpx2="127"/><pair kern="-44" kpx2="108"/><pair kern="-63" kpx2="98"/><pair kern="-17" kpx2="81"/><pair kern="-21" kpx2="76"/><pair kern="18" kpx2="181"/><pair kern="-155" kpx2="17"/><pair kern="-17" kpx2="128"/><pair kern="-63" kpx2="173"/><pair kern="-44" kpx2="109"/><pair kern="-160" kpx2="197"/><pair kern="-35" kpx2="121"/><pair kern="-17" kpx2="228"/><pair kern="-44" kpx2="110"/><pair kern="-63" kpx2="174"/><pair kern="-17" kpx2="120"/></kerning><kerning kpx1="104"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="72"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="199"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="54"><pair kern="18" kpx2="173"/><pair kern="18" kpx2="36"/><pair kern="18" kpx2="201"/><pair kern="18" kpx2="199"/><pair kern="18" kpx2="174"/><pair kern="18" kpx2="98"/></kerning><kerning kpx1="180"><pair kern="-35" kpx2="235"/><pair kern="-35" kpx2="246"/><pair kern="-30" kpx2="43"/><pair kern="-72" kpx2="123"/><pair kern="-35" kpx2="251"/><pair kern="-35" kpx2="208"/><pair kern="-188" kpx2="144"/><pair kern="-58" kpx2="59"/><pair kern="-35" kpx2="73"/><pair kern="-30" kpx2="41"/><pair kern="-72" kpx2="124"/><pair kern="-54" kpx2="85"/><pair kern="-128" kpx2="201"/><pair kern="-17" kpx2="61"/><pair kern="-35" kpx2="100"/><pair kern="-72" kpx2="122"/><pair kern="-30" kpx2="47"/><pair kern="-35" kpx2="210"/><pair kern="-72" kpx2="82"/><pair kern="-35" kpx2="186"/><pair kern="-35" kpx2="175"/><pair kern="-35" kpx2="209"/><pair kern="-35" kpx2="103"/><pair kern="-128" kpx2="98"/><pair kern="-54" kpx2="81"/><pair kern="-17" kpx2="229"/><pair kern="-35" kpx2="38"/><pair kern="-72" kpx2="121"/><pair kern="-30" kpx2="37"/><pair kern="-54" kpx2="120"/><pair kern="-30" kpx2="51"/><pair kern="-128" kpx2="199"/><pair kern="-30" kpx2="53"/><pair kern="-30" kpx2="137"/><pair kern="-35" kpx2="233"/><pair kern="-35" kpx2="253"/><pair kern="-35" kpx2="52"/><pair kern="-72" kpx2="125"/><pair kern="-35" kpx2="42"/><pair kern="-35" kpx2="90"/><pair kern="-128" kpx2="36"/><pair kern="-35" kpx2="50"/><pair kern="-30" kpx2="39"/><pair kern="-30" kpx2="236"/><pair kern="-30" kpx2="45"/><pair kern="-128" kpx2="173"/><pair kern="-35" kpx2="92"/><pair kern="-35" kpx2="89"/><pair kern="-30" kpx2="46"/><pair kern="-128" kpx2="174"/></kerning><kerning kpx1="53"><pair kern="-21" kpx2="107"/><pair kern="-54" kpx2="235"/><pair kern="-40" kpx2="16"/><pair kern="-44" kpx2="112"/><pair kern="-44" kpx2="123"/><pair kern="-49" kpx2="251"/><pair kern="-44" kpx2="113"/><pair kern="-63" kpx2="187"/><pair kern="-44" kpx2="129"/><pair kern="-44" kpx2="124"/><pair kern="-54" kpx2="169"/><pair kern="-63" kpx2="60"/><pair kern="-40" kpx2="201"/><pair kern="-21" kpx2="106"/><pair kern="-30" kpx2="29"/><pair kern="-63" kpx2="234"/><pair kern="-49" kpx2="100"/><pair kern="-44" kpx2="122"/><pair kern="-21" kpx2="68"/><pair kern="-40" kpx2="58"/><pair kern="-44" kpx2="82"/><pair kern="-54" kpx2="186"/><pair kern="-40" kpx2="98"/><pair kern="-63" kpx2="181"/><pair kern="-35" kpx2="17"/><pair kern="-49" kpx2="38"/><pair kern="-44" kpx2="121"/><pair kern="-54" kpx2="57"/><pair kern="-44" kpx2="126"/><pair kern="-44" kpx2="72"/><pair kern="-40" kpx2="199"/><pair kern="-72" kpx2="180"/><pair kern="-21" kpx2="105"/><pair kern="-49" kpx2="253"/><pair kern="-44" kpx2="125"/><pair kern="-44" kpx2="115"/><pair kern="-17" kpx2="170"/><pair kern="-44" kpx2="88"/><pair kern="-40" kpx2="36"/><pair kern="-44" kpx2="114"/><pair kern="-72" kpx2="55"/><pair kern="-44" kpx2="127"/><pair kern="-21" kpx2="108"/><pair kern="-44" kpx2="128"/><pair kern="-40" kpx2="173"/><pair kern="-21" kpx2="109"/><pair kern="-54" kpx2="92"/><pair kern="-17" kpx2="197"/><pair kern="-21" kpx2="110"/><pair kern="-40" kpx2="174"/></kerning><kerning kpx1="137"><pair kern="-54" kpx2="180"/><pair kern="-40" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="233"><pair kern="-44" kpx2="180"/><pair kern="-35" kpx2="197"/><pair kern="-54" kpx2="181"/></kerning><kerning kpx1="253"><pair kern="-17" kpx2="169"/><pair kern="-17" kpx2="60"/><pair kern="-17" kpx2="187"/><pair kern="18" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-17" kpx2="234"/></kerning><kerning kpx1="211"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning><kerning kpx1="78"><pair kern="-17" kpx2="107"/><pair kern="-30" kpx2="126"/><pair kern="-35" kpx2="235"/><pair kern="-35" kpx2="72"/><pair kern="-35" kpx2="112"/><pair kern="-35" kpx2="123"/><pair kern="-35" kpx2="113"/><pair kern="-17" kpx2="105"/><pair kern="-30" kpx2="129"/><pair kern="-35" kpx2="124"/><pair kern="-17" kpx2="106"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="115"/><pair kern="-30" kpx2="88"/><pair kern="-35" kpx2="122"/><pair kern="-17" kpx2="68"/><pair kern="-35" kpx2="82"/><pair kern="-35" kpx2="114"/><pair kern="-35" kpx2="186"/><pair kern="-30" kpx2="127"/><pair kern="-17" kpx2="108"/><pair kern="-30" kpx2="128"/><pair kern="-17" kpx2="109"/><pair kern="-35" kpx2="92"/><pair kern="-35" kpx2="121"/><pair kern="-17" kpx2="110"/></kerning><kerning kpx1="52"><pair kern="-21" kpx2="180"/><pair kern="-63" kpx2="197"/><pair kern="27" kpx2="16"/><pair kern="-17" kpx2="181"/></kerning><kerning kpx1="125"><pair kern="-72" kpx2="180"/><pair kern="-17" kpx2="17"/><pair kern="-63" kpx2="197"/><pair kern="18" kpx2="16"/><pair kern="-30" kpx2="91"/><pair kern="-35" kpx2="181"/></kerning><kerning kpx1="42"><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="169"/><pair kern="-26" kpx2="197"/><pair kern="-35" kpx2="55"/><pair kern="-49" kpx2="60"/><pair kern="-49" kpx2="187"/><pair kern="-21" kpx2="181"/><pair kern="-17" kpx2="170"/><pair kern="-49" kpx2="234"/></kerning><kerning kpx1="170"><pair kern="-17" kpx2="235"/><pair kern="-35" kpx2="199"/><pair kern="-17" kpx2="251"/><pair kern="-109" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-54" kpx2="59"/><pair kern="-109" kpx2="60"/><pair kern="-35" kpx2="201"/><pair kern="-17" kpx2="253"/><pair kern="-109" kpx2="234"/><pair kern="-17" kpx2="90"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="210"/><pair kern="-35" kpx2="36"/><pair kern="-54" kpx2="58"/><pair kern="-91" kpx2="55"/><pair kern="-17" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="50"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="-17" kpx2="39"/><pair kern="-35" kpx2="98"/><pair kern="-17" kpx2="45"/><pair kern="-35" kpx2="173"/><pair kern="-17" kpx2="92"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="89"/><pair kern="-86" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-35" kpx2="174"/></kerning><kerning kpx1="115"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="90"><pair kern="-91" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-104" kpx2="197"/><pair kern="-54" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="36"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="55"><pair kern="-165" kpx2="107"/><pair kern="-155" kpx2="235"/><pair kern="-91" kpx2="16"/><pair kern="-169" kpx2="112"/><pair kern="-169" kpx2="123"/><pair kern="-58" kpx2="251"/><pair kern="-169" kpx2="113"/><pair kern="-165" kpx2="86"/><pair kern="-151" kpx2="129"/><pair kern="-169" kpx2="124"/><pair kern="-91" kpx2="169"/><pair kern="-169" kpx2="252"/><pair kern="-169" kpx2="70"/><pair kern="-146" kpx2="85"/><pair kern="-77" kpx2="201"/><pair kern="-165" kpx2="106"/><pair kern="-109" kpx2="29"/><pair kern="-58" kpx2="100"/><pair kern="-169" kpx2="122"/><pair kern="-165" kpx2="68"/><pair kern="-169" kpx2="82"/><pair kern="-155" kpx2="186"/><pair kern="-165" kpx2="250"/><pair kern="-77" kpx2="98"/><pair kern="-21" kpx2="181"/><pair kern="-118" kpx2="17"/><pair kern="-58" kpx2="38"/><pair kern="-169" kpx2="121"/><pair kern="-165" kpx2="228"/><pair kern="-169" kpx2="254"/><pair kern="-151" kpx2="126"/><pair kern="-169" kpx2="72"/><pair kern="-77" kpx2="199"/><pair kern="-165" kpx2="105"/><pair kern="-58" kpx2="253"/><pair kern="-169" kpx2="125"/><pair kern="-169" kpx2="115"/><pair kern="-54" kpx2="170"/><pair kern="-151" kpx2="88"/><pair kern="-169" kpx2="111"/><pair kern="-165" kpx2="90"/><pair kern="-77" kpx2="36"/><pair kern="-17" kpx2="55"/><pair kern="-169" kpx2="114"/><pair kern="-151" kpx2="127"/><pair kern="-165" kpx2="108"/><pair kern="-30" kpx2="76"/><pair kern="-151" kpx2="128"/><pair kern="-77" kpx2="173"/><pair kern="-165" kpx2="109"/><pair kern="-155" kpx2="92"/><pair kern="-128" kpx2="197"/><pair kern="-165" kpx2="110"/><pair kern="-77" kpx2="174"/></kerning><kerning kpx1="114"><pair kern="-17" kpx2="91"/></kerning><kerning kpx1="50"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="27" kpx2="16"/><pair kern="-54" kpx2="187"/><pair kern="-17" kpx2="98"/><pair kern="-17" kpx2="181"/><pair kern="-63" kpx2="59"/><pair kern="-40" kpx2="17"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="29"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="91"><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="111"/><pair kern="-30" kpx2="122"/><pair kern="-30" kpx2="82"/><pair kern="-30" kpx2="114"/><pair kern="-30" kpx2="72"/><pair kern="-30" kpx2="112"/><pair kern="-30" kpx2="123"/><pair kern="-30" kpx2="113"/><pair kern="-30" kpx2="124"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-30" kpx2="121"/><pair kern="-30" kpx2="125"/><pair kern="-30" kpx2="115"/></kerning><kerning kpx1="39"><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="199"/><pair kern="-17" kpx2="98"/><pair kern="-54" kpx2="187"/><pair kern="-26" kpx2="181"/><pair kern="-21" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="169"/><pair kern="-91" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-54" kpx2="60"/><pair kern="-17" kpx2="57"/><pair kern="-17" kpx2="174"/><pair kern="-17" kpx2="170"/><pair kern="-54" kpx2="234"/></kerning><kerning kpx1="236"><pair kern="-17" kpx2="180"/><pair kern="-72" kpx2="17"/><pair kern="-91" kpx2="197"/><pair kern="-35" kpx2="29"/></kerning><kerning kpx1="45"><pair kern="-35" kpx2="180"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="36"/><pair kern="-17" kpx2="169"/><pair kern="-54" kpx2="197"/><pair kern="-17" kpx2="201"/><pair kern="-17" kpx2="199"/><pair kern="-35" kpx2="16"/><pair kern="-17" kpx2="174"/><pair kern="-17" kpx2="98"/><pair kern="-30" kpx2="181"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="173"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="197"><pair kern="-35" kpx2="246"/><pair kern="-54" kpx2="235"/><pair kern="-35" kpx2="43"/><pair kern="-35" kpx2="123"/><pair kern="-54" kpx2="251"/><pair kern="-183" kpx2="187"/><pair kern="-54" kpx2="208"/><pair kern="18" kpx2="144"/><pair kern="-35" kpx2="59"/><pair kern="-17" kpx2="73"/><pair kern="-35" kpx2="41"/><pair kern="-35" kpx2="124"/><pair kern="-35" kpx2="85"/><pair kern="-183" kpx2="60"/><pair kern="18" kpx2="201"/><pair kern="-183" kpx2="234"/><pair kern="-54" kpx2="100"/><pair kern="-35" kpx2="122"/><pair kern="-35" kpx2="47"/><pair kern="-54" kpx2="210"/><pair kern="-35" kpx2="82"/><pair kern="-123" kpx2="58"/><pair kern="-54" kpx2="186"/><pair kern="-54" kpx2="175"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-35" kpx2="81"/><pair kern="18" kpx2="98"/><pair kern="-54" kpx2="38"/><pair kern="-35" kpx2="121"/><pair kern="-183" kpx2="57"/><pair kern="-35" kpx2="37"/><pair kern="-35" kpx2="120"/><pair kern="-35" kpx2="51"/><pair kern="18" kpx2="199"/><pair kern="-35" kpx2="53"/><pair kern="-35" kpx2="137"/><pair kern="-35" kpx2="233"/><pair kern="-54" kpx2="253"/><pair kern="-54" kpx2="52"/><pair kern="-35" kpx2="125"/><pair kern="-35" kpx2="42"/><pair kern="-95" kpx2="90"/><pair kern="18" kpx2="36"/><pair kern="-137" kpx2="55"/><pair kern="-54" kpx2="50"/><pair kern="-35" kpx2="39"/><pair kern="-35" kpx2="236"/><pair kern="22" kpx2="45"/><pair kern="18" kpx2="173"/><pair kern="-54" kpx2="92"/><pair kern="-114" kpx2="89"/><pair kern="-35" kpx2="46"/><pair kern="18" kpx2="174"/></kerning><kerning kpx1="92"><pair kern="-142" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-146" kpx2="197"/><pair kern="-17" kpx2="16"/><pair kern="-72" kpx2="29"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="89"><pair kern="-77" kpx2="17"/><pair kern="-17" kpx2="169"/><pair kern="-132" kpx2="197"/><pair kern="-26" kpx2="16"/><pair kern="-54" kpx2="29"/><pair kern="-17" kpx2="181"/><pair kern="-17" kpx2="170"/></kerning><kerning kpx1="46"><pair kern="-17" kpx2="107"/><pair kern="-72" kpx2="235"/><pair kern="-104" kpx2="16"/><pair kern="-49" kpx2="112"/><pair kern="-49" kpx2="123"/><pair kern="-54" kpx2="251"/><pair kern="-26" kpx2="213"/><pair kern="-49" kpx2="113"/><pair kern="-35" kpx2="187"/><pair kern="-54" kpx2="208"/><pair kern="-49" kpx2="129"/><pair kern="-49" kpx2="124"/><pair kern="-63" kpx2="169"/><pair kern="-35" kpx2="60"/><pair kern="-17" kpx2="201"/><pair kern="-17" kpx2="106"/><pair kern="-35" kpx2="234"/><pair kern="-54" kpx2="100"/><pair kern="-49" kpx2="122"/><pair kern="-17" kpx2="68"/><pair kern="-54" kpx2="210"/><pair kern="-35" kpx2="58"/><pair kern="-49" kpx2="82"/><pair kern="-72" kpx2="186"/><pair kern="-54" kpx2="175"/><pair kern="-54" kpx2="209"/><pair kern="-54" kpx2="103"/><pair kern="-17" kpx2="98"/><pair kern="-30" kpx2="181"/><pair kern="-26" kpx2="212"/><pair kern="-54" kpx2="38"/><pair kern="-49" kpx2="121"/><pair kern="-49" kpx2="126"/><pair kern="-26" kpx2="104"/><pair kern="-49" kpx2="72"/><pair kern="-17" kpx2="199"/><pair kern="-30" kpx2="180"/><pair kern="-17" kpx2="105"/><pair kern="-54" kpx2="253"/><pair kern="-26" kpx2="211"/><pair kern="-49" kpx2="125"/><pair kern="-49" kpx2="115"/><pair kern="-49" kpx2="88"/><pair kern="-17" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-49" kpx2="114"/><pair kern="-54" kpx2="50"/><pair kern="-49" kpx2="127"/><pair kern="-17" kpx2="108"/><pair kern="-49" kpx2="128"/><pair kern="-17" kpx2="173"/><pair kern="-17" kpx2="109"/><pair kern="-72" kpx2="92"/><pair kern="-17" kpx2="110"/><pair kern="-17" kpx2="174"/><pair kern="-26" kpx2="56"/></kerning><kerning kpx1="174"><pair kern="-17" kpx2="246"/><pair kern="-67" kpx2="235"/><pair kern="-21" kpx2="16"/><pair kern="-17" kpx2="112"/><pair kern="-17" kpx2="123"/><pair kern="-17" kpx2="251"/><pair kern="-17" kpx2="113"/><pair kern="-77" kpx2="187"/><pair kern="-17" kpx2="208"/><pair kern="-35" kpx2="73"/><pair kern="-17" kpx2="124"/><pair kern="-35" kpx2="169"/><pair kern="-17" kpx2="252"/><pair kern="-17" kpx2="70"/><pair kern="-77" kpx2="60"/><pair kern="27" kpx2="201"/><pair kern="-17" kpx2="29"/><pair kern="-77" kpx2="234"/><pair kern="-17" kpx2="100"/><pair kern="-17" kpx2="122"/><pair kern="-17" kpx2="210"/><pair kern="-17" kpx2="82"/><pair kern="-54" kpx2="58"/><pair kern="-67" kpx2="186"/><pair kern="-17" kpx2="175"/><pair kern="-17" kpx2="209"/><pair kern="-17" kpx2="103"/><pair kern="27" kpx2="98"/><pair kern="-123" kpx2="181"/><pair kern="-17" kpx2="17"/><pair kern="-17" kpx2="38"/><pair kern="-17" kpx2="84"/><pair kern="-17" kpx2="121"/><pair kern="-63" kpx2="57"/><pair kern="-17" kpx2="254"/><pair kern="-17" kpx2="87"/><pair kern="-17" kpx2="72"/><pair kern="27" kpx2="199"/><pair kern="-17" kpx2="71"/><pair kern="-128" kpx2="180"/><pair kern="-17" kpx2="253"/><pair kern="-17" kpx2="52"/><pair kern="-17" kpx2="125"/><pair kern="-17" kpx2="42"/><pair kern="-17" kpx2="115"/><pair kern="-40" kpx2="90"/><pair kern="-17" kpx2="111"/><pair kern="27" kpx2="36"/><pair kern="-77" kpx2="55"/><pair kern="-17" kpx2="114"/><pair kern="-17" kpx2="50"/><pair kern="27" kpx2="173"/><pair kern="-67" kpx2="92"/><pair kern="22" kpx2="197"/><pair kern="-58" kpx2="89"/><pair kern="27" kpx2="174"/></kerning><kerning kpx1="56"><pair kern="-17" kpx2="229"/><pair kern="-17" kpx2="61"/></kerning></font-metrics>
\ No newline at end of file diff --git a/documentation/template/VeraMoBd.ttf b/documentation/template/VeraMoBd.ttf Binary files differdeleted file mode 100644 index 9be6547ed6..0000000000 --- a/documentation/template/VeraMoBd.ttf +++ /dev/null diff --git a/documentation/template/VeraMoBd.xml b/documentation/template/VeraMoBd.xml deleted file mode 100644 index 9b33107a44..0000000000 --- a/documentation/template/VeraMoBd.xml +++ /dev/null @@ -1 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?><font-metrics metrics-version="2" type="TYPE0"><font-name>BitstreamVeraSansMono-Bold</font-name><full-name>Bitstream Vera Sans Mono Bold</full-name><family-name>Bitstream Vera Sans Mono</family-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>759</ascender><descender>-240</descender><bbox><left>-19</left><bottom>-235</bottom><right>605</right><top>928</top></bbox><flags>34</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="602"/><wx w="0"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/></cid-widths></multibyte-extras></font-metrics>
\ No newline at end of file diff --git a/documentation/template/VeraMono.ttf b/documentation/template/VeraMono.ttf Binary files differdeleted file mode 100644 index 139f0b4311..0000000000 --- a/documentation/template/VeraMono.ttf +++ /dev/null diff --git a/documentation/template/VeraMono.xml b/documentation/template/VeraMono.xml deleted file mode 100644 index 3a0a86659c..0000000000 --- a/documentation/template/VeraMono.xml +++ /dev/null @@ -1 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?><font-metrics metrics-version="2" type="TYPE0"><font-name>BitstreamVeraSansMono-Roman</font-name><full-name>Bitstream Vera Sans Mono</full-name><family-name>Bitstream Vera Sans Mono</family-name><embed/><cap-height>729</cap-height><x-height>546</x-height><ascender>759</ascender><descender>-240</descender><bbox><left>-4</left><bottom>-235</bottom><right>605</right><top>928</top></bbox><flags>34</flags><stemv>0</stemv><italicangle>0</italicangle><subtype>TYPE0</subtype><multibyte-extras><cid-type>CIDFontType2</cid-type><default-width>0</default-width><bfranges><bf gi="3" ue="126" us="32"/><bf gi="172" ue="160" us="160"/><bf gi="163" ue="161" us="161"/><bf gi="132" ue="163" us="162"/><bf gi="189" ue="164" us="164"/><bf gi="150" ue="165" us="165"/><bf gi="231" ue="166" us="166"/><bf gi="134" ue="167" us="167"/><bf gi="142" ue="168" us="168"/><bf gi="139" ue="169" us="169"/><bf gi="157" ue="170" us="170"/><bf gi="169" ue="171" us="171"/><bf gi="164" ue="172" us="172"/><bf gi="256" ue="173" us="173"/><bf gi="138" ue="174" us="174"/><bf gi="217" ue="175" us="175"/><bf gi="131" ue="176" us="176"/><bf gi="147" ue="177" us="177"/><bf gi="241" ue="179" us="178"/><bf gi="141" ue="180" us="180"/><bf gi="151" ue="181" us="181"/><bf gi="136" ue="182" us="182"/><bf gi="195" ue="183" us="183"/><bf gi="221" ue="184" us="184"/><bf gi="240" ue="185" us="185"/><bf gi="158" ue="186" us="186"/><bf gi="170" ue="187" us="187"/><bf gi="243" ue="190" us="188"/><bf gi="162" ue="191" us="191"/><bf gi="173" ue="192" us="192"/><bf gi="201" ue="193" us="193"/><bf gi="199" ue="194" us="194"/><bf gi="174" ue="195" us="195"/><bf gi="98" ue="197" us="196"/><bf gi="144" ue="198" us="198"/><bf gi="100" ue="199" us="199"/><bf gi="203" ue="200" us="200"/><bf gi="101" ue="201" us="201"/><bf gi="200" ue="202" us="202"/><bf gi="202" ue="203" us="203"/><bf gi="207" ue="204" us="204"/><bf gi="204" ue="207" us="205"/><bf gi="232" ue="208" us="208"/><bf gi="102" ue="209" us="209"/><bf gi="210" ue="210" us="210"/><bf gi="208" ue="212" us="211"/><bf gi="175" ue="213" us="213"/><bf gi="103" ue="214" us="214"/><bf gi="239" ue="215" us="215"/><bf gi="145" ue="216" us="216"/><bf gi="213" ue="217" us="217"/><bf gi="211" ue="219" us="218"/><bf gi="104" ue="220" us="220"/><bf gi="234" ue="221" us="221"/><bf gi="236" ue="222" us="222"/><bf gi="137" ue="223" us="223"/><bf gi="106" ue="224" us="224"/><bf gi="105" ue="225" us="225"/><bf gi="107" ue="226" us="226"/><bf gi="109" ue="227" us="227"/><bf gi="108" ue="228" us="228"/><bf gi="110" ue="229" us="229"/><bf gi="160" ue="230" us="230"/><bf gi="111" ue="231" us="231"/><bf gi="113" ue="232" us="232"/><bf gi="112" ue="233" us="233"/><bf gi="114" ue="235" us="234"/><bf gi="117" ue="236" us="236"/><bf gi="116" ue="237" us="237"/><bf gi="118" ue="239" us="238"/><bf gi="233" ue="240" us="240"/><bf gi="120" ue="241" us="241"/><bf gi="122" ue="242" us="242"/><bf gi="121" ue="243" us="243"/><bf gi="123" ue="244" us="244"/><bf gi="125" ue="245" us="245"/><bf gi="124" ue="246" us="246"/><bf gi="184" ue="247" us="247"/><bf gi="161" ue="248" us="248"/><bf gi="127" ue="249" us="249"/><bf gi="126" ue="250" us="250"/><bf gi="128" ue="252" us="251"/><bf gi="235" ue="253" us="253"/><bf gi="237" ue="254" us="254"/><bf gi="186" ue="255" us="255"/><bf gi="251" ue="263" us="262"/><bf gi="253" ue="269" us="268"/><bf gi="0" ue="270" us="270"/><bf gi="0" ue="271" us="271"/><bf gi="0" ue="272" us="272"/><bf gi="255" ue="273" us="273"/><bf gi="246" ue="287" us="286"/><bf gi="248" ue="304" us="304"/><bf gi="214" ue="305" us="305"/><bf gi="225" ue="322" us="321"/><bf gi="176" ue="339" us="338"/><bf gi="249" ue="351" us="350"/><bf gi="227" ue="353" us="352"/><bf gi="187" ue="376" us="376"/><bf gi="229" ue="382" us="381"/><bf gi="166" ue="402" us="402"/><bf gi="215" ue="710" us="710"/><bf gi="224" ue="711" us="711"/><bf gi="218" ue="730" us="728"/><bf gi="223" ue="731" us="731"/><bf gi="216" ue="732" us="732"/><bf gi="222" ue="733" us="733"/><bf gi="159" ue="937" us="937"/><bf gi="155" ue="960" us="960"/><bf gi="178" ue="8212" us="8211"/><bf gi="0" ue="8213" us="8213"/><bf gi="0" ue="8214" us="8214"/><bf gi="0" ue="8215" us="8215"/><bf gi="182" ue="8217" us="8216"/><bf gi="196" ue="8218" us="8218"/><bf gi="0" ue="8219" us="8219"/><bf gi="180" ue="8221" us="8220"/><bf gi="197" ue="8222" us="8222"/><bf gi="0" ue="8223" us="8223"/><bf gi="130" ue="8224" us="8224"/><bf gi="194" ue="8225" us="8225"/><bf gi="135" ue="8226" us="8226"/><bf gi="0" ue="8227" us="8227"/><bf gi="0" ue="8228" us="8228"/><bf gi="0" ue="8229" us="8229"/><bf gi="171" ue="8230" us="8230"/><bf gi="198" ue="8240" us="8240"/><bf gi="190" ue="8250" us="8249"/><bf gi="258" ue="8364" us="8364"/><bf gi="140" ue="8482" us="8482"/><bf gi="152" ue="8706" us="8706"/><bf gi="0" ue="8707" us="8707"/><bf gi="0" ue="8708" us="8708"/><bf gi="0" ue="8709" us="8709"/><bf gi="168" ue="8710" us="8710"/><bf gi="154" ue="8719" us="8719"/><bf gi="0" ue="8720" us="8720"/><bf gi="153" ue="8721" us="8721"/><bf gi="238" ue="8722" us="8722"/><bf gi="0" ue="8723" us="8723"/><bf gi="0" ue="8724" us="8724"/><bf gi="188" ue="8725" us="8725"/><bf gi="0" ue="8726" us="8726"/><bf gi="0" ue="8727" us="8727"/><bf gi="0" ue="8728" us="8728"/><bf gi="257" ue="8729" us="8729"/><bf gi="165" ue="8730" us="8730"/><bf gi="0" ue="8731" us="8731"/><bf gi="0" ue="8732" us="8732"/><bf gi="0" ue="8733" us="8733"/><bf gi="146" ue="8734" us="8734"/><bf gi="156" ue="8747" us="8747"/><bf gi="167" ue="8776" us="8776"/><bf gi="143" ue="8800" us="8800"/><bf gi="0" ue="8801" us="8801"/><bf gi="0" ue="8802" us="8802"/><bf gi="0" ue="8803" us="8803"/><bf gi="148" ue="8805" us="8804"/><bf gi="185" ue="9674" us="9674"/><bf gi="192" ue="64258" us="64257"/><bf gi="0" ue="65535" us="65535"/></bfranges><cid-widths start-index="0"><wx w="602"/><wx w="0"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/><wx w="602"/></cid-widths></multibyte-extras></font-metrics>
\ No newline at end of file diff --git a/documentation/template/draft.png b/documentation/template/draft.png Binary files differdeleted file mode 100644 index 53051a9ddd..0000000000 --- a/documentation/template/draft.png +++ /dev/null diff --git a/documentation/template/fop-config.xml b/documentation/template/fop-config.xml deleted file mode 100644 index 09cc5ca0f5..0000000000 --- a/documentation/template/fop-config.xml +++ /dev/null @@ -1,58 +0,0 @@ -<fop version="1.0"> - - <!-- Strict user configuration --> - <strict-configuration>true</strict-configuration> - - <!-- Strict FO validation --> - <strict-validation>true</strict-validation> - - <!-- - Set the baseDir so common/openedhand.svg references in plans still - work ok. Note, relative file references to current dir should still work. - --> - <base>../template</base> - <font-base>../template</font-base> - - <!-- Source resolution in dpi (dots/pixels per inch) for determining the - size of pixels in SVG and bitmap images, default: 72dpi --> - <!-- <source-resolution>72</source-resolution> --> - <!-- Target resolution in dpi (dots/pixels per inch) for specifying the - target resolution for generated bitmaps, default: 72dpi --> - <!-- <target-resolution>72</target-resolution> --> - - <!-- default page-height and page-width, in case - value is specified as auto --> - <default-page-settings height="11in" width="8.26in"/> - - <!-- <use-cache>false</use-cache> --> - - <renderers> - <renderer mime="application/pdf"> - <fonts> - <font metrics-file="VeraMono.xml" - kerning="yes" - embed-url="VeraMono.ttf"> - <font-triplet name="veramono" style="normal" weight="normal"/> - </font> - - <font metrics-file="VeraMoBd.xml" - kerning="yes" - embed-url="VeraMoBd.ttf"> - <font-triplet name="veramono" style="normal" weight="bold"/> - </font> - - <font metrics-file="Vera.xml" - kerning="yes" - embed-url="Vera.ttf"> - <font-triplet name="verasans" style="normal" weight="normal"/> - <font-triplet name="verasans" style="normal" weight="bold"/> - <font-triplet name="verasans" style="italic" weight="normal"/> - <font-triplet name="verasans" style="italic" weight="bold"/> - </font> - - <auto-detect/> - </fonts> - </renderer> - </renderers> -</fop> - diff --git a/documentation/template/ohand-color.svg b/documentation/template/ohand-color.svg deleted file mode 100644 index e42ff9c6fc..0000000000 --- a/documentation/template/ohand-color.svg +++ /dev/null @@ -1,150 +0,0 @@ -<?xml version="1.0" encoding="UTF-8" standalone="no"?> -<!-- Created with Inkscape (http://www.inkscape.org/) --> -<svg - xmlns:dc="http://purl.org/dc/elements/1.1/" - xmlns:cc="http://web.resource.org/cc/" - xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" - xmlns:svg="http://www.w3.org/2000/svg" - xmlns="http://www.w3.org/2000/svg" - xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" - xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" - width="141.17999" - height="55.34" - id="svg2207" - sodipodi:version="0.32" - inkscape:version="0.45" - version="1.0" - sodipodi:docname="ohand-color.svg" - inkscape:output_extension="org.inkscape.output.svg.inkscape" - sodipodi:docbase="/home/mallum/Projects/admin/oh-doc-tools/common" - sodipodi:modified="true"> - <defs - id="defs3" /> - <sodipodi:namedview - id="base" - pagecolor="#ffffff" - bordercolor="#666666" - borderopacity="1.0" - inkscape:pageopacity="0.0" - inkscape:pageshadow="2" - inkscape:zoom="1.2" - inkscape:cx="160" - inkscape:cy="146.21189" - inkscape:document-units="mm" - inkscape:current-layer="layer1" - height="55.34px" - width="141.18px" - inkscape:window-width="772" - inkscape:window-height="581" - inkscape:window-x="5" - inkscape:window-y="48" /> - <metadata - id="metadata2211"> - <rdf:RDF> - <cc:Work - rdf:about=""> - <dc:format>image/svg+xml</dc:format> - <dc:type - rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> - </cc:Work> - </rdf:RDF> - </metadata> - <g - inkscape:label="Layer 1" - inkscape:groupmode="layer" - id="layer1"> - <g - id="g2094" - style="fill:#6d6d70;fill-opacity:1" - inkscape:export-filename="/home/mallum/Desktop/g2126.png" - inkscape:export-xdpi="312.71841" - inkscape:export-ydpi="312.71841" - transform="matrix(0.5954767,0,0,0.5954767,31.793058,-18.471052)"> - <g - id="g19" - style="fill:#6d6d70;fill-opacity:1"> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path21" - d="M 48.693,50.633 C 40.282,50.633 33.439,57.477 33.439,65.888 L 33.439,81.142 L 41.066,81.142 L 41.066,65.888 C 41.066,61.684 44.486,58.261 48.692,58.261 C 52.897,58.261 56.32,61.684 56.32,65.888 C 56.32,70.093 52.897,73.516 48.692,73.516 C 45.677,73.516 43.065,71.756 41.828,69.211 L 41.828,79.504 C 43.892,80.549 46.224,81.142 48.692,81.142 C 57.103,81.142 63.947,74.3 63.947,65.888 C 63.948,57.477 57.104,50.633 48.693,50.633 z " /> - </g> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path23" - d="M 18.486,50.557 C 26.942,50.557 33.819,57.435 33.819,65.888 C 33.819,74.344 26.942,81.223 18.486,81.223 C 10.032,81.223 3.152,74.344 3.152,65.888 C 3.152,57.435 10.032,50.557 18.486,50.557 z M 18.486,73.556 C 22.713,73.556 26.153,70.118 26.153,65.888 C 26.153,61.661 22.713,58.222 18.486,58.222 C 14.258,58.222 10.819,61.661 10.819,65.888 C 10.82,70.117 14.259,73.556 18.486,73.556 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path25" - d="M 94.074,107.465 L 94.074,96.016 C 94.074,87.605 87.233,80.763 78.822,80.763 C 70.41,80.763 63.567,87.605 63.567,96.016 C 63.567,104.427 70.41,111.269 78.822,111.269 C 81.289,111.269 83.621,110.676 85.685,109.631 L 85.685,99.339 C 84.448,101.885 81.836,103.644 78.822,103.644 C 74.615,103.644 71.194,100.221 71.194,96.016 C 71.194,91.81 74.615,88.388 78.822,88.388 C 83.026,88.388 86.448,91.81 86.448,96.016 L 86.448,107.456 C 86.448,109.562 88.156,111.268 90.262,111.268 C 92.364,111.269 94.068,109.566 94.074,107.465 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path27" - d="M 124.197,95.814 C 124.088,87.496 117.293,80.762 108.949,80.762 C 100.59,80.762 93.783,87.52 93.697,95.856 L 93.693,95.856 L 93.695,107.456 C 93.695,109.562 95.402,111.268 97.509,111.268 C 99.611,111.268 101.316,109.566 101.321,107.464 L 101.321,95.994 L 101.321,95.994 C 101.333,91.798 104.747,88.388 108.948,88.388 C 113.147,88.388 116.563,91.798 116.575,95.994 L 116.575,107.456 C 116.575,109.562 118.282,111.268 120.387,111.268 C 122.492,111.268 124.201,109.562 124.201,107.456 L 124.201,95.814 L 124.197,95.814 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path29" - d="M 63.946,96.005 L 63.946,95.854 L 63.943,95.854 L 63.943,95.815 L 63.942,95.815 C 63.833,87.497 57.037,80.761 48.693,80.761 C 48.682,80.761 48.671,80.763 48.658,80.763 C 48.382,80.763 48.107,80.772 47.833,80.786 C 47.75,80.791 47.668,80.799 47.586,80.806 C 47.378,80.822 47.172,80.838 46.968,80.862 C 46.884,80.873 46.801,80.882 46.719,80.893 C 46.508,80.92 46.298,80.952 46.091,80.987 C 46.024,80.999 45.958,81.01 45.891,81.024 C 45.649,81.068 45.406,81.119 45.168,81.175 C 45.14,81.183 45.112,81.189 45.085,81.195 C 43.656,81.542 42.306,82.092 41.065,82.812 L 41.065,80.761 L 33.438,80.761 L 33.438,95.857 L 33.435,95.857 L 33.435,107.457 C 33.435,109.563 35.142,111.269 37.248,111.269 C 39.093,111.269 40.632,109.958 40.984,108.217 C 41.036,107.963 41.065,107.702 41.065,107.435 L 41.065,95.873 C 41.086,94.732 41.357,93.65 41.828,92.685 L 41.828,92.693 C 42.598,91.106 43.905,89.824 45.511,89.085 C 45.519,89.08 45.529,89.076 45.536,89.073 C 45.849,88.928 46.174,88.807 46.508,88.707 C 46.523,88.704 46.536,88.699 46.55,88.696 C 46.699,88.651 46.85,88.614 47.004,88.576 C 47.025,88.575 47.046,88.567 47.069,88.562 C 47.234,88.527 47.402,88.495 47.572,88.469 C 47.586,88.468 47.6,88.466 47.615,88.463 C 47.763,88.443 47.916,88.427 48.067,88.415 C 48.106,88.41 48.145,88.407 48.186,88.404 C 48.352,88.393 48.52,88.386 48.691,88.386 C 52.888,88.387 56.304,91.797 56.316,95.992 L 56.316,107.454 C 56.316,109.56 58.023,111.266 60.13,111.266 C 61.976,111.266 63.516,109.954 63.867,108.211 C 63.919,107.963 63.946,107.706 63.946,107.442 L 63.946,96.024 C 63.946,96.021 63.947,96.018 63.947,96.015 C 63.948,96.011 63.946,96.008 63.946,96.005 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path31" - d="M 180.644,50.633 C 178.539,50.633 176.832,52.341 176.832,54.447 L 176.832,65.887 C 176.832,70.092 173.41,73.513 169.203,73.513 C 164.998,73.513 161.576,70.092 161.576,65.887 C 161.576,61.683 164.998,58.26 169.203,58.26 C 172.219,58.26 174.83,60.019 176.068,62.565 L 176.068,52.271 C 174.004,51.225 171.673,50.632 169.203,50.632 C 160.793,50.632 153.951,57.476 153.951,65.887 C 153.951,74.298 160.793,81.141 169.203,81.141 C 177.615,81.141 184.459,74.298 184.459,65.887 L 184.459,54.447 C 184.458,52.341 182.751,50.633 180.644,50.633 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path33" - d="M 124.203,77.339 L 124.203,65.687 L 124.197,65.687 C 124.088,57.371 117.293,50.633 108.949,50.633 C 100.592,50.633 93.783,57.393 93.697,65.731 L 93.695,65.731 L 93.695,65.877 C 93.695,65.882 93.693,65.885 93.693,65.888 C 93.693,65.891 93.695,65.896 93.695,65.899 L 93.695,77.33 C 93.695,79.435 95.402,81.142 97.509,81.142 C 99.614,81.142 101.321,79.435 101.321,77.33 L 101.321,65.868 C 101.333,61.672 104.747,58.261 108.948,58.261 C 113.147,58.261 116.563,61.672 116.575,65.868 L 116.575,65.868 L 116.575,77.329 C 116.575,79.434 118.282,81.141 120.389,81.141 C 122.492,81.142 124.197,79.44 124.203,77.339 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path35" - d="M 150.517,80.761 C 148.41,80.761 146.703,82.469 146.703,84.575 L 146.703,96.015 C 146.703,100.22 143.283,103.643 139.076,103.643 C 134.871,103.643 131.449,100.22 131.449,96.015 C 131.449,91.808 134.871,88.387 139.076,88.387 C 142.092,88.387 144.703,90.145 145.941,92.692 L 145.941,82.397 C 143.875,81.353 141.545,80.76 139.076,80.76 C 130.666,80.76 123.822,87.604 123.822,96.015 C 123.822,104.426 130.666,111.268 139.076,111.268 C 147.486,111.268 154.33,104.426 154.33,96.015 L 154.33,84.575 C 154.33,82.469 152.623,80.761 150.517,80.761 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path37" - d="M 82.625,77.345 C 82.625,75.247 80.923,73.547 78.826,73.547 L 78.826,81.142 C 80.922,81.142 82.625,79.442 82.625,77.345 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path39" - d="M 90.252,69.685 C 92.35,69.685 94.048,67.987 94.048,65.888 L 86.453,65.888 C 86.453,67.986 88.154,69.685 90.252,69.685 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path41" - d="M 93.832,77.329 C 93.832,75.223 92.125,73.516 90.018,73.516 L 78.825,73.516 C 74.619,73.516 71.199,70.093 71.199,65.888 C 71.199,61.684 74.619,58.261 78.825,58.261 C 83.032,58.261 86.453,61.684 86.453,65.888 C 86.453,68.904 84.694,71.514 82.149,72.752 L 92.442,72.752 C 93.488,70.689 94.08,68.356 94.08,65.888 C 94.08,57.477 87.237,50.633 78.826,50.633 C 70.415,50.633 63.571,57.477 63.571,65.888 C 63.571,74.3 70.415,81.142 78.826,81.142 L 90.018,81.142 C 92.125,81.142 93.832,79.435 93.832,77.329 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path43" - d="M 142.869,77.345 C 142.869,75.247 141.168,73.547 139.07,73.547 L 139.07,81.142 C 141.167,81.142 142.869,79.442 142.869,77.345 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path45" - d="M 150.496,69.685 C 152.594,69.685 154.293,67.987 154.293,65.888 L 146.699,65.888 C 146.699,67.986 148.398,69.685 150.496,69.685 z " /> - <path - style="fill:#6d6d70;fill-opacity:1" - id="path47" - d="M 154.076,77.329 C 154.076,75.223 152.367,73.516 150.262,73.516 L 139.07,73.516 C 134.865,73.516 131.443,70.093 131.443,65.888 C 131.443,61.684 134.865,58.261 139.07,58.261 C 143.275,58.261 146.699,61.684 146.699,65.888 C 146.699,68.904 144.939,71.514 142.392,72.752 L 152.687,72.752 C 153.73,70.689 154.324,68.356 154.324,65.888 C 154.324,57.477 147.48,50.633 139.07,50.633 C 130.66,50.633 123.816,57.477 123.816,65.888 C 123.816,74.3 130.66,81.142 139.07,81.142 L 150.261,81.142 C 152.367,81.142 154.076,79.435 154.076,77.329 z " /> - </g> - <g - id="g2126" - transform="matrix(0.7679564,0,0,0.7679564,-66.520631,11.42903)" - inkscape:export-xdpi="312.71841" - inkscape:export-ydpi="312.71841" - style="fill:#35992a;fill-opacity:1"> - <g - transform="translate(86.33975,4.23985e-2)" - style="fill:#35992a;fill-opacity:1" - id="g2114"> - <g - style="fill:#35992a;fill-opacity:1" - id="g2116"> - <path - id="path2118" - transform="translate(-86.33975,-4.239934e-2)" - d="M 89.96875,0.03125 C 87.962748,0.031250001 86.34375,1.6815001 86.34375,3.6875 L 86.34375,17.71875 L 86.34375,19.6875 L 86.34375,28.90625 C 86.343752,39.06825 94.61925,47.34375 104.78125,47.34375 L 113.375,47.34375 L 123.1875,47.34375 L 127.15625,47.34375 C 129.16325,47.343749 130.8125,45.72475 130.8125,43.71875 C 130.8125,41.71275 129.16325,40.09375 127.15625,40.09375 L 123.1875,40.09375 L 123.1875,19.6875 L 123.1875,14.65625 L 123.1875,3.6875 C 123.1875,1.6815 121.5675,0.03125 119.5625,0.03125 C 117.5555,0.031250001 115.9375,1.6815001 115.9375,3.6875 L 115.9375,14.28125 C 115.1185,13.65425 114.26275,13.109 113.34375,12.625 L 113.34375,3.6875 C 113.34475,1.6815 111.6925,0.03125 109.6875,0.03125 C 107.6825,0.031250001 106.0625,1.6815001 106.0625,3.6875 L 106.0625,10.5625 C 105.6305,10.5325 105.22025,10.5 104.78125,10.5 C 104.34125,10.5 103.90075,10.5325 103.46875,10.5625 L 103.46875,3.6875 C 103.46975,1.6815 101.84975,0.03125 99.84375,0.03125 C 97.837749,0.031250001 96.21875,1.6815001 96.21875,3.6875 L 96.21875,12.625 C 95.299754,13.109 94.41375,13.65425 93.59375,14.28125 L 93.59375,3.6875 C 93.59475,1.6815 91.97475,0.03125 89.96875,0.03125 z M 104.78125,14.34375 C 112.80825,14.34375 119.3125,20.87925 119.3125,28.90625 C 119.3125,36.93325 112.80825,43.46875 104.78125,43.46875 C 96.754254,43.46875 90.21875,36.93425 90.21875,28.90625 C 90.218752,20.87825 96.753253,14.34375 104.78125,14.34375 z " - style="fill:#35992a;fill-opacity:1" /> - </g> - </g> - <path - style="fill:#35992a;fill-opacity:1" - id="path2122" - d="M 112.04875,28.913399 C 112.04875,24.899399 108.78275,21.634399 104.76975,21.634399 C 100.75675,21.634399 97.490753,24.900399 97.490753,28.913399 C 97.490753,32.926399 100.75675,36.192399 104.76975,36.192399 C 108.78275,36.192399 112.04875,32.927399 112.04875,28.913399 z " /> - </g> - </g> -</svg> diff --git a/documentation/template/poky-db-pdf.xsl b/documentation/template/poky-db-pdf.xsl deleted file mode 100644 index 3dd065a57e..0000000000 --- a/documentation/template/poky-db-pdf.xsl +++ /dev/null @@ -1,64 +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/fo/docbook.xsl" /> - - <!-- check project-plan.sh for how this is generated, needed to tweak - the cover page - --> - <xsl:include href="/tmp/titlepage.xsl"/> - - <!-- To force a page break in document, i.e per section add a - <?hard-pagebreak?> tag. - --> - <xsl:template match="processing-instruction('hard-pagebreak')"> - <fo:block break-before='page' /> - </xsl:template> - - <!--Fix for defualt indent getting TOC all wierd.. - See http://sources.redhat.com/ml/docbook-apps/2005-q1/msg00455.html - FIXME: must be a better fix - --> - <xsl:param name="body.start.indent" select="'0'"/> - <!--<xsl:param name="title.margin.left" select="'0'"/>--> - - <!-- stop long-ish header titles getting wrapped --> - <xsl:param name="header.column.widths">1 10 1</xsl:param> - - <!-- customise headers and footers a little --> - - <xsl:template name="head.sep.rule"> - <xsl:if test="$header.rule != 0"> - <xsl:attribute name="border-bottom-width">0.5pt</xsl:attribute> - <xsl:attribute name="border-bottom-style">solid</xsl:attribute> - <xsl:attribute name="border-bottom-color">#cccccc</xsl:attribute> - </xsl:if> - </xsl:template> - - <xsl:template name="foot.sep.rule"> - <xsl:if test="$footer.rule != 0"> - <xsl:attribute name="border-top-width">0.5pt</xsl:attribute> - <xsl:attribute name="border-top-style">solid</xsl:attribute> - <xsl:attribute name="border-top-color">#cccccc</xsl:attribute> - </xsl:if> - </xsl:template> - - <xsl:attribute-set name="header.content.properties"> - <xsl:attribute name="color">#cccccc</xsl:attribute> - </xsl:attribute-set> - - <xsl:attribute-set name="footer.content.properties"> - <xsl:attribute name="color">#cccccc</xsl:attribute> - </xsl:attribute-set> - - - <!-- general settings --> - - <xsl:param name="fop1.extensions" select="1"></xsl:param> - <xsl:param name="paper.type" select="'A4'"></xsl:param> - <xsl:param name="section.autolabel" select="1"></xsl:param> - <xsl:param name="body.font.family" select="'verasans'"></xsl:param> - <xsl:param name="title.font.family" select="'verasans'"></xsl:param> - <xsl:param name="monospace.font.family" select="'veramono'"></xsl:param> - -</xsl:stylesheet> diff --git a/documentation/template/poky-ref-manual.png b/documentation/template/poky-ref-manual.png Binary files differdeleted file mode 100644 index 2085edb467..0000000000 --- a/documentation/template/poky-ref-manual.png +++ /dev/null diff --git a/documentation/template/poky.svg b/documentation/template/poky.svg deleted file mode 100644 index a4ea5e2f45..0000000000 --- a/documentation/template/poky.svg +++ /dev/null @@ -1,163 +0,0 @@ -<?xml version="1.0" encoding="UTF-8" standalone="no"?> -<!-- Created with Inkscape (http://www.inkscape.org/) --> -<svg - xmlns:svg="http://www.w3.org/2000/svg" - xmlns="http://www.w3.org/2000/svg" - version="1.0" - width="158.56076" - height="79.284424" - viewBox="-40.981 -92.592 300 300" - id="svg2" - xml:space="preserve"> -<defs - id="defs4"> -</defs> -<path - d="M -36.585379,54.412576 L -36.585379,54.421305 L -36.582469,54.421305 L -36.582469,54.243829 C -36.57956,54.302018 -36.585379,54.357297 -36.585379,54.412576 z " - style="fill:#6ac7bd" - id="path6" /> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g8"> - <g - id="g10"> - <path - d="M 24.482,23.998 L 24.482,23.995 C 10.961,23.994 0,34.955 0,48.476 L 0.001,48.479 L 0.001,48.482 C 0.003,62.001 10.962,72.96 24.482,72.96 L 24.482,72.96 L 0,72.96 L 0,97.442 L 0.003,97.442 C 13.523,97.44 24.482,86.48 24.482,72.961 L 24.485,72.961 C 38.005,72.959 48.963,62 48.963,48.479 L 48.963,48.476 C 48.962,34.957 38.001,23.998 24.482,23.998 z M 24.482,50.928 C 23.13,50.928 22.034,49.832 22.034,48.48 C 22.034,47.128 23.13,46.032 24.482,46.032 C 25.834,46.032 26.93,47.128 26.93,48.48 C 26.93,49.832 25.834,50.928 24.482,50.928 z " - style="fill:#ef412a" - id="path12" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g14"> - <g - id="g16"> - <path - d="M 119.96,48.842 C 120.024,47.548 121.086,46.516 122.397,46.516 C 123.707,46.516 124.768,47.548 124.833,48.843 C 137.211,47.62 146.879,37.181 146.879,24.483 L 122.397,24.483 C 122.396,10.961 111.435,0 97.915,0 L 97.915,24.485 C 97.917,37.183 107.584,47.619 119.96,48.842 z M 124.833,49.084 C 124.769,50.379 123.707,51.411 122.397,51.411 L 122.396,51.411 L 122.396,73.444 L 146.878,73.444 L 146.878,73.441 C 146.876,60.745 137.208,50.308 124.833,49.084 z M 119.949,48.963 L 97.915,48.963 L 97.915,73.442 L 97.915,73.442 C 110.613,73.442 121.052,63.774 122.275,51.399 C 120.981,51.334 119.949,50.274 119.949,48.963 z " - style="fill:#a9c542" - id="path18" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g20"> - <g - id="g22"> - <path - d="M 168.912,48.967 C 168.912,47.656 169.945,46.596 171.24,46.531 C 170.018,34.152 159.579,24.482 146.879,24.482 L 146.879,48.963 C 146.879,62.484 157.84,73.444 171.361,73.444 L 171.361,51.414 C 170.007,51.415 168.912,50.319 168.912,48.967 z M 195.841,48.978 C 195.841,48.973 195.842,48.969 195.842,48.964 L 195.842,24.482 L 195.838,24.482 C 183.14,24.484 172.702,34.154 171.482,46.531 C 172.776,46.595 173.808,47.656 173.808,48.967 C 173.808,50.278 172.776,51.339 171.481,51.403 C 172.679,63.59 182.814,73.146 195.244,73.445 L 171.361,73.445 L 171.361,97.927 L 171.364,97.927 C 184.879,97.925 195.834,86.973 195.842,73.46 L 195.844,73.46 L 195.844,48.979 L 195.841,48.978 z M 195.832,48.964 L 195.842,48.964 L 195.842,48.978 L 195.832,48.964 z " - style="fill:#f9c759" - id="path24" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g26"> - <g - id="g28"> - <path - d="M 70.994,48.479 L 48.962,48.479 L 48.962,48.481 L 70.995,48.481 C 70.995,48.481 70.994,48.48 70.994,48.479 z M 73.44,24.001 L 73.437,24.001 L 73.437,46.032 C 73.439,46.032 73.44,46.032 73.442,46.032 C 74.794,46.032 75.89,47.128 75.89,48.48 C 75.89,49.832 74.794,50.928 73.442,50.928 C 72.091,50.928 70.996,49.834 70.994,48.483 L 48.958,48.483 L 48.958,48.486 C 48.96,62.005 59.919,72.964 73.437,72.964 C 86.955,72.964 97.914,62.005 97.916,48.486 L 97.916,48.483 C 97.916,34.963 86.958,24.003 73.44,24.001 z " - style="fill:#6ac7bd" - id="path30" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g32"> - <g - id="g34"> - <path - d="M 24.482,23.998 L 24.482,23.995 C 10.961,23.994 0,34.955 0,48.476 L 22.034,48.476 C 22.036,47.125 23.131,46.031 24.482,46.031 C 25.834,46.031 26.93,47.127 26.93,48.479 C 26.93,49.831 25.834,50.927 24.482,50.927 L 24.482,72.937 C 24.469,59.427 13.514,48.479 0,48.479 L 0,72.96 L 24.481,72.96 L 24.481,72.96 L 0,72.96 L 0,97.442 L 0.003,97.442 C 13.523,97.44 24.482,86.48 24.482,72.961 L 24.485,72.961 C 38.005,72.959 48.963,62 48.963,48.479 L 48.963,48.476 C 48.962,34.957 38.001,23.998 24.482,23.998 z " - style="fill:#ef412a" - id="path36" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g38"> - <g - id="g40"> - <path - d="M 122.397,46.516 C 123.707,46.516 124.768,47.548 124.833,48.843 C 137.211,47.62 146.879,37.181 146.879,24.483 L 122.397,24.483 L 122.397,46.516 L 122.397,46.516 z M 97.915,0 L 97.915,24.482 L 122.396,24.482 C 122.396,10.961 111.435,0 97.915,0 z M 122.275,46.528 C 121.052,34.151 110.613,24.482 97.914,24.482 L 97.914,48.964 L 97.914,48.964 L 97.914,73.443 L 97.914,73.443 C 110.612,73.443 121.051,63.775 122.274,51.4 C 120.98,51.335 119.948,50.275 119.948,48.964 C 119.949,47.653 120.98,46.593 122.275,46.528 z M 124.833,49.084 C 124.769,50.379 123.707,51.411 122.397,51.411 L 122.396,51.411 L 122.396,73.444 L 146.878,73.444 L 146.878,73.441 C 146.876,60.745 137.208,50.308 124.833,49.084 z " - style="fill:#a9c542" - id="path42" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g44"> - <g - id="g46"> - <path - d="M 173.795,49.1 C 173.724,50.389 172.666,51.415 171.36,51.415 C 170.006,51.415 168.911,50.319 168.911,48.967 C 168.911,47.656 169.944,46.596 171.239,46.531 C 170.017,34.152 159.578,24.482 146.878,24.482 L 146.878,48.963 C 146.878,62.484 157.839,73.444 171.36,73.444 L 171.36,97.926 L 171.363,97.926 C 184.878,97.924 195.833,86.972 195.841,73.459 L 195.842,73.459 L 195.842,73.443 L 195.841,73.443 C 195.833,60.753 186.167,50.322 173.795,49.1 z M 195.838,24.482 C 183.14,24.484 172.702,34.154 171.482,46.531 C 172.775,46.595 173.806,47.655 173.808,48.964 L 195.841,48.964 L 195.841,48.979 C 195.841,48.974 195.842,48.969 195.842,48.964 L 195.842,24.482 L 195.838,24.482 z " - style="fill:#f9c759" - id="path48" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g50"> - <g - id="g52"> - <path - d="M 71.007,48.347 C 71.075,47.105 72.062,46.117 73.304,46.046 C 72.509,38.02 67.85,31.133 61.201,27.284 C 57.601,25.2 53.424,24 48.965,24 L 48.962,24 C 48.962,28.46 50.161,32.638 52.245,36.24 C 56.093,42.891 62.98,47.552 71.007,48.347 z M 48.962,48.418 C 48.962,48.438 48.961,48.456 48.961,48.476 L 48.961,48.479 L 48.962,48.479 L 48.962,48.418 z M 70.995,48.482 C 70.995,48.481 70.995,48.481 70.995,48.48 L 48.962,48.48 L 48.962,48.482 L 70.995,48.482 z M 73.44,24.001 L 73.437,24.001 L 73.437,46.032 C 73.439,46.032 73.44,46.032 73.442,46.032 C 74.794,46.032 75.89,47.128 75.89,48.48 C 75.89,49.832 74.794,50.928 73.442,50.928 C 72.091,50.928 70.996,49.834 70.994,48.483 L 48.958,48.483 L 48.958,48.486 C 48.96,62.005 59.919,72.964 73.437,72.964 C 86.955,72.964 97.914,62.005 97.916,48.486 L 97.916,48.483 C 97.916,34.963 86.958,24.003 73.44,24.001 z " - style="fill:#6ac7bd" - id="path54" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g56"> - <g - id="g58"> - <path - d="M 24.482,23.998 L 24.482,23.995 C 10.961,23.994 0,34.955 0,48.476 L 22.034,48.476 C 22.036,47.125 23.131,46.031 24.482,46.031 C 25.834,46.031 26.93,47.127 26.93,48.479 C 26.93,49.831 25.834,50.927 24.482,50.927 C 23.171,50.927 22.11,49.894 22.046,48.6 C 9.669,49.824 0.001,60.262 0.001,72.96 L 0,72.96 L 0,97.442 L 0.003,97.442 C 13.523,97.44 24.482,86.48 24.482,72.961 L 24.485,72.961 C 38.005,72.959 48.963,62 48.963,48.479 L 48.963,48.476 C 48.962,34.957 38.001,23.998 24.482,23.998 z " - style="fill:#ef412a" - id="path60" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g62"> - <g - id="g64"> - <path - d="M 119.949,48.963 C 119.949,47.611 121.045,46.515 122.397,46.515 C 123.707,46.515 124.768,47.547 124.833,48.842 C 137.211,47.619 146.879,37.18 146.879,24.482 L 122.397,24.482 C 122.396,10.961 111.435,0 97.915,0 L 97.915,24.482 L 122.394,24.482 C 108.874,24.484 97.916,35.444 97.916,48.963 L 97.916,48.963 L 97.916,73.442 L 97.916,73.442 C 110.614,73.442 121.053,63.774 122.276,51.399 C 120.981,51.334 119.949,50.274 119.949,48.963 z M 124.833,49.084 C 124.769,50.379 123.707,51.411 122.397,51.411 L 122.396,51.411 L 122.396,73.444 L 146.878,73.444 L 146.878,73.441 C 146.876,60.745 137.208,50.308 124.833,49.084 z " - style="fill:#a9c542" - id="path66" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g68"> - <g - id="g70"> - <path - d="M 195.841,48.979 L 195.835,48.964 L 195.841,48.964 L 195.841,48.979 C 195.841,48.974 195.842,48.969 195.842,48.964 L 195.842,24.482 L 195.838,24.482 C 183.14,24.484 172.702,34.154 171.482,46.531 C 172.776,46.595 173.808,47.656 173.808,48.967 C 173.808,50.319 172.712,51.415 171.361,51.415 C 170.007,51.415 168.912,50.319 168.912,48.967 C 168.912,47.656 169.945,46.596 171.24,46.531 C 170.018,34.152 159.579,24.482 146.879,24.482 L 146.879,48.963 C 146.879,62.484 157.84,73.444 171.361,73.444 L 171.361,97.926 L 171.364,97.926 C 184.883,97.924 195.843,86.963 195.843,73.444 L 171.959,73.444 C 185.203,73.126 195.841,62.299 195.841,48.979 z " - style="fill:#f9c759" - id="path72" /> - </g> -</g> -<g - transform="matrix(2.9094193,0,0,2.9094193,-179.03055,-86.624435)" - style="opacity:0.65" - id="g74"> - <g - id="g76"> - <path - d="M 73.44,24.001 L 73.437,24.001 C 59.919,24.003 48.96,34.959 48.958,48.476 L 48.958,48.479 L 48.961,48.479 L 48.961,48.481 L 48.957,48.482 L 48.957,48.485 C 48.959,62.004 59.918,72.963 73.436,72.963 C 86.954,72.963 97.913,62.004 97.915,48.485 L 97.915,48.482 C 97.916,34.963 86.958,24.003 73.44,24.001 z M 73.442,50.928 C 72.09,50.928 70.994,49.832 70.994,48.48 C 70.994,47.128 72.09,46.032 73.442,46.032 C 74.794,46.032 75.89,47.128 75.89,48.48 C 75.89,49.832 74.794,50.928 73.442,50.928 z " - style="fill:#6ac7bd" - id="path78" /> - </g> -</g> -</svg>
\ No newline at end of file diff --git a/documentation/template/titlepage.templates.xml b/documentation/template/titlepage.templates.xml deleted file mode 100644 index ff640fa5f2..0000000000 --- a/documentation/template/titlepage.templates.xml +++ /dev/null @@ -1,1240 +0,0 @@ -<!DOCTYPE t:templates [ -<!ENTITY hsize0 "10pt"> -<!ENTITY hsize1 "12pt"> -<!ENTITY hsize2 "14.4pt"> -<!ENTITY hsize3 "17.28pt"> -<!ENTITY hsize4 "20.736pt"> -<!ENTITY hsize5 "24.8832pt"> -<!ENTITY hsize0space "7.5pt"> <!-- 0.75 * hsize0 --> -<!ENTITY hsize1space "9pt"> <!-- 0.75 * hsize1 --> -<!ENTITY hsize2space "10.8pt"> <!-- 0.75 * hsize2 --> -<!ENTITY hsize3space "12.96pt"> <!-- 0.75 * hsize3 --> -<!ENTITY hsize4space "15.552pt"> <!-- 0.75 * hsize4 --> -<!ENTITY hsize5space "18.6624pt"> <!-- 0.75 * hsize5 --> -]> -<t:templates xmlns:t="http://nwalsh.com/docbook/xsl/template/1.0" - xmlns:param="http://nwalsh.com/docbook/xsl/template/1.0/param" - xmlns:fo="http://www.w3.org/1999/XSL/Format" - xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> - -<!-- ******************************************************************** - $Id: titlepage.templates.xml,v 1.23 2003/12/16 00:30:49 bobstayton Exp $ - ******************************************************************** - - This file is part of the DocBook XSL Stylesheet distribution. - See ../README or http://docbook.sf.net/ for copyright - and other information. - - ******************************************************************** --> - -<!-- ==================================================================== --> - -<t:titlepage t:element="article" t:wrapper="fo:block" - font-family="{$title.fontset}"> - - <t:titlepage-content t:side="recto" - text-align="center"> - - <mediaobject/> - - <title t:named-template="component.title" - param:node="ancestor-or-self::article[1]" - keep-with-next="always" - font-size="&hsize5;" - font-weight="bold"/> - - <subtitle param:node="ancestor-or-self::article[1]" - keep-with-next="always" - font-size="&hsize3;" - font-weight="bold" - space-after="0.8em"/> - - <corpauthor space-before="0.5em" - font-size="&hsize3;"/> - <authorgroup space-before="0.5em" - font-size="&hsize2;"/> - <author space-before="0.5em" - font-size="&hsize2;" - space-after="0.8em"/> - - <email font-size="&hsize2;"/> - - <othercredit space-before="0.5em"/> - <releaseinfo space-before="0.5em"/> - <copyright space-before="0.5em"/> - <legalnotice text-align="start" - margin-left="0.5in" - margin-right="0.5in" - font-family="{$body.fontset}"/> - <pubdate space-before="0.5em"/> - <para></para> - <revision space-before="0.5em"/> - <revhistory space-before="0.5em"/> - <abstract space-before="0.5em" - text-align="start" - margin-left="0.5in" - margin-right="0.5in" - font-family="{$body.fontset}"/> - - <para></para> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="set" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:named-template="division.title" - param:node="ancestor-or-self::set[1]" - text-align="center" - font-size="&hsize5;" - space-before="&hsize5space;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}" - text-align="center"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="book" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - - <mediaobject/> - - <title - t:named-template="division.title" - param:node="ancestor-or-self::book[1]" - text-align="center" - font-size="&hsize5;" - space-before="&hsize5space;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - text-align="center" - font-size="&hsize4;" - space-before="&hsize4space;" - font-family="{$title.fontset}"/> - <corpauthor font-size="&hsize3;" - keep-with-next="always" - space-before="2in"/> - <authorgroup space-before="2in"/> - <author font-size="&hsize3;" - space-before="&hsize2space;" - keep-with-next="always"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - <title - t:named-template="book.verso.title" - font-size="&hsize2;" - font-weight="bold" - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup t:named-template="verso.authorgroup"/> - <author/> - <othercredit/> - <pubdate space-before="1em"/> - <copyright/> - <abstract/> - <legalnotice font-size="8pt"/> - </t:titlepage-content> - - <t:titlepage-separator> - <fo:block break-after="page"/> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - <fo:block break-after="page"/> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="part" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:named-template="division.title" - param:node="ancestor-or-self::part[1]" - text-align="center" - font-size="&hsize5;" - space-before="&hsize5space;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - text-align="center" - font-size="&hsize4;" - space-before="&hsize4space;" - font-weight='bold' - font-style='italic' - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="partintro" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - text-align="center" - font-size="&hsize5;" - font-weight="bold" - space-before="1em" - font-family="{$title.fontset}"/> - <subtitle - text-align="center" - font-size="&hsize2;" - font-weight="bold" - font-style="italic" - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="reference" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:named-template="division.title" - param:node="ancestor-or-self::reference[1]" - text-align="center" - font-size="&hsize5;" - space-before="&hsize5space;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}" - text-align="center"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsynopsisdiv" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsection" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsect1" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsect2" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="refsect3" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="dedication" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::dedication[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="preface" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::preface[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="chapter" t:wrapper="fo:block" - font-family="{$title.fontset}"> - <t:titlepage-content t:side="recto" margin-left="{$title.margin.left}"> - <title t:named-template="component.title" - param:node="ancestor-or-self::chapter[1]" - font-size="&hsize5;" - font-weight="bold"/> - - <subtitle space-before="0.5em" - font-style="italic" - font-size="&hsize2;" - font-weight="bold"/> - - <corpauthor space-before="0.5em" - space-after="0.5em" - font-size="&hsize2;"/> - - <authorgroup space-before="0.5em" - space-after="0.5em" - font-size="&hsize2;"/> - - <author space-before="0.5em" - space-after="0.5em" - font-size="&hsize2;"/> - - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="appendix" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:named-template="component.title" - param:node="ancestor-or-self::appendix[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-weight="bold" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - -<t:titlepage t:element="section" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect1" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect2" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect3" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect4" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="sect5" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<t:titlepage t:element="simplesect" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - margin-left="{$title.margin.left}" - font-family="{$title.fontset}"/> - <subtitle - font-family="{$title.fontset}"/> - <corpauthor/> - <authorgroup/> - <author/> - <othercredit/> - <releaseinfo/> - <copyright/> - <legalnotice/> - <pubdate/> - <revision/> - <revhistory/> - <abstract/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="bibliography" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::bibliography[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="bibliodiv" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title t:named-template="component.title" - param:node="ancestor-or-self::bibliodiv[1]" - margin-left="{$title.margin.left}" - font-size="&hsize4;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="glossary" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::glossary[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="glossdiv" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title t:named-template="component.title" - param:node="ancestor-or-self::glossdiv[1]" - margin-left="{$title.margin.left}" - font-size="&hsize4;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="index" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::index[1]" - param:pagewide="1" - margin-left="0pt" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <!-- The indexdiv.title template is used so that manual and --> - <!-- automatically generated indexdiv titles get the same --> - <!-- formatting. --> - - <t:titlepage t:element="indexdiv" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title t:force="1" - t:named-template="indexdiv.title" - param:title="title"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="setindex" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::setindex[1]" - param:pagewide="1" - margin-left="0pt" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="colophon" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="component.title" - param:node="ancestor-or-self::colophon[1]" - margin-left="{$title.margin.left}" - font-size="&hsize5;" - font-family="{$title.fontset}" - font-weight="bold"/> - <subtitle - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> -</t:titlepage> - -<!-- ==================================================================== --> - - <t:titlepage t:element="table.of.contents" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'TableofContents'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.tables" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofTables'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.figures" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofFigures'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.examples" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofExamples'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.equations" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofEquations'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.procedures" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofProcedures'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - - <t:titlepage t:element="list.of.unknowns" t:wrapper="fo:block"> - <t:titlepage-content t:side="recto"> - <title - t:force="1" - t:named-template="gentext" - param:key="'ListofUnknown'" - space-before.minimum="1em" - space-before.optimum="1.5em" - space-before.maximum="2em" - space-after="0.5em" - margin-left="{$title.margin.left}" - font-size="&hsize3;" - font-weight="bold" - font-family="{$title.fontset}"/> - </t:titlepage-content> - - <t:titlepage-content t:side="verso"> - </t:titlepage-content> - - <t:titlepage-separator> - </t:titlepage-separator> - - <t:titlepage-before t:side="recto"> - </t:titlepage-before> - - <t:titlepage-before t:side="verso"> - </t:titlepage-before> - </t:titlepage> - -<!-- ==================================================================== --> - -</t:templates> diff --git a/documentation/template/yocto-project-qs.png b/documentation/template/yocto-project-qs.png Binary files differdeleted file mode 100644 index 333442e0d6..0000000000 --- a/documentation/template/yocto-project-qs.png +++ /dev/null diff --git a/documentation/tools/poky-docbook-to-pdf b/documentation/tools/poky-docbook-to-pdf deleted file mode 100755 index f55fd278af..0000000000 --- a/documentation/tools/poky-docbook-to-pdf +++ /dev/null @@ -1,51 +0,0 @@ -#!/bin/sh - -if [ -z "$1" -o -z "$2" ]; then - echo "usage: [-v] $0 <docbook file> <templatedir>" - echo - echo "*NOTE* you need xsltproc, fop and nwalsh docbook stylesheets" - echo " installed for this to work!" - echo - exit 0 -fi - -FO=`echo $1 | sed s/.xml/.fo/` || exit 1 -PDF=`echo $1 | sed s/.xml/.pdf/` || exit 1 -TEMPLATEDIR=$2 - -## -# 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" - -# Creates a temporary XSL stylesheet based on titlepage.xsl -xsltproc -o /tmp/titlepage.xsl \ - --xinclude \ - $XSL_BASE_URI/template/titlepage.xsl \ - $TEMPLATEDIR/titlepage.templates.xml || exit 1 - -# Creates the file needed for FOP -xsltproc --xinclude \ - --stringparam hyphenate false \ - --stringparam formal.title.placement "figure after" \ - --stringparam ulink.show 1 \ - --stringparam body.font.master 9 \ - --stringparam title.font.master 11 \ - --stringparam draft.watermark.image "$TEMPLATEDIR/draft.png" \ - --stringparam chapter.autolabel 1 \ - --stringparam appendix.autolabel A \ - --stringparam section.autolabel 1 \ - --stringparam section.label.includes.component.label 1 \ - --output $FO \ - $TEMPLATEDIR/poky-db-pdf.xsl \ - $1 || exit 1 - -# Invokes the Java version of FOP. Uses the additional configuration file common/fop-config.xml -fop -c $TEMPLATEDIR/fop-config.xml -fo $FO -pdf $PDF || exit 1 - -rm -f $FO -rm -f /tmp/titlepage.xsl - -echo -echo " #### Success! $PDF ready. ####" -echo diff --git a/documentation/yocto-project-qs/Makefile b/documentation/yocto-project-qs/Makefile deleted file mode 100644 index a267edc0c8..0000000000 --- a/documentation/yocto-project-qs/Makefile +++ /dev/null @@ -1,32 +0,0 @@ -XSLTOPTS = --stringparam html.stylesheet style.css \ - --xinclude - -XSL_BASE_URI = http://docbook.sourceforge.net/release/xsl/current -XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl - -all: html tarball - -## -# These URI should be rewritten by your distribution's xml catalog to -# match your localy installed XSL stylesheets. - -html: -# See http://www.sagehill.net/docbookxsl/HtmlOutput.html - -# xsltproc $(XSLTOPTS) -o yocto-project-qs.html $(XSL_XHTML_URI) yocto-project-qs.xml - xsltproc $(XSLTOPTS) -o yocto-project-qs.html yocto-project-qs-customization.xsl yocto-project-qs.xml - -tarball: html - tar -cvzf yocto-project-qs.tgz yocto-project-qs.html ypqs.pdf style.css figures/yocto-environment.png figures/building-an-image.png figures/using-a-pre-built-image.png figures/yocto-project-transp.png - -validate: - xmllint --postvalid --xinclude --noout yocto-project-qs.xml - -OUTPUTS = yocto-project-qs.tgz yocto-project-qs.html ypqs.pdf -SOURCES = *.png *.xml *.css - -publish: - scp -r $(OUTPUTS) $(SOURCES) o-hand.com:/srv/www/pokylinux.org/doc/ - -clean: - rm -f $(OUTPUTS) diff --git a/documentation/yocto-project-qs/figures/building-an-image.png b/documentation/yocto-project-qs/figures/building-an-image.png Binary files differdeleted file mode 100755 index 1fbea5ab00..0000000000 --- a/documentation/yocto-project-qs/figures/building-an-image.png +++ /dev/null diff --git a/documentation/yocto-project-qs/figures/cropped-yocto-project-bw.png b/documentation/yocto-project-qs/figures/cropped-yocto-project-bw.png Binary files differdeleted file mode 100755 index 561333b146..0000000000 --- a/documentation/yocto-project-qs/figures/cropped-yocto-project-bw.png +++ /dev/null diff --git a/documentation/yocto-project-qs/figures/using-a-pre-built-image.png b/documentation/yocto-project-qs/figures/using-a-pre-built-image.png Binary files differdeleted file mode 100644 index b03130d123..0000000000 --- a/documentation/yocto-project-qs/figures/using-a-pre-built-image.png +++ /dev/null diff --git a/documentation/yocto-project-qs/figures/white-on-black.png b/documentation/yocto-project-qs/figures/white-on-black.png Binary files differdeleted file mode 100755 index 075b4f2949..0000000000 --- a/documentation/yocto-project-qs/figures/white-on-black.png +++ /dev/null diff --git a/documentation/yocto-project-qs/figures/yocto-environment.png b/documentation/yocto-project-qs/figures/yocto-environment.png Binary files differdeleted file mode 100755 index 04e6092749..0000000000 --- a/documentation/yocto-project-qs/figures/yocto-environment.png +++ /dev/null diff --git a/documentation/yocto-project-qs/figures/yocto-project-transp.png b/documentation/yocto-project-qs/figures/yocto-project-transp.png Binary files differdeleted file mode 100755 index 31d2b147fd..0000000000 --- a/documentation/yocto-project-qs/figures/yocto-project-transp.png +++ /dev/null diff --git a/documentation/yocto-project-qs/style.css b/documentation/yocto-project-qs/style.css deleted file mode 100644 index 21caf85da4..0000000000 --- a/documentation/yocto-project-qs/style.css +++ /dev/null @@ -1,968 +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/yocto-project-bw.png"); - background-position: top; - margin-top: -256px; - padding-right: 50px; - margin-left: 50px; - text-align: center; - 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{ -} - -/* -Example of how to stick an image as part of the title. - -div.article .titlepage .title -{ - background-image: url("figures/white-on-black.png"); - background-position: center; - background-repeat: repeat-x; -} -*/ - -div.preface .titlepage .title, -div.colophon .title, -div.chapter .titlepage .title, -div.article .titlepage .title -{ -} - -div.section div.section .titlepage .title, -div.sect2 .titlepage .title { - background: none; -} - - -h1.title { - background-color: transparent; - background-image: url("figures/yocto-project-bw.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/yocto-project-qs/yocto-project-qs-customization.xsl b/documentation/yocto-project-qs/yocto-project-qs-customization.xsl deleted file mode 100644 index 8e6ea34dd4..0000000000 --- a/documentation/yocto-project-qs/yocto-project-qs-customization.xsl +++ /dev/null @@ -1,8 +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:param name="generate.toc" select="'article nop'"></xsl:param> - -</xsl:stylesheet> diff --git a/documentation/yocto-project-qs/yocto-project-qs.xml b/documentation/yocto-project-qs/yocto-project-qs.xml deleted file mode 100644 index f011f09860..0000000000 --- a/documentation/yocto-project-qs/yocto-project-qs.xml +++ /dev/null @@ -1,525 +0,0 @@ -<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"> - -<article id='intro'> - <imagedata fileref="figures/yocto-project-transp.png" width="6in" depth="1in" align="right" scale="25" /> - -<section id='fake-title'> - <title>Yocto Project Quick Start</title> - <para>Copyright © 2010-2011 Linux Foundation</para> -</section> - -<section id='welcome'> - <title>Welcome!</title> - <para> - Welcome to the Yocto Project! - The Yocto Project is an open-source collaboration project focused on embedded Linux - developers. - Amongst other things, the Yocto Project uses the Poky build tool to - construct complete Linux images. - </para> - <para> - This short document will give you some basic information about the environment as well - as let you experience it in its simplest form. - After reading this document you will have a basic understanding of what the Yocto Project is - and how to use some of its core components. - This document steps you through a simple example showing you how to build a small image - and run it using the QEMU emulator. - </para> - <para> - For complete information on the Yocto Project, you should check out the - <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>. - You can find the latest builds, breaking news, full development documentation, and a - rich Yocto Project Development Community into which you can tap. - </para> - <para> - Finally, you might find the Frequently Asked Questions (FAQ) for the Yocto Project - at <ulink url='https://wiki.yoctoproject.org/wiki/FAQ'>Yocto Project FAQ</ulink> and - the FAQ appendix located in the - <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'> - Poky Reference Manual</ulink> helpful. - </para> -</section> - -<section id='yp-intro'> - <title>Introducing the Yocto Project Development Environment</title> - <para> - The Yocto Project through the Poky build tool provides an open source development - environment targeting the ARM, MIPS, PowerPC and x86 architectures for a variety of - platforms including x86-64 and emulated ones. - You can use components from the the Yocto Project to design, develop, build, debug, simulate, - and test the complete software stack using Linux, the X Window System, GNOME Mobile-based - application frameworks, and Qt frameworks. - </para> - - <para></para> - <para></para> - - <mediaobject> - <imageobject> - <imagedata fileref="figures/yocto-environment.png" - format="PNG" align='center' scalefit='1' width="100%"/> - </imageobject> - <caption> - <para>The Yocto Project Development Environment</para> - </caption> - </mediaobject> - - <para> - Yocto Project: - </para> - - <itemizedlist> - <listitem> - <para>Provides a recent Linux kernel along with a set of system commands and libraries suitable for the embedded environment.</para> - </listitem> - <listitem> - <para>Makes available system components such as X11, Matchbox, GTK+, Pimlico, Clutter, - GuPNP and Qt (among others) so you can create a richer user interface experience on - devices that use displays or have a GUI. - For devices that don't have a GUI or display you simply would not employ these - components.</para> - </listitem> - <listitem> - <para>Creates a focused and stable core compatible with the OpenEmbedded - project with which you can easily and reliably build and develop.</para> - </listitem> - <listitem> - <para>Fully supports a wide range of hardware and device emulation through the QEMU - Emulator.</para> - </listitem> - </itemizedlist> - - <para> - The Yocto Project can generate images for many kinds of devices. - However, the standard example machines target QEMU full system emulation for x86, ARM, MIPS, - and PPC-based architectures as well as specific hardware such as the Intel Desktop Board - DH55TC. - Because an image developed with the Yocto Project can boot inside a QEMU emulator, the - development environment works nicely as a test platform for developing embedded software. - </para> - - <para> - Another important Yocto Project feature is the Sato reference User Interface. - This optional GNOME mobile-based UI, which is intended for devices with - resolution but restricted size screens, sits neatly on top of a device using the - GNOME Mobile Stack providing a well-defined user experience. - Implemented in its own layer, it makes it clear to developers how they can implement - their own UIs on top of Yocto Linux. - </para> -</section> - -<section id='resources'> - <title>What You Need and How You Get It</title> - - <para> - You need these things to develop in the Yocto Project environment: - </para> - - <itemizedlist> - <listitem> - <para>A host system running a supported Linux distribution (i.e. recent releases of - Fedora, OpenSUSE, Debian, and Ubuntu). - <note> - For notes about using the Yocto Project on development systems that use - older Linux distributions see - <ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'></ulink> - </note></para> - </listitem> - <listitem> - <para>The right packages.</para> - </listitem> - <listitem> - <para>A release of Yocto Project.</para> - </listitem> - </itemizedlist> - - <section id='the-linux-distro'> - <title>The Linux Distribution</title> - - <para> - This document assumes you are running a reasonably current Linux-based host system. - The examples work for both Debian-based and RPM-based distributions. - </para> - </section> - - <section id='packages'> - <title>The Packages</title> - - <para> - The packages you need for a Debian-based host are shown in the following command: - </para> - - <literallayout class='monospaced'> - $ sudo apt-get install sed wget cvs subversion git-core coreutils \ - unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \ - python-pysqlite2 diffstat help2man make gcc build-essential \ - g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \ - mercurial autoconf automake groff - </literallayout> - - <para> - The packages you need for an RPM-based host like Fedora are shown in these commands: - </para> - - <literallayout class='monospaced'> - $ sudo yum groupinstall "development tools" - $ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \ - unzip python-psyco perl texinfo texi2html diffstat openjade \ - docbook-style-dsssl sed docbook-style-xsl docbook-dtds \ - docbook-utils sed bc glibc-devel ccache pcre pcre-devel quilt \ - groff linuxdoc-tools patch linuxdoc-tools cmake help2man \ - perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \ - SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \ - autoconf automake - </literallayout> - - <note><para> - Packages vary in number and name for other Linux distributions. - The commands here should work. We are interested, though, to learn what works for you. - You can find more information for package requirements on common Linux distributions - at <ulink url="http://wiki.openembedded.net/index.php/OEandYourDistro"></ulink>. - However, you should be careful when using this information as the information applies - to old Linux distributions that are known to not work with a current Poky install. - </para></note> - </section> - - <section id='releases'> - <title>Yocto Project Release</title> - - <para> - The latest release images for the Yocto Project are kept at - <ulink url="http://yoctoproject.org/downloads/yocto-1.0/"></ulink>. - Nightly and developmental builds are also maintained. However, for this - document a released version of Yocto Project is used. - </para> - </section> -</section> - -<section id='test-run'> - <title>A Quick Test Run</title> - - <para> - Now that you have your system requirements in order you can give Yocto Project a try. - This section presents some steps that let you do the following: - </para> - - <itemizedlist> - <listitem> - <para>Build an image and run it in the emulator</para> - </listitem> - <listitem> - <para>Or, use a pre-built image and run it in the emulator</para> - </listitem> - </itemizedlist> - - <section id='building-image'> - <title>Building an Image</title> - - <para> - In the development environment you will need to build an image whenever you change hardware support, add or change system libraries, or add or change services that have dependencies. - </para> - - <mediaobject> - <imageobject> - <imagedata fileref="figures/building-an-image.png" format="PNG" align='center' scalefit='1'/> - </imageobject> - <caption> - <para>Building an Image</para> - </caption> - </mediaobject> - - <para> - Use the following commands to build your image. - The build process creates an entire Linux distribution, including the toolchain, from source. - </para> - - <note><para> - The build process using Sato currently consumes - about 50GB of disk space. - To allow for variations in the build process and for future package expansion, we - recommend having at least 100GB of free disk space. - </para></note> - - <note><para> - By default, Poky searches for source code using a pre-determined order - through a set of locations. - If you encounter problems with Poky finding and downloading source code, see - the FAQ entry "How does Poky obtain source code and will it work behind my - firewall or proxy server?" in the - <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'> - Poky Reference Manual</ulink>. - </para></note> - - <para> - <literallayout class='monospaced'> - $ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.tar.bz2 - $ tar xjf poky-bernard-5.0.tar.bz2 - $ source poky-bernard-5.0/poky-init-build-env poky-5.0-build - </literallayout> - </para> - - <tip><para> - To help conserve disk space during builds you can add the following statement - to your <filename>local.conf</filename> file. - Adding this statement deletes the work directory used for building a package - once the package is built. - <literallayout class='monospaced'> - INHERIT += rm_work - </literallayout> - </para></tip> - - <itemizedlist> - <listitem><para>The first two commands extract the Yocto Project files from the - release tarball and place them into a subdirectory of your current directory.</para></listitem> - <listitem><para>The <command>source</command> command creates the - <filename>poky-5.0-build</filename> directory and executes the <command>cd</command> - command to make <filename>poky-5.0-build</filename> the working directory. - The resulting build directory contains all the files created during the build. - By default the target architecture is qemux86. - To change this default, edit the value of the MACHINE variable in the - <filename>conf/local.conf</filename> file.</para></listitem> - </itemizedlist> - <para> - Take some time to examine your <filename>conf/local.conf</filename> file. - The defaults should work fine. - However, if you have a multi-core CPU you might want to set the variables - BB_NUMBER_THREADS and PARALLEL_MAKE to the number of processor cores on your build machine. - By default, these variables are commented out. - </para> - <para> - Continue with the following command to build an OS image for the target, which is - <filename>poky-image-sato</filename> in this example. - <literallayout class='monospaced'> - $ bitbake poky-image-sato - </literallayout> - <note><para> - BitBake requires Python 2.6. For more information on this requirement, - see the FAQ appendix in the - <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'> - Poky Reference Manual</ulink>. - </para></note> - The final command runs the image: - <literallayout class='monospaced'> - $ poky-qemu qemux86 - </literallayout> - <note><para> - Depending on the number of processors and cores, the amount or RAM, the speed of your - Internet connection and other factors, the build process could take several hours the first - time you run it. - Subsequent builds run much faster since parts of the build are cached. - </para></note> - </para> - </section> - - <section id='using-pre-built'> - <title>Using Pre-Built Binaries and QEMU</title> - <para> - If hardware, libraries and services are stable you can get started by using a pre-built binary - of the image, kernel and toolchain and run it using the emulator QEMU. - This scenario is useful for developing application software. - </para> - - <para></para> - <para></para> - <para></para> - - <mediaobject> - <imageobject> - <imagedata fileref="figures/using-a-pre-built-image.png" format="PNG" align='center' scalefit='1'/> - </imageobject> - <caption> - <para>Using a Pre-Built Image</para> - </caption> - </mediaobject> - - <para> - For this scenario you need to do several things: - </para> - - <itemizedlist> - <listitem> - <para> - Install the stand-alone Yocto toolchain tarball. - </para> - </listitem> - <listitem> - <para> - Download the pre-built kernel that will boot with QEMU. - You need to be sure to get the QEMU image that matches your target machine’s - architecture (e.g. x86, ARM, etc.). - </para> - </listitem> - <listitem> - <para> - Download the filesystem image for your target machine's architecture. - </para> - </listitem> - <listitem> - <para> - Set up the environment to emulate the hardware and then start the QEMU emulator. - </para> - </listitem> - - </itemizedlist> - - <section id='installing-the-toolchain'> - <title>Installing the Toolchain</title> - <para> - You can download the pre-built toolchain, which includes the poky-qemu script and - support files, from - <ulink url='http://yoctoproject.org/downloads/yocto-1.0/toolchain/'></ulink>. - Toolchains are available for 32-bit and 64-bit development systems from the - <filename>i686</filename> and <filename>x86_64</filename> folders, respectively. - Each type of development system supports five target architectures. - The tarball files are named such that a string representing the host system appears - first in the filename and then is immediately followed by a string representing - the target architecture. - </para> - - <literallayout class='monospaced'> - yocto-eglibc<<emphasis>host_system</emphasis>>-<<emphasis>arch</emphasis>>-toolchain-sdk-<<emphasis>release</emphasis>>.tar.bz2 - - Where: - <<emphasis>host_system</emphasis>> is a string representing your development system: - i686 or x86_64. - - <<emphasis>arch</emphasis>> is a string representing the target architecture: - i686, x86_64, powerpc, mips, or arm. - - <<emphasis>release</emphasis>> is the version of Yocto Project. - </literallayout> - - <para> - For example, the following toolchain tarball is for a 64-bit development - host system and a 32-bit target architecture: - </para> - - <literallayout class='monospaced'> - yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2 - </literallayout> - - <para> - The toolchain tarballs are self-contained and should be installed into <filename>/opt/poky</filename>. - The following commands show how you install the toolchain tarball given a 64-bit development host system - and a 32-bit target architecture. - </para> - - <para> - <literallayout class='monospaced'> - $ cd / - $ sudo tar -xvjf yocto-eglibc-x86_64-i686-toolchain-sdk-1.0.tar.bz2 - </literallayout> - </para> - </section> - - <section id='downloading-the-pre-built-linux-kernel'> - <title>Downloading the Pre-Built Linux Kernel</title> - <para> - You can download the pre-built Linux kernel and the filesystem image suitable for - running in the emulator QEMU from - <ulink url='http://yoctoproject.org/downloads/yocto-1.0/machines/qemu'></ulink>. - Be sure to use the kernel and filesystem image that matches the architecture you want - to simulate. - </para> - - <para> - Most kernel files have the following form: - </para> - - <literallayout class='monospaced'> - *zImage*qemu<<emphasis>arch</emphasis>>*.bin - - Where: - <<emphasis>arch</emphasis>> is a string representing the target architecture: - x86, x86-64, ppc, mips, or arm. - </literallayout> - </section> - - <section id='downloading-the-filesystem'> - <title>Downloading the Filesystem</title> - <para> - The filesystem image has two forms. - One form is an <filename>ext3</filename> filesystem image. - The other form is a tarball of the filesystem and is booted using user-space NFS. - Here are the respective forms: - </para> - - <literallayout class='monospaced'> - yocto-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>.rootfs.ext3 - yocto-image-<<emphasis>profile</emphasis>>-qemu<<emphasis>arch</emphasis>>.rootfs.tar.bz2 - - Where: - <<emphasis>profile</emphasis>> is the filesystem image's profile: - sdk, sato, minimal, or lsb. - - <<emphasis>arch</emphasis>> is a string representing the target architecture: - x86, x86-64, ppc, mips, or arm. - </literallayout> - </section> - - <section id='setting-up-the-environment-and-starting-the-qemu-emulator'> - <title>Setting Up the Environment and Starting the QEMU Emulator</title> - <para> - Before you start the QEMU emulator you need to set up the emulation environment. - The following command form sets up the emulation environment. - </para> - - <literallayout class='monospaced'> - $ source /opt/poky/environment-setup-<<emphasis>arch</emphasis>>-poky-linux-<<emphasis>if</emphasis>> - - Where: - <<emphasis>arch</emphasis>> is a string representing the target architecture: - i686, x86_64, ppc603e, mips, or armv5te. - - <<emphasis>if</emphasis>> is a string representing an embedded application binary interface. - Not all setup scripts include this string. - </literallayout> - - <para> - Finally, this command form invokes the QEMU emulator - </para> - - <literallayout class='monospaced'> - $ poky-qemu <<emphasis>qemuarch</emphasis>> <<emphasis>kernel</emphasis>> <<emphasis>filesystem_image</emphasis>> - - Where: - <<emphasis>qemuarch</emphasis>> is a string representing the target architecture: qemux86, qemux86-64, - qemuppc, qemumips, or qemuarm. - - <<emphasis>kernel</emphasis>> is the architecture-specific kernel. - - <<emphasis>filesystem_image</emphasis>> is the .ext3 filesystem image. - - </literallayout> - - <para> - Continuing with the example, the following two commands setup the emulation - environment and launch QEMU. - The kernel and filesystem are for a 32-bit target architecture. - </para> - - <literallayout class='monospaced'> - $ source /opt/poky/environment-setup-i686-poky-linux - $ poky-qemu qemux86 zImage-2.6.34-qemux86-1.0.bin yocto-image-sdk-qemux86-1.0.rootfs.ext3 - </literallayout> - - <para> - The environment in which QEMU launches varies depending on the filesystem image and on the - target architecture. For example, if you source the environment for the ARM target - architecture and then boot the minimal QEMU image, the emulator comes up in a new - shell in command-line mode. However, if you boot the SDK image QEMU comes up with - a GUI. - </para> - - <note><para> - Booting the PPC image results in QEMU launching in the same shell in command-line mode. - </para></note> - </section> - </section> -</section> - -</article> -<!-- -vim: expandtab tw=80 ts=4 ---> |
