</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>
</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">
projects / thirdparty / openembedded / openembedded-core-contrib.git / commitdiff
