diff options
Diffstat (limited to 'documentation')
| -rw-r--r-- | documentation/poky-ref-manual/development.xml | 21 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/faq.xml | 55 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/introduction.xml | 24 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/ref-bitbake.xml | 15 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/ref-classes.xml | 33 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/ref-features.xml | 2 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/ref-images.xml | 6 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/ref-structure.xml | 61 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/ref-variables.xml | 109 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/resources.xml | 15 | ||||
| -rw-r--r-- | documentation/poky-ref-manual/usingpoky.xml | 27 |
11 files changed, 200 insertions, 168 deletions
diff --git a/documentation/poky-ref-manual/development.xml b/documentation/poky-ref-manual/development.xml index b897efd550..9628fcbd15 100644 --- a/documentation/poky-ref-manual/development.xml +++ b/documentation/poky-ref-manual/development.xml @@ -10,7 +10,7 @@ <para> The Yocto Project supports several methods of application development through which you can create user-space software designed to run on an embedded device that uses - a Linux Yocto image developed with the Yocto Project. + a Yocto Project image, which was developed with the OpenEmbedded build system. This flexibility allows you to choose the method that works best for you. This chapter describes each development method. </para> @@ -25,12 +25,12 @@ section in that when you invoke <filename>devshell</filename> source files are extracted into your working directory and patches are applied. Then, a new terminal is opened and you are placed in the working directory. - In the new terminal all the Yocto Project build-related environment variables are + In the new terminal, all the OpenEmbedded build-related environment variables are still defined so you can use commands such as <filename>configure</filename> and <filename>make</filename>. - The commands execute just as if the Yocto Project build system were executing them. + The commands execute just as if the OpenEmbedded build system were executing them. Consequently, working this way can be helpful when debugging a build or preparing - software to be used with the Yocto Project build system. + software to be used with the OpenEmbedded build system. </para> <para> @@ -45,7 +45,7 @@ </para> <para> - This command opens a terminal with a shell prompt within the Poky + This command opens a terminal with a shell prompt within the Yocto Project environment. The following occurs: <itemizedlist> @@ -58,7 +58,7 @@ </itemizedlist> Within this environment, you can run <filename>configure</filename> or <filename>compile</filename> commands as if they were being run by - the Yocto Project build system itself. + the OpenEmbedded build system itself. As noted earlier, the working directory also automatically changes to the source directory (<filename><link linkend='var-S'>S</link></filename>). </para> @@ -71,8 +71,8 @@ The default shell used by <filename>devshell</filename> is xterm. For examples of available options, see the "UI/Interaction Configuration" section of the - <filename>meta/conf/bitbake.conf</filename> configuration file in the Yocto Project - files. + <filename>meta/conf/bitbake.conf</filename> configuration file in the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. </para> <para> @@ -99,7 +99,7 @@ <para> If you're working on a recipe that pulls from an external Source Code Manager (SCM), it - is possible to have the Yocto Project build system notice new changes added to the + is possible to have the OpenEmbedded build system notice new changes added to the SCM and then build the package that depends on them using the latest version. This only works for SCMs from which it is possible to get a sensible revision number for changes. Currently, you can do this with Apache Subversion (SVN), Git, and Bazaar (BZR) repositories. @@ -107,7 +107,8 @@ <para> To enable this behavior, simply add the following to the <filename>local.conf</filename> - configuration file in the build directory of the Yocto Project files: + configuration file found in the + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>: <literallayout class='monospaced'> SRCREV_pn-<PN> = "${AUTOREV}" </literallayout> diff --git a/documentation/poky-ref-manual/faq.xml b/documentation/poky-ref-manual/faq.xml index 6b56c5abb9..7c2fc11818 100644 --- a/documentation/poky-ref-manual/faq.xml +++ b/documentation/poky-ref-manual/faq.xml @@ -13,11 +13,17 @@ </question> <answer> <para> - Poky is the Yocto Project build system that was derived from <ulink + The term "Poky" is sometimes used to refer to the build system that the + Yocto Project uses. + The build system used in the Yocto project is referred to as the + OpenEmbedded build system because "Poky" was derived from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>. Poky is a stable, smaller subset focused on the mobile environment. Development in the Yocto Project using Poky is closely tied to OpenEmbedded with features being merged regularly between the two for mutual benefit. + For a fuller description of the term "Poky", see the + <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>poky</ulink> term in the Yocto Project + Development Manual. </para> </answer> </qandaentry> @@ -64,7 +70,8 @@ <para> There are three areas that help with stability; <itemizedlist> - <listitem><para>The Yocto Project team keeps Poky small and focused. + <listitem><para>The Yocto Project team keeps + <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> small and focused. It contains around 650 packages as compared to over 5000 for full OpenEmbedded.</para></listitem> <listitem><para>The Yocto Project only supports hardware that the @@ -100,16 +107,17 @@ <qandaentry> <question> <para> - Are there any products using Poky? + Are there any products using the OpenEmbedded build system (poky)? </para> </question> <answer> <para> The <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink> is using - the Yocto Project build system Poky. + the OpenEmbedded build system. See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink> for more information. - There are a number of pre-production devices using Poky and the Yocto Project team + There are a number of pre-production devices using the OpenEmbedded build system + and the Yocto Project team announces them as soon as they are released. </para> </answer> @@ -118,13 +126,13 @@ <qandaentry> <question> <para> - What does the Yocto Project build system Poky produce as output? + What does the OpenEmbedded build system produce as output? </para> </question> <answer> <para> Because the same set of recipes can be used to create output of various formats, the - output of a Yocto Project build depends on how it was started. + output of an OpenEmbedded build depends on how it was started. Usually, the output is a flashable image ready for the target device. </para> </answer> @@ -155,7 +163,7 @@ </question> <answer> <para> - The Yocto Project can build packages in various formats such as + The OpenEmbedded build system can build packages in various formats such as <filename>ipk</filename> for <filename>ipkg</filename>/<filename>opkg</filename>, Debian package (<filename>.deb</filename>), or RPM. The packages can then be upgraded using the package tools on the device, much like @@ -223,8 +231,8 @@ </para> <para> - Once these packages are installed, the Yocto Project will be able to build standard - images. + Once these packages are installed, the OpenEmbedded build system will be able + to build standard images. However, there might be a problem with the QEMU emulator segfaulting. You can either disable the generation of binary locales by setting <filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link> @@ -244,14 +252,14 @@ <answer> <para> Nothing is wrong. - The Yocto Project checks any configured source mirrors before downloading + The OpenEmbedded build system checks any configured source mirrors before downloading from the upstream sources. - The Yocto Project does this searching for both source archives and + The build system does this searching for both source archives and pre-checked out versions of SCM managed software. These checks help in large installations because it can reduce load on the SCM servers themselves. The address above is one of the default mirrors configured into the - Yocto Project. + build system. Consequently, if an upstream source disappears, the team can place sources there so builds continue to work. </para> @@ -284,7 +292,7 @@ </question> <answer> <para> - Most source fetching by the Yocto Project is done by <filename>wget</filename> + Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename> and you therefore need to specify the proxy settings in a <filename>.wgetrc</filename> file in your home directory. Example settings in that file would be @@ -350,7 +358,7 @@ the most likely explanation is that either the hardware you're running the build on has some problem, or, if you are running the build under virtualisation, the virtualisation probably has bugs. - The Yocto Project processes a massive amount of data causing lots of network, disk and + The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and CPU activity and is sensitive to even single bit failures in any of these areas. True random failures have always been traced back to hardware or virtualisation issues. </para> @@ -449,7 +457,7 @@ <answer> <para> The Yocto Project team has tried to do this before but too many of the tools - the Yocto Project depends on such as <filename>autoconf</filename> + the OpenEmbedded build system depends on such as <filename>autoconf</filename> break when they find spaces in pathnames. Until that situation changes, the team will not support spaces in pathnames. </para> @@ -495,14 +503,14 @@ <qandaentry> <question> <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'> - How does the Yocto Project build system obtain source code and will it work behind my + How does the OpenEmbedded build system obtain source code and will it work behind my firewall or proxy server? </para> </question> <answer> <para> - The way the Yocto Project obtains source code is highly configurable. - You can setup the Yocto Project to get source code in most environments if + The way the build system obtains source code is highly configurable. + You can setup the build system to get source code in most environments if HTTP transport is available. </para> <para> @@ -511,7 +519,8 @@ and then MIRRORS in that order. </para> <para> - By default, Poky uses the Yocto Project source PREMIRRORS for SCM-based sources, + By default, the OpenEmbedded build system 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> @@ -574,7 +583,7 @@ any network accesses to anything other than the PREMIRROR would fail. </para> <para> - Poky also honors the standard shell environment variables + The build system also honors the standard shell 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. @@ -600,8 +609,8 @@ </para> <para> - Within the Yocto Project Build Directory is the <filename>tmp</filename> - directory. + Within the <ulink url='&YOCTO_DOCS_DEV_URL;buile-directory'>build directory</ulink> + is the <filename>tmp</filename> directory. To remove all the build output yet preserve any source code or downloaded files from previous builds, simply remove the <filename>tmp</filename> directory. </para> diff --git a/documentation/poky-ref-manual/introduction.xml b/documentation/poky-ref-manual/introduction.xml index 160cdca73d..249b9a18fd 100644 --- a/documentation/poky-ref-manual/introduction.xml +++ b/documentation/poky-ref-manual/introduction.xml @@ -12,8 +12,8 @@ This manual provides reference information for the current release of 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. + Amongst other things, the Yocto Project uses the OpenEmbedded build system, which + is based on the Poky project, to construct complete Linux images. You can find complete introductory and getting started information on the Yocto Project by reading the <ulink url='&YOCTO_DOCS_QS_URL;'> @@ -51,9 +51,13 @@ the Yocto Project.</para></listitem> <listitem><para><emphasis> <link linkend='ref-structure'>Reference: Directory Structure</link>:</emphasis> - This appendix describes the directory structure of the Yocto Project files. - The Yocto Project files represent the file structure or Git repository created - as a result of setting up the Yocto Project on your host development system. + This appendix describes the directory structure of the + Yocto Project files, referred to as the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. + The source directory represents the local file structure created + as a result from either cloning the upstream + <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository or unpacking a + released Yocto Project tarball on your host development system. </para></listitem> <listitem><para><emphasis> <link linkend='ref-bitbake'>Reference: BitBake</link>:</emphasis> @@ -69,7 +73,7 @@ <listitem><para><emphasis> <link linkend='ref-features'>Reference: Features</link>:</emphasis> This appendix describes mechanisms for creating distribution, machine, and image - features during the build process using the Yocto Project.</para></listitem> + features during the build process using the OpenEmbedded build system.</para></listitem> <listitem><para><emphasis> <link linkend='ref-variables-glos'>Reference: Variables Glossary</link>:</emphasis> This appendix presents most Yocto Project variables. @@ -124,9 +128,11 @@ <section id='intro-getit-dev'> <title>Development Checkouts</title> <para> - Development using the Yocto Project requires a local copy of the Yocto Project files. - You can get these files by downloading a Yocto Project release tarball and unpacking it, - or by establishing a Git repository of the files. + Development using the Yocto Project requires a local copy of the Yocto Project files + referred to as the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. + You can set source directory up by downloading a Yocto Project release tarball and unpacking it, + or by cloning a copy of the upstream + <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository. For information on both these methods, see the "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Setup</ulink>" section in The Yocto Project Development Manual. diff --git a/documentation/poky-ref-manual/ref-bitbake.xml b/documentation/poky-ref-manual/ref-bitbake.xml index 523caf7090..81a8934e6a 100644 --- a/documentation/poky-ref-manual/ref-bitbake.xml +++ b/documentation/poky-ref-manual/ref-bitbake.xml @@ -7,7 +7,8 @@ <title>Reference: BitBake</title> <para> - BitBake is a program written in Python that interprets the metadata that makes up the Yocto Project. + BitBake is a program written in Python that interprets the metadata used by the Yocto Project. + The OpenEmbedded build system uses BitBake. At some point, developers wonder what actually happens when you enter: <literallayout class='monospaced'> $ bitbake core-image-sato @@ -34,20 +35,22 @@ <para> The first thing BitBake does is look for the <filename>bitbake.conf</filename> file. - The Yocto Project keeps this file in the Yocto Project file's <filename>meta/conf/</filename> - directory. - BitBake finds it by examining its <filename>BBPATH</filename> environment + This file resides in the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> + within the <filename>meta/conf/</filename> directory. + BitBake finds it by examining its + <link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment variable and looking for the <filename>meta/conf/</filename> directory. </para> <para> - In the Yocto Project, <filename>bitbake.conf</filename> lists other configuration + The <filename>bitbake.conf</filename> file 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 the Yocto Project build environment. + settings for the OpenEmbedded build environment. Other notable configuration files are the distribution configuration file (set by the <filename><link linkend='var-DISTRO'>DISTRO</link></filename> variable) diff --git a/documentation/poky-ref-manual/ref-classes.xml b/documentation/poky-ref-manual/ref-classes.xml index 35c713434c..67f2454145 100644 --- a/documentation/poky-ref-manual/ref-classes.xml +++ b/documentation/poky-ref-manual/ref-classes.xml @@ -12,10 +12,11 @@ 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 found in the Yocto Project file's area + <filename>meta*/</filename> directory found in the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. Class files can also be pointed to by BUILDDIR (e.g. <filename>build/</filename>)in the same way as <filename>.conf</filename> files in the <filename>conf</filename> directory. - Class files are searched for in <filename>BBPATH</filename> + Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link> using the same method by which <filename>.conf</filename> files are searched. </para> @@ -111,7 +112,7 @@ </para> <para> - Currently, the Yocto Project supports only one binary per package. + Currently, the OpenEmbedded build system supports only one binary per package. </para> </section> @@ -121,7 +122,7 @@ <para> This class uses <filename>update-rc.d</filename> to safely install an initialization script on behalf of the package. - The Yocto Project takes care of details such as making sure the script is stopped before + The OpenEmbedded build system takes care of details such as making sure the script is stopped before a package is removed and started when the package is installed. Three variables control this class: <filename><link linkend='var-INITSCRIPT_PACKAGES'>INITSCRIPT_PACKAGES</link></filename>, @@ -254,7 +255,7 @@ <para> This class adds the <filename>devshell</filename> task. - Distribution policy dictates whether to include this class as the Yocto Project does. + Distribution policy dictates whether to include this class. See the "<link linkend='platdev-appdev-devshell'>Development Within a Development Shell</link>" section for more information about using devshell. @@ -277,8 +278,9 @@ <para> You can control the list of resulting package formats by using the <filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></filename> - variable defined in the <filename>local.conf</filename> configuration file - found in the Yocto Project file's <filename>conf</filename> directory. + variable defined in the <filename>local.conf</filename> configuration file, + which is located in the <filename>conf</filename> folder of the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. When defining the variable, you can specify one or more package types. Since images are generated from packages, a packaging class is needed to enable image generation. @@ -380,7 +382,7 @@ The class also performs basic user configuration checks from the <filename>local.conf</filename> configuration file to prevent common mistakes that cause build failures. - Distribution policy usually whether to include this class as the Yocto Project does. + Distribution policy usually determines whether to include this class. </para> </section> @@ -389,10 +391,10 @@ <para> This class adds a step to the package generation process that sanity checks the - packages generated by the Yocto Project. + packages generated by the OpenEmbedded build system. A range of checks are performed that check the build's output for common problems that show up during runtime. - Distribution policy usually dictates whether to include this class as the Yocto Project does. + Distribution policy usually dictates whether to include this class. </para> <para> @@ -514,7 +516,8 @@ you can use this class to specify those packages and associate the users and groups with those packages. The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename> - recipe in the Yocto Project Files provides a simple exmample that shows how to add three + recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> + provides a simple exmample that shows how to add three users and groups to two packages. See the <filename>useradd-example.bb</filename> for more information on how to use this class. @@ -526,7 +529,7 @@ <para> You can use this class to build software from source code that is external to the - Yocto Project build system. + OpenEmbedded build system. In other words, your source code resides in an external tree outside of the Yocto Project. Building software from an external source tree means that the normal fetch, unpack, and patch process is not used. @@ -541,7 +544,7 @@ <para> This class expects the source code to support recipe builds that use the <link linkend='var-B'><filename>B</filename></link> variable to point to the directory in - which the Yocto Project build system places the generated objects built from the recipes. + which the OpenEmbedded build system places the generated objects built from the recipes. By default, the <filename>B</filename> directory is set to the following, which is separate from the source directory (<filename>S</filename>): <literallayout class='monospaced'> @@ -570,7 +573,7 @@ When you do, the <link linkend='var-B'><filename>B</filename></link> variable must support the recipe's ability to build variants in different working directories. Most autotools-based recipes support separating these directories. - The Yocto Project defaults to using separate directories for <filename>gcc</filename> + The OpenEmbedded build system defaults to using separate directories for <filename>gcc</filename> and some kernel recipes. Alternatively, you can make sure that separate recipes exist that each use the <filename>BBCLASSEXTEND</filename> variable to build each variant. @@ -591,7 +594,7 @@ Thus far, this appendix has discussed only the most useful and important classes. However, other classes exist within the <filename>meta/classes</filename> directory - in the Yocto Project file's directory structure. + in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. You can examine the <filename>.bbclass</filename> files directly for more information. </para> diff --git a/documentation/poky-ref-manual/ref-features.xml b/documentation/poky-ref-manual/ref-features.xml index c61b985f8a..58db94e295 100644 --- a/documentation/poky-ref-manual/ref-features.xml +++ b/documentation/poky-ref-manual/ref-features.xml @@ -115,7 +115,7 @@ <title>Reference: Images</title> <para> - The contents of images generated by the Yocto Project can be controlled by the + The contents of images generated by the OpenEmbedded build system can be controlled by the <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename> and <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variables that you typically configure in your image recipes. diff --git a/documentation/poky-ref-manual/ref-images.xml b/documentation/poky-ref-manual/ref-images.xml index a4cd926d0d..0ffea5d19f 100644 --- a/documentation/poky-ref-manual/ref-images.xml +++ b/documentation/poky-ref-manual/ref-images.xml @@ -6,7 +6,7 @@ <title>Reference: Images</title> <para> - The Yocto Project build process supports several types of images to satisfy different needs. + The OpenEmbedded build process supports several types of images to satisfy different needs. When you issue the <filename>bitbake</filename> command you provide a “top-level” recipe that essentially begins the build for the type of image you want. </para> @@ -32,8 +32,8 @@ These recipes reside in the <filename>meta/recipes-core/images</filename>, <filename>meta/recipes-extended/images</filename>, <filename>meta/recipes-graphics/images</filename>, and - <filename>meta/recipes-sato/images</filename> directories of your local Yocto Project - file structure (Git repository or extracted release tarball). + <filename>meta/recipes-sato/images</filename> directories + within the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. Although the recipe names are somewhat explanatory, here is a list that describes them: </para> diff --git a/documentation/poky-ref-manual/ref-structure.xml b/documentation/poky-ref-manual/ref-structure.xml index a5bfe5e876..c950671cb0 100644 --- a/documentation/poky-ref-manual/ref-structure.xml +++ b/documentation/poky-ref-manual/ref-structure.xml @@ -9,12 +9,12 @@ <para> The Yocto Project consists of several components. Understanding them and knowing where they are located is key to using the Yocto Project well. - This appendix describes the Yocto Project file's directory structure and gives information about the various - files and directories. + This appendix describes the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> + and gives information about the various files and directories. </para> <para> - For information on how to establish the Yocto Project files on your local development system, see the + For information on how to establish a local source directory on your development system, see the "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>" section in the Yocto Project Development Manual. </para> @@ -49,18 +49,20 @@ <para> This directory contains user configuration files and the output - generated by the Yocto Project in its standard configuration where the source tree is - combined with the output. - The build directory is created initially when you <filename>source</filename> + generated by the OpenEmbedded build system in its standard configuration where + the source tree is combined with the output. + The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> + is created initially when you <filename>source</filename> the Yocto Project environment setup script <filename>oe-init-build-env</filename>. </para> <para> It is also possible to place output and configuration - files in a directory separate from the Yocto Project files + files in a directory separate from the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> by providing a directory name when you <filename>source</filename> the setup script. - For information on separating output from the Yocto Project files, see <link + For information on separating output from your local source directory files, see <link linkend='structure-core-script'>oe-init-build-env</link>. </para> </section> @@ -147,9 +149,11 @@ By default, running this script without a build directory argument creates the <filename>build</filename> directory. If you provide a build directory argument when you <filename>source</filename> - the script, you direct the Yocto Project to create a build directory of your choice. + the script, you direct OpenEmbedded build system to create a + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> of your choice. For example, the following command creates a build directory named - <filename>mybuilds</filename> that is outside of the Yocto Project files: + <filename>mybuilds</filename> that is outside of the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>sourc directory</ulink>: <literallayout class='monospaced'> $ source oe-init-build-env ~/mybuilds </literallayout> @@ -181,12 +185,12 @@ <title><filename>build/conf/local.conf</filename></title> <para> - This file contains all the local user configuration of the Yocto Project. + This file contains all the local user configuration for your build environment. 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 the Yocto Project unless - that variable is hard-coded within the Yocto Project (e.g. by using '=' instead of '?='). + Any variable set here overrides any variable set elsewhere within the environment unless + that variable is hard-coded within a file (e.g. by using '=' instead of '?='). Some variables are hard-coded for various reasons but these variables are relatively rare. </para> @@ -244,10 +248,11 @@ <title><filename>build/tmp/</filename></title> <para> - This directory receives all the Yocto Project output. + This directory receives all the OpenEmbedded build system's output. BitBake creates this directory if it does not exist. - As a last resort, to clean the Yocto Project and start a build from scratch (other than downloads), - you can remove everything in this directory or get rid of the directory completely. + As a last resort, to clean up a build and start it from scratch (other than the downloads), + you can remove everything in the <filename>tmp</filename> directory or get rid of the + directory completely. If you do, you should also completely remove the <filename>build/sstate-cache</filename> directory as well. </para> @@ -275,7 +280,7 @@ <title><filename>build/tmp/deploy/</filename></title> <para> - This directory contains any 'end result' output from the Yocto Project build process. + This directory contains any 'end result' output from the OpenEmbedded build process. </para> </section> @@ -283,7 +288,8 @@ <title><filename>build/tmp/deploy/deb/</filename></title> <para> - This directory receives any <filename>.deb</filename> packages produced by the Yocto Project. + This directory receives any <filename>.deb</filename> packages produced by + the build process. The packages are sorted into feeds for different architecture types. </para> </section> @@ -292,7 +298,8 @@ <title><filename>build/tmp/deploy/rpm/</filename></title> <para> - This directory receives any <filename>.rpm</filename> packages produced by the Yocto Project. + This directory receives any <filename>.rpm</filename> packages produced by + the build process. The packages are sorted into feeds for different architecture types. </para> </section> @@ -319,7 +326,9 @@ <section id='structure-build-tmp-deploy-ipk'> <title><filename>build/tmp/deploy/ipk/</filename></title> - <para>This directory receives <filename>.ipk</filename> packages produced by the Yocto Project.</para> + <para> + This directory receives <filename>.ipk</filename> packages produced by + the build process.</para> </section> <section id='structure-build-tmp-sysroots'> @@ -380,7 +389,8 @@ <para> It is worth considering the structure of a typical work directory. - As an example, consider the linux-yocto kernel 3.0 on the machine <filename>qemux86</filename> + As an example, consider the <filename>linux-yocto-kernel-3.0</filename> + on the machine <filename>qemux86</filename> built within the Yocto Project. For this package, a work directory of <filename>tmp/work/qemux86-poky-linux/linux-yocto-3.0+git1+<.....></filename>, @@ -455,7 +465,7 @@ <para> This directory contains all the machine configuration files. If you set <filename>MACHINE="qemux86"</filename>, - Yocto Project looks for a <filename>qemux86.conf</filename> file in this + the OpenEmbedded build system looks for a <filename>qemux86.conf</filename> file in this directory. The <filename>include</filename> directory contains various data common to multiple machines. If you want to add support for a new machine to the Yocto Project, look in this directory. @@ -467,12 +477,11 @@ <para> Any distribution-specific configuration is controlled from this directory. - The Yocto Project only contains the Yocto Project distribution so - <filename>defaultsetup.conf</filename> is the main file here. + For the Yocto Project, the <filename>defaultsetup.conf</filename> is the main file here. This directory includes the versions and the <filename>SRCDATE</filename> definitions 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 the Yocto Project itself. + An example of an alternative configuration might be <filename>poky-bleeding.conf</filename>. + Although this file mainly inherits its configuration from Poky. </para> </section> diff --git a/documentation/poky-ref-manual/ref-variables.xml b/documentation/poky-ref-manual/ref-variables.xml index c815d3cfa0..99edab592e 100644 --- a/documentation/poky-ref-manual/ref-variables.xml +++ b/documentation/poky-ref-manual/ref-variables.xml @@ -8,7 +8,7 @@ <title>Reference: Variables Glossary</title> <para> - This section lists common variables used in the Yocto Project and gives an overview + This section lists common variables used in the OpenEmbedded build system and gives an overview of their function and contents. </para> @@ -89,7 +89,7 @@ <glossentry id='var-B'><glossterm>B</glossterm> <glossdef> <para> - The directory in which the Yocto Project build system places + The directory in which the OpenEmbedded build system places generated objects during a recipe's build process. By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link> directory: @@ -99,7 +99,7 @@ You can separate the source directory (<filename>S</filename>) and the directory pointed to by the <filename>B</filename> variable. Most autotools-based recipes support separating these directories. - The Yocto Project defaults to using separate directories for <filename>gcc</filename> + The build system defaults to using separate directories for <filename>gcc</filename> and some kernel recipes. </para> </glossdef> @@ -160,7 +160,7 @@ </literallayout></para> <para>Use the <filename>BBMASK</filename> variable from within the <filename>conf/local.conf</filename> file found - in the Yocto Project build directory.</para> + in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.</para> </glossdef> </glossentry> @@ -243,9 +243,9 @@ <glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm> <glossdef> - <para>Lists the layers to enable during the Yocto Project build. + <para>Lists the layers to enable during the build. This variable is defined in the <filename>bblayers.conf</filename> configuration - file in the Yocto Project build directory. + file in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>. Here is an example: <literallayout class='monospaced'> BBLAYERS = " \ @@ -335,8 +335,8 @@ <filename>/etc</filename> or <filename>${bindir}</filename> rather than <filename>/usr/bin</filename>. You can find a list of these variables at the top of the - <filename>/meta/conf/bitbake.conf</filename> file in the Yocto Project - files directory. + <filename>/meta/conf/bitbake.conf</filename> file in the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. </note> </glossdef> </glossentry> @@ -358,7 +358,7 @@ Specifies the list of packages to be added to the image. This variable should only be set in the <filename>local.conf</filename> configuration file found in the - <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project Build Directory</ulink>. + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>. </para> <para> @@ -479,7 +479,7 @@ This directory is self-maintaining and you should not have to touch it. By default, the directory is <filename>downloads</filename> in the - Yocto Project build directory. + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>. <literallayout class='monospaced'> #DL_DIR ?= "${TOPDIR}/downloads" </literallayout> @@ -635,8 +635,8 @@ <filename>/etc</filename> or <filename>${bindir}</filename> rather than <filename>/usr/bin</filename>. You can find a list of these variables at the top of the - <filename>/meta/conf/bitbake.conf</filename> file in the Yocto Project - files directory. + <filename>/meta/conf/bitbake.conf</filename> file in the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. </note> <para> @@ -655,7 +655,7 @@ <glossentry id='var-FILESEXTRAPATHS'><glossterm>FILESEXTRAPATHS</glossterm> <glossdef> <para> - Extends the search path the Yocto Project build system uses when + Extends the search path the OpenEmbedded build system uses when looking for files and patches as it processes recipes. The directories BitBake uses when it processes recipes is defined by the <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> variable. @@ -691,7 +691,7 @@ <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm> <glossdef> <para> - The default set of directories the Yocto Project build system uses + The default set of directories the OpenEmbedded build system uses when searching for patches and files. During the build process, BitBake searches each directory in <filename>FILESPATH</filename> in the specified order when looking for @@ -702,7 +702,7 @@ The default value for the <filename>FILESPATH</filename> variable is defined in the <filename>base.bbclass</filename> class found in <filename>meta/classes</filename> in the - <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>: + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>: <literallayout class='monospaced'> FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ "${FILE_DIRNAME}/${P}", "${FILE_DIRNAME}/${PN}", \ @@ -727,16 +727,17 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ possible. </para> <para> - By default, the Yocto Project uses the <filename>fs-perms.txt</filename>, which - is located in the <filename>meta/files</filename> directory of the Yocto Project - files directory. + By default, the OpenEmbedded build system uses the <filename>fs-perms.txt</filename>, which + is located in the <filename>meta/files</filename> folder in the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. If you create your own file permissions setting table, you should place it in your layer or the distros layer. </para> <para> You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the - <filename>conf/local.conf</filename> file, which is found in the Yocto Project's - build directory, to point to your custom <filename>fs-perms.txt</filename>. + <filename>conf/local.conf</filename> file, which is found in the + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>, to + point to your custom <filename>fs-perms.txt</filename>. You can specify more than a single file permissions setting table. The paths you specify to these files must be defined within the <filename>BBPATH</filename> variable. @@ -785,7 +786,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ Note that you can add extra features to the image by using the <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable. See the "<link linkend="ref-features-image">Reference: Images</link>" section for the - list of features present in images built by the Yocto Project.</para> + list of features present in images built by the OpenEmbedded build system.</para> </glossdef> </glossentry> @@ -908,7 +909,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossdef> <para> Defines the size in Kbytes for the generated image. - The Yocto Project build system determines the final size for the generated + The OpenEmbedded build system determines the final size for the generated image using an algorithm that takes into account the initial disk space used for the generated image, a requested size for the image, and requested additional free disk space to be added to the image. @@ -1035,8 +1036,8 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm> <glossdef> - <para>Includes additional metadata from the Linux Yocto kernel Git repository. - In the Yocto Project build system, the default Board Support Packages (BSPs) + <para>Includes additional metadata from the Yocto Project kernel Git repository. + In the OpenEmbedded build system, the default Board Support Packages (BSPs) metadata is provided through the <filename>KMACHINE</filename> and <filename>KBRANCH</filename> variables. You can use the <filename>KERNEL_FEATURES</filename> variable to further @@ -1049,7 +1050,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ In this way, you can provide validated, but optional, sets of kernel configurations and features.</para> <para>For example, the following adds <filename>netfilter</filename> to all - the Linux Yocto kernels and adds sound support to the <filename>qemux86</filename> + the Yocto Project kernels and adds sound support to the <filename>qemux86</filename> machine: <literallayout class='monospaced'> # Add netfilter to all linux-yocto kernels @@ -1137,7 +1138,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossentry id='var-LICENSE_DIR'><glossterm>LICENSE_DIR</glossterm> <glossdef> <para>Path to additional licenses used during the build. - By default, the Yocto Project uses <filename>COMMON_LICENSE_DIR</filename> + By default, the OpenEmbedded build system uses <filename>COMMON_LICENSE_DIR</filename> to define the directory that holds common license text used during the build. The <filename>LICENSE_DIR</filename> variable allows you to extend that location to other areas that have additional licenses: @@ -1341,7 +1342,8 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossentry id='var-PACKAGE_CLASSES'><glossterm>PACKAGE_CLASSES</glossterm> <glossdef> <para>This variable, which is set in the <filename>local.conf</filename> configuration - file found in the Yocto Project file's <filename>conf</filename> directory, + file found in the <filename>conf</filename> folder of the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>, specifies the package manager to use when packaging data. You can provide one or more arguments for the variable with the first argument being the package manager used to create images: @@ -1534,7 +1536,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variable. </para> <para> - The Yocto Project build process automatically installs the list of packages + The OpenEmbedded build process automatically installs the list of packages as part of the built package. However, you can remove them later if you want. If, during the build, a package from the list cannot be found, the build @@ -1572,8 +1574,8 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossentry id='var-S'><glossterm>S</glossterm> <glossdef> <para> - The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'> - Yocto Project Build Directory</ulink> where unpacked package source code resides. + The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> + where unpacked package source code resides. This location is within the working directory (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>), which is not static. @@ -1585,9 +1587,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ ${WORKDIR}/${PN}-${PV} </literallayout> As an example, assume a - <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'> - Yocto Project Files</ulink> top-level directory named <filename>poky</filename> - and a default Yocto Project Build Directory of <filename>poky/build</filename>. + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> top-level + folder named <filename>poky</filename> + and a default <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> + at <filename>poky/build</filename>. In this case, the working directory the build system uses to build the <filename>db</filename> package is the following: <literallayout class='monospaced'> @@ -1661,10 +1664,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossdef> <para></para> <para> - By default, the Yocto Project automatically detects whether + By default, the OpenEmbedded build system automatically detects whether <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> contains files that are machine-specific. - If so, the Yocto Project automatically changes + If so, the build system automatically changes <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>. Setting this variable to "0" disables this behavior. </para> @@ -1728,7 +1731,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm> <glossdef> <para>The architecture of the device being built. - While a number of values are possible, the Yocto Project primarily supports + While a number of values are possible, the OpenEmbedded build system primarily supports <filename>arm</filename> and <filename>i586</filename>.</para> </glossdef> </glossentry> @@ -1790,11 +1793,11 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ </para> <para> The <filename>TCMODE</filename> variable selects the external toolchain - built from the Yocto Project or a few supported combinations of + built using the OpenEmbedded build system or a few supported combinations of the upstream GCC or CodeSourcery Labs toolchain. The variable determines which of the <filename>tcmode-*</filename> files in the <filename>meta/conf/distro/include</filename> directory, which is found in the - <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>, + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>, is used. </para> <para> @@ -1811,20 +1814,18 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossentry id='var-TMPDIR'><glossterm>TMPDIR</glossterm> <glossdef> <para> - This variable is the temporary directory the Yocto Project build system + This variable is the temporary directory the OpenEmbedded build system uses when it does its work building images. By default, the <filename>TMPDIR</filename> variable is named <filename>tmp</filename> within the - <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'> - Yocto Project Build Directory</ulink>. + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>. </para> <para> If you want to establish this directory in a location other than the default, you can uncomment the following statement in the <filename>conf/local.conf</filename> file in the - <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'> - Yocto Project Files</ulink>: + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>: <literallayout class='monospaced'> #TMPDIR = "${TOPDIR}/tmp" </literallayout> @@ -1836,10 +1837,9 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossdef> <para> This variable is the - <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'> - Yocto Project Build Directory</ulink>. + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>. BitBake automatically sets this variable. - The Yocto Project build system uses the build directory when building images. + The OpenEmbedded build system uses the build directory when building images. </para> </glossdef> </glossentry> @@ -1857,7 +1857,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <glossentry id='var-WORKDIR'><glossterm>WORKDIR</glossterm> <glossdef> <para> - The pathname of the working directory in which the Yocto Project build system + The pathname of the working directory in which the OpenEmbedded build system builds packages. This directory is located within the <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> directory structure and changes @@ -1884,11 +1884,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ ${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR} </literallayout> As an example, assume a - <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'> - Yocto Project Files</ulink> top-level directory named <filename>poky</filename> - and a default - <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'> - Yocto Project Build Directory</ulink> of <filename>poky/build</filename>. + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> top-level + folder name <filename>poky</filename> and a default + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> + at <filename>poky/build</filename>. In this case, the working directory the build system uses to build the <filename>v86d</filename> package is the following: <literallayout class='monospaced'> @@ -1902,9 +1901,9 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ <literallayout class='monospaced'> ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR} </literallayout> - As an example, again assume a Yocto Project Files top-level directory - named <filename>poky</filename> and a default Yocto Project build directory - of <filename>poky/build</filename>. + As an example, again assume a source directory top-level folder + named <filename>poky</filename> and a default build directory + at <filename>poky/build</filename>. In this case, the working directory the build system uses to build the <filename>acl</filename> package, which is dependent on a MIPS-based device, is the following: diff --git a/documentation/poky-ref-manual/resources.xml b/documentation/poky-ref-manual/resources.xml index 5dc6153bcb..15f4bacb34 100644 --- a/documentation/poky-ref-manual/resources.xml +++ b/documentation/poky-ref-manual/resources.xml @@ -39,8 +39,8 @@ Use this list to monitor Yocto Project development discussions, ask questions, and get help.</para></listitem> <listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink></emphasis>: - Use this list to monitor discussions about the Yocto Project build system Poky, - ask questions, and get help.</para></listitem> + Use this list to monitor discussions about the OpenEmbedded build system, which is + based on Poky, ask questions, and get help.</para></listitem> </itemizedlist> </para> </section> @@ -65,15 +65,16 @@ <itemizedlist> <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>: </emphasis> The home site for the Yocto Project.</para></listitem> - <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis> +<!-- <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis> The company where the Yocto Project build system Poky was first developed. - OpenedHand has since been acquired by Intel Corporation.</para></listitem> + OpenedHand has since been acquired by Intel Corporation.</para></listitem> --> <listitem><para><emphasis><ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis> - The company who acquired OpenedHand in 2008 and continues development on the + The company who acquired OpenedHand in 2008 and began development on the Yocto Project.</para></listitem> <listitem><para><emphasis><ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis> - The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives - from and to which it contributes.</para></listitem> + The upstream, generic, embedded distribution used as the basis for the build system in the + Yocto Project. + Poky derives from and contributes back to the OpenEmbedded project.</para></listitem> <listitem><para><emphasis><ulink url='http://developer.berlios.de/projects/bitbake/'> BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem> <listitem><para><emphasis><ulink url='http://bitbake.berlios.de/manual/'> diff --git a/documentation/poky-ref-manual/usingpoky.xml b/documentation/poky-ref-manual/usingpoky.xml index 914a0f5771..6ce36014f1 100644 --- a/documentation/poky-ref-manual/usingpoky.xml +++ b/documentation/poky-ref-manual/usingpoky.xml @@ -8,15 +8,15 @@ <para> This chapter describes common usage for the Yocto Project. The information is introductory in nature as other manuals in the Yocto Project - provide more details on how to use the Yocto Project. + documentation set provide more details on how to use the Yocto Project. </para> <section id='usingpoky-build'> <title>Running a Build</title> <para> - You can find general information on how to build an image using the - Yocto Project in the + You can find general information on how to build an image using the OpenEmbedded build + system in the "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section of The Yocto Project Quick Start. This section provides a summary of the build process and provides information @@ -36,7 +36,7 @@ <para> The <filename>build_dir</filename> is optional and specifies the directory Yocto Project - uses for the build. + uses for the build - the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>. If you do not specify a build directory it defaults to <filename>build</filename> in your current working directory. A common practice is to use a different build directory for different targets. @@ -56,11 +56,11 @@ <para> The <filename>target</filename> 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. all found in the Yocto Project - files. + <filename>/meta/recipes-sato/images</filename>, etc. all found in the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. 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 images the Yocto Project supports, see the + For more details about the images the OpenEmbedded build system supports, see the "<link linkend="ref-images">Reference: Images</link>" appendix. </para> @@ -89,7 +89,8 @@ <para> Once an image has been built, it often needs to be installed. - The images and kernels built by the Yocto Project are placed in the build directory in + The images and kernels built by the OpenEmbedded build system are placed in the + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> in <filename class="directory">tmp/deploy/images</filename>. For information on how to run pre-built images such as <filename>qemux86</filename> and <filename>qemuarm</filename>, see the @@ -104,12 +105,12 @@ <title>Debugging Build Failures</title> <para> - The exact method for debugging Yocto Project build failures depends on the nature of the + The exact method for debugging build failures 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 Yocto Project just as they are for any other system. + valid for the Yocto Project just as they are for any other system. Even though it is impossible to detail every possible potential failure, this section provides some general tips to aid in debugging. </para> @@ -263,10 +264,10 @@ </para> <para> - For guidance on how logging is handled - in both Python and Bash recipes, see the + For guidance on how logging is handled in both Python and Bash recipes, see the <filename>logging.bbclass</filename> file in the - <filename>meta/classes</filename> directory of the Yocto Project files. + <filename>meta/classes</filename> folder of the + <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. </para> <section id='logging-with-python'> |