diff --git a/documentation/mega-manual/mega-manual.xml b/documentation/mega-manual/mega-manual.xml index 68fb1e17d8..efefa17032 100644 --- a/documentation/mega-manual/mega-manual.xml +++ b/documentation/mega-manual/mega-manual.xml @@ -231,7 +231,10 @@ + xmlns:xi="http://www.w3.org/2003/XInclude" href="../ref-manual/ref-system-requirements.xml"/> + + diff --git a/documentation/ref-manual/ref-manual.xml b/documentation/ref-manual/ref-manual.xml index a24a9e310d..e69ab72c62 100644 --- a/documentation/ref-manual/ref-manual.xml +++ b/documentation/ref-manual/ref-manual.xml @@ -166,7 +166,9 @@ - + + + diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/ref-system-requirements.xml similarity index 50% rename from documentation/ref-manual/introduction.xml rename to documentation/ref-manual/ref-system-requirements.xml index 098dbc8a22..dfa2c2b6d1 100644 --- a/documentation/ref-manual/introduction.xml +++ b/documentation/ref-manual/ref-system-requirements.xml @@ -2,21 +2,18 @@ "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [ %poky; ] > - -Introduction - -
- Welcome + +System Requirements - Welcome to the Yocto Project Reference Manual. + Welcome to the Yocto Project Reference Manual! This manual provides reference information for the current release of the Yocto Project. - This manual is best used after you have an understanding + The manual is best used after you have an understanding of the basics of the Yocto Project. The manual is neither meant to be read as a starting point to the Yocto Project nor read from start to finish. - Use this manual to find concepts, variable definitions, class + Use this manual to find variable definitions, class descriptions, and so forth as needed during the course of using the Yocto Project. @@ -41,17 +38,6 @@ section. -
- -
-System Requirements - - For general Yocto Project system requirements, see the - "Setting Up to Use the Yocto Project" section - in the Yocto Project Quick Start. - The remainder of this section provides details on system requirements - not covered in the Yocto Project Quick Start. -
Supported Linux Distributions @@ -500,437 +486,6 @@
- - -
- Yocto Project Terms - - - Following is a list of terms and definitions users new to the Yocto - Project development environment might find helpful. - While some of these terms are universal, the list includes them - just in case: - - - Append Files: - Files that append build information to a recipe file. - Append files are known as BitBake append files and - .bbappend files. - The OpenEmbedded build system expects every append file to have - a corresponding recipe (.bb) file. - Furthermore, the append file and corresponding recipe file - must use the same root filename. - The filenames can differ only in the file type suffix used - (e.g. - formfactor_0.0.bb and - formfactor_0.0.bbappend). - - Information in append files extends or overrides the - information in the similarly-named recipe file. - For an example of an append file in use, see the - "Using .bbappend Files in Your Layer" - section in the Yocto Project Development Tasks Manual. - - Append files can also use wildcard patterns in their - version numbers so they can be applied to more than one - version of the underlying recipe file. - - - - BitBake: - The task executor and scheduler used by the OpenEmbedded build - system to build images. - For more information on BitBake, see the - BitBake User Manual. - - - Board Support Package (BSP): - A group of drivers, definitions, and other components that - provide support for a specific hardware configuration. - For more information on BSPs, see the - Yocto Project Board Support Package (BSP) Developer's Guide. - - - - Build Directory: - This term refers to the area used by the OpenEmbedded build - system for builds. - The area is created when you source the - setup environment script that is found in the Source Directory - (i.e. &OE_INIT_FILE;). - The - TOPDIR - variable points to the Build Directory. - - You have a lot of flexibility when creating the Build - Directory. - Following are some examples that show how to create the - directory. - The examples assume your - Source Directory is - named poky: - - Create the Build Directory inside your - Source Directory and let the name of the Build - Directory default to build: - - $ cd $HOME/poky - $ source &OE_INIT_FILE; - - - Create the Build Directory inside your - home directory and specifically name it - test-builds: - - $ cd $HOME - $ source poky/&OE_INIT_FILE; test-builds - - - - Provide a directory path and specifically name the - Build Directory. - Any intermediate folders in the pathname must exist. - This next example creates a Build Directory named - YP-&POKYVERSION; - in your home directory within the existing - directory mybuilds: - - $cd $HOME - $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION; - - - - - By default, the Build Directory contains - TMPDIR, - which is a temporary directory the build system uses for - its work. - TMPDIR cannot be under NFS. - Thus, by default, the Build Directory cannot be under NFS. - However, if you need the Build Directory to be under NFS, - you can set this up by setting TMPDIR - in your local.conf file - to use a local drive. - Doing so effectively separates TMPDIR - from TOPDIR, which is the Build - Directory. - - - - Build System: - The system used to build images in a Yocto Project - Development environment. - The build system is sometimes referred to as the - development host. - - - Classes: - Files that provide for logic encapsulation and inheritance so - that commonly used patterns can be defined once and then - easily used in multiple recipes. - For reference information on the Yocto Project classes, see the - "Classes" chapter. - Class files end with the .bbclass - filename extension. - - - Configuration File: - Configuration information in various .conf - files provides global definitions of variables. - The conf/local.conf configuration file in - the - Build Directory - contains user-defined variables that affect every build. - The meta-poky/conf/distro/poky.conf - configuration file defines Yocto "distro" configuration - variables used only when building with this policy. - Machine configuration files, which - are located throughout the - Source Directory, define - variables for specific hardware and are only used when building - for that target (e.g. the - machine/beaglebone.conf configuration - file defines variables for the Texas Instruments ARM Cortex-A8 - development board). - Configuration files end with a .conf - filename extension. - - - Cross-Development Toolchain: - In general, a cross-development toolchain is a collection of - software development tools and utilities that run on one - architecture and allow you to develop software for a - different, or targeted, architecture. - These toolchains contain cross-compilers, linkers, and - debuggers that are specific to the target architecture. - - The Yocto Project supports two different cross-development - toolchains: - - - A toolchain only used by and within - BitBake when building an image for a target - architecture. - - A relocatable toolchain used outside of - BitBake by developers when developing applications - that will run on a targeted device. - - - - Creation of these toolchains is simple and automated. - For information on toolchain concepts as they apply to the - Yocto Project, see the - "Cross-Development Toolchain Generation" - section. - You can also find more information on using the - relocatable toolchain in the - Yocto Project Application Development and the Extensible Software Development Kit (eSDK) - manual. - - - Image: - An image is an artifact of the BitBake build process given - a collection of recipes and related Metadata. - Images are the binary output that run on specific hardware or - QEMU and are used for specific use-cases. - For a list of the supported image types that the Yocto Project - provides, see the - "Images" - chapter. - - - Layer: - A collection of recipes representing the core, - a BSP, or an application stack. - For a discussion specifically on BSP Layers, see the - "BSP Layers" - section in the Yocto Project Board Support Packages (BSP) - Developer's Guide. - - - Metadata: - The files that BitBake parses when building an image. - In general, Metadata includes recipes, classes, and - configuration files. - In the context of the kernel ("kernel Metadata"), the - term refers to the kernel config fragments and features - contained in the - yocto-kernel-cache - Git repository. - - - OE-Core: - A core set of Metadata originating with OpenEmbedded (OE) - that is shared between OE and the Yocto Project. - This Metadata is found in the meta - directory of the - Source Directory. - - - OpenEmbedded Build System: - The build system specific to the Yocto Project. - The OpenEmbedded build system is based on another project known - as "Poky", which uses - BitBake as the task - executor. - Throughout the Yocto Project documentation set, the - OpenEmbedded build system is sometimes referred to simply - as "the build system". - If other build systems, such as a host or target build system - are referenced, the documentation clearly states the - difference. - - For some historical information about Poky, see the - Poky term. - - - - Package: - In the context of the Yocto Project, this term refers to a - recipe's packaged output produced by BitBake (i.e. a - "baked recipe"). - A package is generally the compiled binaries produced from the - recipe's sources. - You "bake" something by running it through BitBake. - - It is worth noting that the term "package" can, - in general, have subtle meanings. - For example, the packages referred to in the - "The Build Host Packages" - section in the Yocto Project Quick Start are compiled binaries - that, when installed, add functionality to your Linux - distribution. - - Another point worth noting is that historically within - the Yocto Project, recipes were referred to as packages - thus, - the existence of several BitBake variables that are seemingly - mis-named, - (e.g. PR, - PV, and - PE). - - - Package Groups: - Arbitrary groups of software Recipes. - You use package groups to hold recipes that, when built, - usually accomplish a single task. - For example, a package group could contain the recipes for a - company’s proprietary or value-add software. - Or, the package group could contain the recipes that enable - graphics. - A package group is really just another recipe. - Because package group files are recipes, they end with the - .bb filename extension. - - - Poky: - The term "poky", which is pronounced - Pah-kee, can mean several things: - - - In its most general sense, poky is an open-source - project that was initially developed by OpenedHand. - OpenedHand developed poky off of the existing - OpenEmbedded build system to create a commercially - supportable build system for embedded Linux. - After Intel Corporation acquired OpenedHand, the - poky project became the basis for the Yocto Project's - build system. - - - Within the Yocto Project - Source Repositories, - "poky" exists as a separate Git - repository from which you can clone to yield a local - Git repository that is a copy on your host system. - Thus, "poky" can refer to the upstream or - local copy of the files used for development within - the Yocto Project. - - - Finally, "poky" can refer to the default - DISTRO - (i.e. distribution) created when you use the Yocto - Project in conjunction with the - poky repository to build an image. - - - - - Recipe: - A set of instructions for building packages. - A recipe describes where you get source code, which patches - to apply, how to configure the source, how to compile it and so on. - Recipes also describe dependencies for libraries or for other - recipes. - Recipes represent the logical unit of execution, the software - to build, the images to build, and use the - .bb file extension. - - - Reference Kit: - A working example of a system, which includes a - BSP - as well as a - build system - and other components, that can work on specific hardware. - - - - Source Directory: - This term refers to the directory structure created as a result - of creating a local copy of the poky Git - repository git://git.yoctoproject.org/poky - or expanding a released poky tarball. - - Creating a local copy of the poky - Git repository is the recommended method for setting up - your Source Directory. - - Sometimes you might hear the term "poky directory" used to refer - to this directory structure. - - The OpenEmbedded build system does not support file or - directory names that contain spaces. - Be sure that the Source Directory you use does not contain - these types of names. - - - The Source Directory contains BitBake, Documentation, - Metadata and other files that all support the Yocto Project. - Consequently, you must have the Source Directory in place on - your development system in order to do any development using - the Yocto Project. - - When you create a local copy of the Git repository, you - can name the repository anything you like. - Throughout much of the documentation, "poky" - is used as the name of the top-level folder of the local copy of - the poky Git repository. - So, for example, cloning the poky Git - repository results in a local Git repository whose top-level - folder is also named "poky". - - While it is not recommended that you use tarball expansion - to set up the Source Directory, if you do, the top-level - directory name of the Source Directory is derived from the - Yocto Project release tarball. - For example, downloading and unpacking - &YOCTO_POKY_TARBALL; results in a - Source Directory whose root folder is named - &YOCTO_POKY;. - - It is important to understand the differences between the - Source Directory created by unpacking a released tarball as - compared to cloning - git://git.yoctoproject.org/poky. - When you unpack a tarball, you have an exact copy of the files - based on the time of release - a fixed release point. - Any changes you make to your local files in the Source Directory - are on top of the release and will remain local only. - On the other hand, when you clone the poky - Git repository, you have an active development repository with - access to the upstream repository's branches and tags. - In this case, any local changes you make to the local - Source Directory can be later applied to active development - branches of the upstream poky Git - repository. - - For more information on concepts related to Git - repositories, branches, and tags, see the - "Repositories, Tags, and Branches" - section in the Yocto Project Overview Manual. - - Task: - A unit of execution for BitBake (e.g. - do_compile, - do_fetch, - do_patch, - and so forth). - - Toaster: - A web interface to the Yocto Project's - OpenEmbedded Build System. - The interface enables you to configure and run your builds. - Information about builds is collected and stored in a database. - For information on Toaster, see the - Yocto Project Toaster Manual. - - - Upstream: - A reference to source code or repositories - that are not local to the development system but located in a - master area that is controlled by the maintainer of the source - code. - For example, in order for a developer to work on a particular - piece of code, they need to first get a copy of it from an - "upstream" source. - - - -
-