From 7b70da93bc86b5aa6a9907c7e9f370932ff709ec Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 9 Sep 2013 13:36:30 -0700 Subject: ref-manual: Re-ordered flow for detailed process sections. Fixes [YOCTO #2808] Based on feedback from Dave Stewart, I have rearranged the sub- section flow of the topics to match that of an actual build. This meant moving the BitBake section higher up in the order. (From yocto-docs rev: 3e62dd70dab596c3a55815c1ad3f1578a9f3400f) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/technical-details.xml | 434 ++++++++++++------------- 1 file changed, 217 insertions(+), 217 deletions(-) (limited to 'documentation/ref-manual/technical-details.xml') diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml index 4a6c3b2a6e..bfab8a6c68 100644 --- a/documentation/ref-manual/technical-details.xml +++ b/documentation/ref-manual/technical-details.xml @@ -743,223 +743,6 @@ -
- Package Feeds - - - When the OpenEmbedded build system generates an image or an SDK, - it gets the packages from a package feed area located in the - Build Directory. - The main - Yocto Project Development Environment - figure shows this package feeds area in the upper-right corner. - - - - This section looks a little closer into the package feeds area used - by the build system. - Here is a more detailed look at the area: - - - - - Package feeds are an intermediary step in the build process. - BitBake generates packages whose type is defined by the - PACKAGE_CLASSES - variable. - Before placing the packages into package feeds, - the build process validates them with generated output quality - assurance checks through the - insane.bbclass - class. - - - - The package feed area resides in - tmp/deploy of the Build Directory. - Folders are created that correspond to the package type - (IPK, DEB, or RPM) created. - Further organization is derived through the value of the - PACKAGE_ARCH - variable for each package. - For example, packages can exist for the i586 or qemux86 - architectures. - The package files themselves reside within the appropriate - architecture folder. - - - - BitBake uses the do_package_write_* task to - place generated packages into the package holding area (e.g. - do_package_write_ipk for IPK packages). - -
- -
- Images - - - The images produced by the OpenEmbedded build system - are compressed forms of the - root filesystems that are ready to boot on a target device. - You can see from the main - Yocto Project Development Environment - figure that BitBake output in part consists of images. - This section is going to look more closely at this output: - - - - - For a list of example images that the Yocto Project provides, - the - "Images" chapter. - - - - Images are written out to the - Build Directory - inside the deploy/images folder as shown - in the figure. - This folder contains any files expected to be loaded on the - target device. - The - DEPLOY_DIR - variable points to the deploy directory. - - <kernel-image>: - A kernel binary file. - The KERNEL_IMAGETYPE - variable setting determines the naming scheme for the - kernel image file. - Depending on that variable, the file could begin with - a variety of naming strings. - The deploy/images directory can - contain multiple image files. - <root-filesystem-image>: - Root filesystems for the target device (e.g. - *.ext3 or *.bz2 - files). - The IMAGE_FSTYPES - variable setting determines the root filesystem image - type. - The deploy/images directory can - contain multiple root filesystems. - <kernel-modules>: - Tarballs that contain all the modules built for the kernel. - Kernel module tarballs exist for legacy purposes and - can be suppressed by setting the - MODULE_TARBALL_DEPLOY - variable to "0". - The deploy/images directory can - contain multiple kernel module tarballs. - - <bootloaders>: - Bootloaders supporting the image, if applicable to the - target machine. - The deploy/images directory can - contain multiple bootloaders. - - <symlinks>: - The deploy/images folder contains - a symbolic link that points to the most recently built file - for each machine. - These links might be useful for external scripts that - need to obtain the latest version of each file. - - - -
- -
- Application Development SDK - - - In the overview figure of the - Yocto Project Development Environment - the output labeled "Application Development SDK" represents an - SDK. - This section is going to take a closer look at this output: - - - - - The specific form of this output is a self-extracting - SDK installer (*.sh) that, when run, - installs the SDK, which consists of a cross-development - toolchain, a set of libraries and headers, and an SDK - environment setup script. - Running this installer essentially sets up your - cross-development environment. - You can think of the cross-toolchain as the "host" - part because it runs on the SDK machine. - You can think of the libraries and headers as the "target" - part because they are built for the target hardware. - The setup script is added so that you can initialize the - environment before using the tools. - - - - - The Yocto Project supports several methods by which you can - set up this cross-development environment. - These methods include downloading pre-built SDK installers, - building and installing your own SDK installer, or running - an Application Development Toolkit (ADT) installer to - install not just cross-development toolchains - but also additional tools to help in this type of - development. - - - - For background information on cross-development toolchains - in the Yocto Project development environment, see the - "Cross-Development Toolchain Generation" - section. - For information on setting up a cross-development - environment, see the - "Installing the ADT and Toolchains" - section in the Yocto Project Application Developer's Guide. - - - - - Once built, the SDK installers are written out to the - deploy/sdk folder inside the - Build Directory - as shown in the figure at the beginning of this section. - Several variables exist that help configure these files: - - DEPLOY_DIR: - Points to the deploy - directory. - SDKMACHINE: - Specifies the architecture of the machine - on which the cross-development tools are run to - create packages for the target hardware. - - SDKIMAGE_FEATURES: - Lists the features to include in the "target" part - of the SDK. - - TOOLCHAIN_HOST_TASK: - Lists packages that make up the host - part of the SDK (i.e. the part that runs on - the SDKMACHINE). - When you use - bitbake -c populate_sdk <imagename> - to create the SDK, a set of default packages - apply. - This variable allows you to add more packages. - - TOOLCHAIN_TARGET_TASK: - Lists packages that make up the target part - of the SDK (i.e. the part built for the - target hardware). - - - -
-
BitBake @@ -1190,6 +973,223 @@
+ +
+ Package Feeds + + + When the OpenEmbedded build system generates an image or an SDK, + it gets the packages from a package feed area located in the + Build Directory. + The main + Yocto Project Development Environment + figure shows this package feeds area in the upper-right corner. + + + + This section looks a little closer into the package feeds area used + by the build system. + Here is a more detailed look at the area: + + + + + Package feeds are an intermediary step in the build process. + BitBake generates packages whose type is defined by the + PACKAGE_CLASSES + variable. + Before placing the packages into package feeds, + the build process validates them with generated output quality + assurance checks through the + insane.bbclass + class. + + + + The package feed area resides in + tmp/deploy of the Build Directory. + Folders are created that correspond to the package type + (IPK, DEB, or RPM) created. + Further organization is derived through the value of the + PACKAGE_ARCH + variable for each package. + For example, packages can exist for the i586 or qemux86 + architectures. + The package files themselves reside within the appropriate + architecture folder. + + + + BitBake uses the do_package_write_* task to + place generated packages into the package holding area (e.g. + do_package_write_ipk for IPK packages). + +
+ +
+ Images + + + The images produced by the OpenEmbedded build system + are compressed forms of the + root filesystems that are ready to boot on a target device. + You can see from the main + Yocto Project Development Environment + figure that BitBake output in part consists of images. + This section is going to look more closely at this output: + + + + + For a list of example images that the Yocto Project provides, + the + "Images" chapter. + + + + Images are written out to the + Build Directory + inside the deploy/images folder as shown + in the figure. + This folder contains any files expected to be loaded on the + target device. + The + DEPLOY_DIR + variable points to the deploy directory. + + <kernel-image>: + A kernel binary file. + The KERNEL_IMAGETYPE + variable setting determines the naming scheme for the + kernel image file. + Depending on that variable, the file could begin with + a variety of naming strings. + The deploy/images directory can + contain multiple image files. + <root-filesystem-image>: + Root filesystems for the target device (e.g. + *.ext3 or *.bz2 + files). + The IMAGE_FSTYPES + variable setting determines the root filesystem image + type. + The deploy/images directory can + contain multiple root filesystems. + <kernel-modules>: + Tarballs that contain all the modules built for the kernel. + Kernel module tarballs exist for legacy purposes and + can be suppressed by setting the + MODULE_TARBALL_DEPLOY + variable to "0". + The deploy/images directory can + contain multiple kernel module tarballs. + + <bootloaders>: + Bootloaders supporting the image, if applicable to the + target machine. + The deploy/images directory can + contain multiple bootloaders. + + <symlinks>: + The deploy/images folder contains + a symbolic link that points to the most recently built file + for each machine. + These links might be useful for external scripts that + need to obtain the latest version of each file. + + + +
+ +
+ Application Development SDK + + + In the overview figure of the + Yocto Project Development Environment + the output labeled "Application Development SDK" represents an + SDK. + This section is going to take a closer look at this output: + + + + + The specific form of this output is a self-extracting + SDK installer (*.sh) that, when run, + installs the SDK, which consists of a cross-development + toolchain, a set of libraries and headers, and an SDK + environment setup script. + Running this installer essentially sets up your + cross-development environment. + You can think of the cross-toolchain as the "host" + part because it runs on the SDK machine. + You can think of the libraries and headers as the "target" + part because they are built for the target hardware. + The setup script is added so that you can initialize the + environment before using the tools. + + + + + The Yocto Project supports several methods by which you can + set up this cross-development environment. + These methods include downloading pre-built SDK installers, + building and installing your own SDK installer, or running + an Application Development Toolkit (ADT) installer to + install not just cross-development toolchains + but also additional tools to help in this type of + development. + + + + For background information on cross-development toolchains + in the Yocto Project development environment, see the + "Cross-Development Toolchain Generation" + section. + For information on setting up a cross-development + environment, see the + "Installing the ADT and Toolchains" + section in the Yocto Project Application Developer's Guide. + + + + + Once built, the SDK installers are written out to the + deploy/sdk folder inside the + Build Directory + as shown in the figure at the beginning of this section. + Several variables exist that help configure these files: + + DEPLOY_DIR: + Points to the deploy + directory. + SDKMACHINE: + Specifies the architecture of the machine + on which the cross-development tools are run to + create packages for the target hardware. + + SDKIMAGE_FEATURES: + Lists the features to include in the "target" part + of the SDK. + + TOOLCHAIN_HOST_TASK: + Lists packages that make up the host + part of the SDK (i.e. the part that runs on + the SDKMACHINE). + When you use + bitbake -c populate_sdk <imagename> + to create the SDK, a set of default packages + apply. + This variable allows you to add more packages. + + TOOLCHAIN_TARGET_TASK: + Lists packages that make up the target part + of the SDK (i.e. the part built for the + target hardware). + + + +
-- cgit v1.2.3-54-g00ecf