From 5966b44893a39847d3d590566dd488323a11ff73 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 2 Jul 2012 14:34:39 -0700 Subject: documentation/poky-ref-manual: Yocto Project scrub I have changed as many "Yocto Project" terms as possible so that better reflect reality. (From yocto-docs rev: 5f729e53b0cb653c97621e4e6598d9295d60ada5) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/poky-ref-manual/development.xml | 21 ++--- documentation/poky-ref-manual/faq.xml | 55 +++++++----- documentation/poky-ref-manual/introduction.xml | 24 ++++-- documentation/poky-ref-manual/ref-bitbake.xml | 15 ++-- documentation/poky-ref-manual/ref-classes.xml | 33 +++---- documentation/poky-ref-manual/ref-features.xml | 2 +- documentation/poky-ref-manual/ref-images.xml | 6 +- documentation/poky-ref-manual/ref-structure.xml | 61 +++++++------ documentation/poky-ref-manual/ref-variables.xml | 109 ++++++++++++------------ documentation/poky-ref-manual/resources.xml | 15 ++-- 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 @@ 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. @@ -25,12 +25,12 @@ section in that when you invoke devshell 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 configure and make. - 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. @@ -45,7 +45,7 @@ - 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: @@ -58,7 +58,7 @@ Within this environment, you can run configure or compile 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 (S). @@ -71,8 +71,8 @@ The default shell used by devshell is xterm. For examples of available options, see the "UI/Interaction Configuration" section of the - meta/conf/bitbake.conf configuration file in the Yocto Project - files. + meta/conf/bitbake.conf configuration file in the + source directory. @@ -99,7 +99,7 @@ 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 @@ To enable this behavior, simply add the following to the local.conf - configuration file in the build directory of the Yocto Project files: + configuration file found in the + build directory: SRCREV_pn-<PN> = "${AUTOREV}" 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 @@ - Poky is the Yocto Project build system that was derived from OpenEmbedded. 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 + poky term in the Yocto Project + Development Manual. @@ -64,7 +70,8 @@ There are three areas that help with stability; - The Yocto Project team keeps Poky small and focused. + The Yocto Project team keeps + Poky small and focused. It contains around 650 packages as compared to over 5000 for full OpenEmbedded. The Yocto Project only supports hardware that the @@ -100,16 +107,17 @@ - Are there any products using Poky? + Are there any products using the OpenEmbedded build system (poky)? The Vernier LabQuest is using - the Yocto Project build system Poky. + the OpenEmbedded build system. See the Vernier LabQuest 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. @@ -118,13 +126,13 @@ - What does the Yocto Project build system Poky produce as output? + What does the OpenEmbedded build system produce as output? 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. @@ -155,7 +163,7 @@ - The Yocto Project can build packages in various formats such as + The OpenEmbedded build system can build packages in various formats such as ipk for ipkg/opkg, Debian package (.deb), or RPM. The packages can then be upgraded using the package tools on the device, much like @@ -223,8 +231,8 @@ - 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 ENABLE_BINARY_LOCALE_GENERATION @@ -244,14 +252,14 @@ 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. @@ -284,7 +292,7 @@ - Most source fetching by the Yocto Project is done by wget + Most source fetching by the OpenEmbedded build system 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 @@ -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. @@ -449,7 +457,7 @@ The Yocto Project team has tried to do this before but too many of the tools - the Yocto Project depends on such as autoconf + the OpenEmbedded build system depends on such as autoconf break when they find spaces in pathnames. Until that situation changes, the team will not support spaces in pathnames. @@ -495,14 +503,14 @@ - 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? - 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. @@ -511,7 +519,8 @@ and then MIRRORS in that order. - 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. @@ -574,7 +583,7 @@ any network accesses to anything other than the PREMIRROR would fail. - Poky also honors the standard shell environment variables + The build system also honors the standard shell environment variables http_proxy, ftp_proxy, https_proxy, and all_proxy to redirect requests through proxy servers. @@ -600,8 +609,8 @@ - Within the Yocto Project Build Directory is the tmp - directory. + Within the build directory + is the tmp directory. To remove all the build output yet preserve any source code or downloaded files from previous builds, simply remove the tmp directory. 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 @@ -51,9 +51,13 @@ the Yocto Project. Reference: Directory Structure: - 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 + source directory. + The source directory represents the local file structure created + as a result from either cloning the upstream + Poky Git repository or unpacking a + released Yocto Project tarball on your host development system. Reference: BitBake: @@ -69,7 +73,7 @@ Reference: Features: This appendix describes mechanisms for creating distribution, machine, and image - features during the build process using the Yocto Project. + features during the build process using the OpenEmbedded build system. Reference: Variables Glossary: This appendix presents most Yocto Project variables. @@ -124,9 +128,11 @@
Development Checkouts - 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 source directory. + You can set source directory up by downloading a Yocto Project release tarball and unpacking it, + or by cloning a copy of the upstream + Poky Git repository. For information on both these methods, see the "Getting Setup" 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 @@ Reference: BitBake - 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: $ bitbake core-image-sato @@ -34,20 +35,22 @@ The first thing BitBake does is look for the bitbake.conf file. - The Yocto Project keeps this file in the Yocto Project file's meta/conf/ - directory. - BitBake finds it by examining its BBPATH environment + This file resides in the + source directory + within the meta/conf/ directory. + BitBake finds it by examining its + BBPATH environment variable and looking for the meta/conf/ directory. - In the Yocto Project, bitbake.conf lists other configuration + The bitbake.conf file lists other configuration files to include from a conf/ directory below the directories listed in BBPATH. In general, the most important configuration file from a user's perspective is local.conf, 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 DISTRO 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 .bbclass and are usually placed in a classes/ directory beneath the - meta*/ directory found in the Yocto Project file's area + meta*/ directory found in the + source directory. Class files can also be pointed to by BUILDDIR (e.g. build/)in the same way as .conf files in the conf directory. - Class files are searched for in BBPATH + Class files are searched for in BBPATH using the same method by which .conf files are searched. @@ -111,7 +112,7 @@ - Currently, the Yocto Project supports only one binary per package. + Currently, the OpenEmbedded build system supports only one binary per package.
@@ -121,7 +122,7 @@ This class uses update-rc.d 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: INITSCRIPT_PACKAGES, @@ -254,7 +255,7 @@ This class adds the devshell task. - Distribution policy dictates whether to include this class as the Yocto Project does. + Distribution policy dictates whether to include this class. See the "Development Within a Development Shell" section for more information about using devshell. @@ -277,8 +278,9 @@ You can control the list of resulting package formats by using the PACKAGE_CLASSES - variable defined in the local.conf configuration file - found in the Yocto Project file's conf directory. + variable defined in the local.conf configuration file, + which is located in the conf folder of the + source directory. 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 local.conf 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. @@ -389,10 +391,10 @@ 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. @@ -514,7 +516,8 @@ you can use this class to specify those packages and associate the users and groups with those packages. The meta-skeleton/recipes-skeleton/useradd/useradd-example.bb - recipe in the Yocto Project Files provides a simple exmample that shows how to add three + recipe in the source directory + provides a simple exmample that shows how to add three users and groups to two packages. See the useradd-example.bb for more information on how to use this class. @@ -526,7 +529,7 @@ 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 @@ This class expects the source code to support recipe builds that use the B 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 B directory is set to the following, which is separate from the source directory (S): @@ -570,7 +573,7 @@ When you do, the B 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 gcc + The OpenEmbedded build system defaults to using separate directories for gcc and some kernel recipes. Alternatively, you can make sure that separate recipes exist that each use the BBCLASSEXTEND 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 meta/classes directory - in the Yocto Project file's directory structure. + in the source directory. You can examine the .bbclass files directly for more information. 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 @@ Reference: Images - 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 IMAGE_FEATURES and EXTRA_IMAGE_FEATURES 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 @@ Reference: Images - 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 bitbake command you provide a “top-level” recipe that essentially begins the build for the type of image you want. @@ -32,8 +32,8 @@ These recipes reside in the meta/recipes-core/images, meta/recipes-extended/images, meta/recipes-graphics/images, and - meta/recipes-sato/images directories of your local Yocto Project - file structure (Git repository or extracted release tarball). + meta/recipes-sato/images directories + within the source directory. Although the recipe names are somewhat explanatory, here is a list that describes them: 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 @@ 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 source directory + and gives information about the various files and directories. - 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 "Getting Set Up" section in the Yocto Project Development Manual. @@ -49,18 +49,20 @@ 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 source + generated by the OpenEmbedded build system in its standard configuration where + the source tree is combined with the output. + The build directory + is created initially when you source the Yocto Project environment setup script oe-init-build-env. 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 + source directory by providing a directory name when you source the setup script. - For information on separating output from the Yocto Project files, see oe-init-build-env. @@ -147,9 +149,11 @@ By default, running this script without a build directory argument creates the build directory. If you provide a build directory argument when you source - 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 + build directory of your choice. For example, the following command creates a build directory named - mybuilds that is outside of the Yocto Project files: + mybuilds that is outside of the + sourc directory: $ source oe-init-build-env ~/mybuilds @@ -181,12 +185,12 @@ <filename>build/conf/local.conf</filename> - 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 local.conf present, it is created from local.conf.sample. The local.conf 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. @@ -244,10 +248,11 @@ <filename>build/tmp/</filename> - 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 tmp directory or get rid of the + directory completely. If you do, you should also completely remove the build/sstate-cache directory as well. @@ -275,7 +280,7 @@ <filename>build/tmp/deploy/</filename> - 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. @@ -283,7 +288,8 @@ <filename>build/tmp/deploy/deb/</filename> - This directory receives any .deb packages produced by the Yocto Project. + This directory receives any .deb packages produced by + the build process. The packages are sorted into feeds for different architecture types. @@ -292,7 +298,8 @@ <filename>build/tmp/deploy/rpm/</filename> - This directory receives any .rpm packages produced by the Yocto Project. + This directory receives any .rpm packages produced by + the build process. The packages are sorted into feeds for different architecture types. @@ -319,7 +326,9 @@
<filename>build/tmp/deploy/ipk/</filename> - This directory receives .ipk packages produced by the Yocto Project. + + This directory receives .ipk packages produced by + the build process.
@@ -380,7 +389,8 @@ It is worth considering the structure of a typical work directory. - As an example, consider the linux-yocto kernel 3.0 on the machine qemux86 + As an example, consider the linux-yocto-kernel-3.0 + on the machine qemux86 built within the Yocto Project. For this package, a work directory of tmp/work/qemux86-poky-linux/linux-yocto-3.0+git1+<.....>, @@ -455,7 +465,7 @@ This directory contains all the machine configuration files. If you set MACHINE="qemux86", - Yocto Project looks for a qemux86.conf file in this + the OpenEmbedded build system looks for a qemux86.conf file in this directory. The include 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 @@ Any distribution-specific configuration is controlled from this directory. - The Yocto Project only contains the Yocto Project distribution so - defaultsetup.conf is the main file here. + For the Yocto Project, the defaultsetup.conf is the main file here. This directory includes the versions and the SRCDATE definitions for applications that are configured here. - An example of an alternative configuration is poky-bleeding.conf - although this file mainly inherits its configuration from the Yocto Project itself. + An example of an alternative configuration might be poky-bleeding.conf. + Although this file mainly inherits its configuration from Poky.
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 @@ Reference: Variables Glossary - 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. @@ -89,7 +89,7 @@ B - 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 S directory: @@ -99,7 +99,7 @@ You can separate the source directory (S) and the directory pointed to by the B variable. Most autotools-based recipes support separating these directories. - The Yocto Project defaults to using separate directories for gcc + The build system defaults to using separate directories for gcc and some kernel recipes. @@ -160,7 +160,7 @@ Use the BBMASK variable from within the conf/local.conf file found - in the Yocto Project build directory. + in the build directory. @@ -243,9 +243,9 @@ BBLAYERS - Lists the layers to enable during the Yocto Project build. + Lists the layers to enable during the build. This variable is defined in the bblayers.conf configuration - file in the Yocto Project build directory. + file in the build directory. Here is an example: BBLAYERS = " \ @@ -335,8 +335,8 @@ /etc or ${bindir} rather than /usr/bin. You can find a list of these variables at the top of the - /meta/conf/bitbake.conf file in the Yocto Project - files directory. + /meta/conf/bitbake.conf file in the + source directory. @@ -358,7 +358,7 @@ Specifies the list of packages to be added to the image. This variable should only be set in the local.conf configuration file found in the - Yocto Project Build Directory. + build directory. @@ -479,7 +479,7 @@ This directory is self-maintaining and you should not have to touch it. By default, the directory is downloads in the - Yocto Project build directory. + build directory. #DL_DIR ?= "${TOPDIR}/downloads" @@ -635,8 +635,8 @@ /etc or ${bindir} rather than /usr/bin. You can find a list of these variables at the top of the - /meta/conf/bitbake.conf file in the Yocto Project - files directory. + /meta/conf/bitbake.conf file in the + source directory. @@ -655,7 +655,7 @@ FILESEXTRAPATHS - 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 FILESPATH variable. @@ -691,7 +691,7 @@ FILESPATH - 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 FILESPATH in the specified order when looking for @@ -702,7 +702,7 @@ The default value for the FILESPATH variable is defined in the base.bbclass class found in meta/classes in the - Yocto Project Files: + source directory: 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. - By default, the Yocto Project uses the fs-perms.txt, which - is located in the meta/files directory of the Yocto Project - files directory. + By default, the OpenEmbedded build system uses the fs-perms.txt, which + is located in the meta/files folder in the + source directory. If you create your own file permissions setting table, you should place it in your layer or the distros layer. You define the FILESYSTEM_PERMS_TABLES variable in the - conf/local.conf file, which is found in the Yocto Project's - build directory, to point to your custom fs-perms.txt. + conf/local.conf file, which is found in the + build directory, to + point to your custom fs-perms.txt. You can specify more than a single file permissions setting table. The paths you specify to these files must be defined within the BBPATH 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 EXTRA_IMAGE_FEATURES variable. See the "Reference: Images" section for the - list of features present in images built by the Yocto Project. + list of features present in images built by the OpenEmbedded build system. @@ -908,7 +909,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ 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}", \ KERNEL_FEATURES - Includes additional metadata from the Linux Yocto kernel Git repository. - In the Yocto Project build system, the default Board Support Packages (BSPs) + 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 KMACHINE and KBRANCH variables. You can use the KERNEL_FEATURES 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. For example, the following adds netfilter to all - the Linux Yocto kernels and adds sound support to the qemux86 + the Yocto Project kernels and adds sound support to the qemux86 machine: # Add netfilter to all linux-yocto kernels @@ -1137,7 +1138,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ LICENSE_DIR Path to additional licenses used during the build. - By default, the Yocto Project uses COMMON_LICENSE_DIR + By default, the OpenEmbedded build system uses COMMON_LICENSE_DIR to define the directory that holds common license text used during the build. The LICENSE_DIR 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}", \ PACKAGE_CLASSES This variable, which is set in the local.conf configuration - file found in the Yocto Project file's conf directory, + file found in the conf folder of the + source directory, 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}", \ RDEPENDS variable. - 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}", \ S - The location in the - Yocto Project Build Directory where unpacked package source code resides. + The location in the build directory + where unpacked package source code resides. This location is within the working directory (WORKDIR), which is not static. @@ -1585,9 +1587,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ ${WORKDIR}/${PN}-${PV} As an example, assume a - - Yocto Project Files top-level directory named poky - and a default Yocto Project Build Directory of poky/build. + source directory top-level + folder named poky + and a default build directory + at poky/build. In this case, the working directory the build system uses to build the db package is the following: @@ -1661,10 +1664,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ - By default, the Yocto Project automatically detects whether + By default, the OpenEmbedded build system automatically detects whether SRC_URI contains files that are machine-specific. - If so, the Yocto Project automatically changes + If so, the build system automatically changes PACKAGE_ARCH. Setting this variable to "0" disables this behavior. @@ -1728,7 +1731,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ TARGET_ARCH 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 arm and i586. @@ -1790,11 +1793,11 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ The TCMODE 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 tcmode-* files in the meta/conf/distro/include directory, which is found in the - Yocto Project Files, + source directory, is used. @@ -1811,20 +1814,18 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ TMPDIR - 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 TMPDIR variable is named tmp within the - - Yocto Project Build Directory. + build directory. If you want to establish this directory in a location other than the default, you can uncomment the following statement in the conf/local.conf file in the - - Yocto Project Files: + source directory: #TMPDIR = "${TOPDIR}/tmp" @@ -1836,10 +1837,9 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ This variable is the - - Yocto Project Build Directory. + build directory. 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. @@ -1857,7 +1857,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ WORKDIR - 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 TMPDIR 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} As an example, assume a - - Yocto Project Files top-level directory named poky - and a default - - Yocto Project Build Directory of poky/build. + source directory top-level + folder name poky and a default + build directory + at poky/build. In this case, the working directory the build system uses to build the v86d package is the following: @@ -1902,9 +1901,9 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \ ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR} - As an example, again assume a Yocto Project Files top-level directory - named poky and a default Yocto Project build directory - of poky/build. + As an example, again assume a source directory top-level folder + named poky and a default build directory + at poky/build. In this case, the working directory the build system uses to build the acl 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. : - Use this list to monitor discussions about the Yocto Project build system Poky, - ask questions, and get help. + Use this list to monitor discussions about the OpenEmbedded build system, which is + based on Poky, ask questions, and get help. @@ -65,15 +65,16 @@ The Yocto Project website: The home site for the Yocto Project. - OpenedHand: + Intel Corporation: - 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. OpenEmbedded: - The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives - from and to which it contributes. + 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. BitBake: The tool used to process Yocto Project metadata. 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 @@ 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.
Running a Build - 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 "Building an Image" section of The Yocto Project Quick Start. This section provides a summary of the build process and provides information @@ -36,7 +36,7 @@ The build_dir is optional and specifies the directory Yocto Project - uses for the build. + uses for the build - the build directory. If you do not specify a build directory it defaults to build in your current working directory. A common practice is to use a different build directory for different targets. @@ -56,11 +56,11 @@ The target is the name of the recipe you want to build. Common targets are the images in meta/recipes-core/images, - /meta/recipes-sato/images, etc. all found in the Yocto Project - files. + /meta/recipes-sato/images, etc. all found in the + source directory. Or, the target can be the name of a recipe for a specific piece of software such as busybox. - 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 "Reference: Images" appendix. @@ -89,7 +89,8 @@ 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 + build directory in tmp/deploy/images. For information on how to run pre-built images such as qemux86 and qemuarm, see the @@ -104,12 +105,12 @@ Debugging Build Failures - 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. @@ -263,10 +264,10 @@ - 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 logging.bbclass file in the - meta/classes directory of the Yocto Project files. + meta/classes folder of the + source directory.
-- cgit v1.2.3-54-g00ecf