diff options
| -rw-r--r-- | documentation/ref-manual/technical-details.xml | 434 |
1 files changed, 217 insertions, 217 deletions
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml index 4a6c3b2..bfab8a6 100644 --- a/documentation/ref-manual/technical-details.xml +++ b/documentation/ref-manual/technical-details.xml @@ -743,223 +743,6 @@ </section> </section> - <section id="package-feeds-dev-environment"> - <title>Package Feeds</title> - - <para> - When the OpenEmbedded build system generates an image or an SDK, - it gets the packages from a package feed area located in the - <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>. - The main - <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link> - figure shows this package feeds area in the upper-right corner. - </para> - - <para> - 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: - <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" /> - </para> - - <para> - Package feeds are an intermediary step in the build process. - BitBake generates packages whose type is defined by the - <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link> - variable. - Before placing the packages into package feeds, - the build process validates them with generated output quality - assurance checks through the - <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link> - class. - </para> - - <para> - The package feed area resides in - <filename>tmp/deploy</filename> 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 - <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link> - 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. - </para> - - <para> - BitBake uses the <filename>do_package_write_*</filename> task to - place generated packages into the package holding area (e.g. - <filename>do_package_write_ipk</filename> for IPK packages). - </para> - </section> - - <section id='images-dev-environment'> - <title>Images</title> - - <para> - 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 - <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link> - figure that BitBake output in part consists of images. - This section is going to look more closely at this output: - <imagedata fileref="figures/images.png" align="center" width="6in" depth="5in" /> - </para> - - <para> - For a list of example images that the Yocto Project provides, - the - "<link linkend='ref-images'>Images</link>" chapter. - </para> - - <para> - Images are written out to the - <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> - inside the <filename>deploy/images</filename> folder as shown - in the figure. - This folder contains any files expected to be loaded on the - target device. - The - <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link> - variable points to the <filename>deploy</filename> directory. - <itemizedlist> - <listitem><para><filename><kernel-image></filename>: - A kernel binary file. - The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link> - 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 <filename>deploy/images</filename> directory can - contain multiple image files.</para></listitem> - <listitem><para><filename><root-filesystem-image></filename>: - Root filesystems for the target device (e.g. - <filename>*.ext3</filename> or <filename>*.bz2</filename> - files). - The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link> - variable setting determines the root filesystem image - type. - The <filename>deploy/images</filename> directory can - contain multiple root filesystems.</para></listitem> - <listitem><para><filename><kernel-modules></filename>: - Tarballs that contain all the modules built for the kernel. - Kernel module tarballs exist for legacy purposes and - can be suppressed by setting the - <link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link> - variable to "0". - The <filename>deploy/images</filename> directory can - contain multiple kernel module tarballs. - </para></listitem> - <listitem><para><filename><bootloaders></filename>: - Bootloaders supporting the image, if applicable to the - target machine. - The <filename>deploy/images</filename> directory can - contain multiple bootloaders. - </para></listitem> - <listitem><para><filename><symlinks></filename>: - The <filename>deploy/images</filename> 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. - </para></listitem> - </itemizedlist> - </para> - </section> - - <section id='sdk-dev-environment'> - <title>Application Development SDK</title> - - <para> - In the overview figure of the - <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link> - the output labeled "Application Development SDK" represents an - SDK. - This section is going to take a closer look at this output: - <imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" /> - </para> - - <para> - The specific form of this output is a self-extracting - SDK installer (<filename>*.sh</filename>) 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. - </para> - - <note> - <para> - 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. - </para> - - <para> - For background information on cross-development toolchains - in the Yocto Project development environment, see the - "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>" - section. - For information on setting up a cross-development - environment, see the - "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>" - section in the Yocto Project Application Developer's Guide. - </para> - </note> - - <para> - Once built, the SDK installers are written out to the - <filename>deploy/sdk</filename> folder inside the - <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> - as shown in the figure at the beginning of this section. - Several variables exist that help configure these files: - <itemizedlist> - <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>: - Points to the <filename>deploy</filename> - directory.</para></listitem> - <listitem><para><link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>: - Specifies the architecture of the machine - on which the cross-development tools are run to - create packages for the target hardware. - </para></listitem> - <listitem><para><link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link>: - Lists the features to include in the "target" part - of the SDK. - </para></listitem> - <listitem><para><link linkend='var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></link>: - Lists packages that make up the host - part of the SDK (i.e. the part that runs on - the <filename>SDKMACHINE</filename>). - When you use - <filename>bitbake -c populate_sdk <imagename></filename> - to create the SDK, a set of default packages - apply. - This variable allows you to add more packages. - </para></listitem> - <listitem><para><link linkend='var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></link>: - Lists packages that make up the target part - of the SDK (i.e. the part built for the - target hardware). - </para></listitem> - </itemizedlist> - </para> - </section> - <section id='bitbake-dev-environment'> <title>BitBake</title> @@ -1190,6 +973,223 @@ </para> </section> </section> + + <section id="package-feeds-dev-environment"> + <title>Package Feeds</title> + + <para> + When the OpenEmbedded build system generates an image or an SDK, + it gets the packages from a package feed area located in the + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>. + The main + <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link> + figure shows this package feeds area in the upper-right corner. + </para> + + <para> + 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: + <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" /> + </para> + + <para> + Package feeds are an intermediary step in the build process. + BitBake generates packages whose type is defined by the + <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link> + variable. + Before placing the packages into package feeds, + the build process validates them with generated output quality + assurance checks through the + <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link> + class. + </para> + + <para> + The package feed area resides in + <filename>tmp/deploy</filename> 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 + <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link> + 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. + </para> + + <para> + BitBake uses the <filename>do_package_write_*</filename> task to + place generated packages into the package holding area (e.g. + <filename>do_package_write_ipk</filename> for IPK packages). + </para> + </section> + + <section id='images-dev-environment'> + <title>Images</title> + + <para> + 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 + <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link> + figure that BitBake output in part consists of images. + This section is going to look more closely at this output: + <imagedata fileref="figures/images.png" align="center" width="6in" depth="5in" /> + </para> + + <para> + For a list of example images that the Yocto Project provides, + the + "<link linkend='ref-images'>Images</link>" chapter. + </para> + + <para> + Images are written out to the + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> + inside the <filename>deploy/images</filename> folder as shown + in the figure. + This folder contains any files expected to be loaded on the + target device. + The + <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link> + variable points to the <filename>deploy</filename> directory. + <itemizedlist> + <listitem><para><filename><kernel-image></filename>: + A kernel binary file. + The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link> + 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 <filename>deploy/images</filename> directory can + contain multiple image files.</para></listitem> + <listitem><para><filename><root-filesystem-image></filename>: + Root filesystems for the target device (e.g. + <filename>*.ext3</filename> or <filename>*.bz2</filename> + files). + The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link> + variable setting determines the root filesystem image + type. + The <filename>deploy/images</filename> directory can + contain multiple root filesystems.</para></listitem> + <listitem><para><filename><kernel-modules></filename>: + Tarballs that contain all the modules built for the kernel. + Kernel module tarballs exist for legacy purposes and + can be suppressed by setting the + <link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link> + variable to "0". + The <filename>deploy/images</filename> directory can + contain multiple kernel module tarballs. + </para></listitem> + <listitem><para><filename><bootloaders></filename>: + Bootloaders supporting the image, if applicable to the + target machine. + The <filename>deploy/images</filename> directory can + contain multiple bootloaders. + </para></listitem> + <listitem><para><filename><symlinks></filename>: + The <filename>deploy/images</filename> 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. + </para></listitem> + </itemizedlist> + </para> + </section> + + <section id='sdk-dev-environment'> + <title>Application Development SDK</title> + + <para> + In the overview figure of the + <link linkend='a-closer-look-at-the-yocto-project-development-environment'>Yocto Project Development Environment</link> + the output labeled "Application Development SDK" represents an + SDK. + This section is going to take a closer look at this output: + <imagedata fileref="figures/sdk.png" align="center" width="5in" depth="4in" /> + </para> + + <para> + The specific form of this output is a self-extracting + SDK installer (<filename>*.sh</filename>) 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. + </para> + + <note> + <para> + 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. + </para> + + <para> + For background information on cross-development toolchains + in the Yocto Project development environment, see the + "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>" + section. + For information on setting up a cross-development + environment, see the + "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>" + section in the Yocto Project Application Developer's Guide. + </para> + </note> + + <para> + Once built, the SDK installers are written out to the + <filename>deploy/sdk</filename> folder inside the + <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> + as shown in the figure at the beginning of this section. + Several variables exist that help configure these files: + <itemizedlist> + <listitem><para><link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>: + Points to the <filename>deploy</filename> + directory.</para></listitem> + <listitem><para><link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>: + Specifies the architecture of the machine + on which the cross-development tools are run to + create packages for the target hardware. + </para></listitem> + <listitem><para><link linkend='var-SDKIMAGE_FEATURES'><filename>SDKIMAGE_FEATURES</filename></link>: + Lists the features to include in the "target" part + of the SDK. + </para></listitem> + <listitem><para><link linkend='var-TOOLCHAIN_HOST_TASK'><filename>TOOLCHAIN_HOST_TASK</filename></link>: + Lists packages that make up the host + part of the SDK (i.e. the part that runs on + the <filename>SDKMACHINE</filename>). + When you use + <filename>bitbake -c populate_sdk <imagename></filename> + to create the SDK, a set of default packages + apply. + This variable allows you to add more packages. + </para></listitem> + <listitem><para><link linkend='var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></link>: + Lists packages that make up the target part + of the SDK (i.e. the part built for the + target hardware). + </para></listitem> + </itemizedlist> + </para> + </section> </section> <section id="cross-development-toolchain-generation"> |
