</question>
<answer>
<para>
- Because you can use the same set of recipes to create output of
- various formats, the output of an OpenEmbedded build depends on
+ Because you can use the same set of recipes to create output of
+ various formats, the output of an OpenEmbedded build depends on
how you start it.
- Usually, the output is a flashable image ready for the target
+ Usually, the output is a flashable image ready for the target
device.
</para>
</answer>
</question>
<answer>
<para>
- The OpenEmbedded build system can build packages in various
- formats such as IPK for OPKG, Debian package
+ The OpenEmbedded build system can build packages in various
+ formats such as IPK for OPKG, Debian package
(<filename>.deb</filename>), or RPM.
- You can then upgrade the packages using the package tools on
- the device, much like on a desktop distribution such as
- Ubuntu or Fedora.
+ You can then upgrade the packages using the package tools on
+ the device, much like on a desktop distribution such as
+ Ubuntu or Fedora.
However, package management on the target is entirely optional.
</para>
</answer>
<note>
<para>For information on distributions that the Yocto Project
- uses during validation, see the
+ uses during validation, see the
<ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>
Wiki page.</para>
<para>For notes about using the Yocto Project on a RHEL 4-based
</filename> = "0" in the <filename>.bb</filename> file but make sure the package is
manually marked as
machine-specific for the case that needs it.
- The code that handles
- <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in
+ The code that handles
+ <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in
the <filename>meta/classes/base.bbclass</filename> file.
</para>
</answer>
http_proxy = http://proxy.yoyodyne.com:18023/
ftp_proxy = http://proxy.yoyodyne.com:18023/
</literallayout>
- The Yocto Project also includes a
- <filename>site.conf.sample</filename> file that shows how to
+ The Yocto Project also includes a
+ <filename>site.conf.sample</filename> file that shows how to
configure CVS and Git proxy servers if needed.
</para>
</answer>
</question>
<answer>
<para>
- If the same build is failing in totally different and random
+ If the same build is failing in totally different and random
ways, the most likely explanation is:
<itemizedlist>
- <listitem><para>The hardware you are running the build on
+ <listitem><para>The hardware you are running the build on
has some problem.</para></listitem>
- <listitem><para>You are running the build under
- virtualization, in which case the virtualization
- probably has bugs.</para></listitem>
+ <listitem><para>You are running the build under
+ virtualization, in which case the virtualization
+ probably has bugs.</para></listitem>
</itemizedlist>
- The OpenEmbedded build system processes a massive amount of
- data that causes lots of network, disk and CPU activity and
+ The OpenEmbedded build system processes a massive amount of
+ data that causes 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
+ True random failures have always been traced back to hardware
or virtualization issues.
</para>
</answer>
</question>
<answer>
<para>
- This is a difficult question and you need to consult your lawyer
+ This is a difficult question and you need to consult your lawyer
for the answer for your specific case.
- It is worth bearing in mind that for GPL compliance, there needs
- to be enough information shipped to allow someone else to
+ It is worth bearing in mind that for GPL compliance, there needs
+ to be enough information shipped to allow someone else to
rebuild and produce the same end result you are shipping.
- This means sharing the source code, any patches applied to it,
- and also any configuration information about how that package
+ This means sharing the source code, any patches applied to it,
+ and also any configuration information about how that package
was configured and built.
</para>
<para>
- You can find more information on licensing in the
+ You can find more information on licensing in the
"<ulink url='&YOCTO_DOCS_DEV_URL;#licensing'>Licensing</ulink>"
and "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
sections, both of which are in the Yocto Project Development
"<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
section in the Yocto Project Board Support Packages (BSP)
Developer's Guide.
- Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to
+ Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to
one as follows:
<literallayout class='monospaced'>
HAVE_TOUCHSCREEN=1
file.
See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
section in the Yocto Project Board Support Packages (BSP)
- Developer's Guide for information on creating these types of
+ Developer's Guide for information on creating these types of
miscellaneous recipe files.
</para>
<para>
</question>
<answer>
<para>
- By default, the OpenEmbedded build system creates images
+ By default, the OpenEmbedded build system creates images
that are 1.3 times the size of the populated root filesystem.
- To affect the image size, you need to set various
+ To affect the image size, you need to set various
configurations:
<itemizedlist>
<listitem><para><emphasis>Image Size:</emphasis>
- The OpenEmbedded build system uses the
+ The OpenEmbedded build system uses the
<link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link>
- variable to define the size of the image in Kbytes.
- The build system determines the size by taking into
+ variable to define the size of the image in Kbytes.
+ The build system determines the size by taking into
account the initial root filesystem size before any
- modifications such as requested size for the image and
- any requested additional free disk space to be
+ modifications such as requested size for the image and
+ any requested additional free disk space to be
added to the image.</para></listitem>
<listitem><para><emphasis>Overhead:</emphasis>
- Use the
+ Use the
<link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
- variable to define the multiplier that the build system
- applies to the initial image size, which is 1.3 by
+ variable to define the multiplier that the build system
+ applies to the initial image size, which is 1.3 by
default.</para></listitem>
<listitem><para><emphasis>Additional Free Space:</emphasis>
- Use the
+ Use the
<link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
variable to add additional free space to the image.
The build system adds this space to the image after
- it determines its
+ it determines its
<filename>IMAGE_ROOTFS_SIZE</filename>.
</para></listitem>
</itemizedlist>
</question>
<answer>
<para>
- The Yocto Project team has tried to do this before but too
- many of the tools the OpenEmbedded build system depends on,
- such as <filename>autoconf</filename>, break when they find
+ The Yocto Project team has tried to do this before but too
+ many of the tools the OpenEmbedded build system depends on,
+ such as <filename>autoconf</filename>, break when they find
spaces in pathnames.
- Until that situation changes, the team will not support spaces
+ Until that situation changes, the team will not support spaces
in pathnames.
</para>
</answer>
<para>
The toolchain configuration is very flexible and customizable.
It is primarily controlled with the
- <filename><link linkend='var-TCMODE'>TCMODE</link></filename>
+ <filename><link linkend='var-TCMODE'>TCMODE</link></filename>
variable.
- This variable controls which <filename>tcmode-*.inc</filename>
- file to include from the
- <filename>meta/conf/distro/include</filename> directory within
+ This variable controls which <filename>tcmode-*.inc</filename>
+ file to include from the
+ <filename>meta/conf/distro/include</filename> directory within
the
<ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
</para>
The default value of <filename>TCMODE</filename> is "default"
(i.e. <filename>tcmode-default.inc</filename>).
However, other patterns are accepted.
- In particular, "external-*" refers to external toolchains of
- which there are some basic examples included in the
+ In particular, "external-*" refers to external toolchains of
+ which there are some basic examples included in the
OpenEmbedded Core (<filename>meta</filename>).
- You can use your own custom toolchain definition in your own
- layer (or as defined in the <filename>local.conf</filename>
+ You can use your own custom toolchain definition in your own
+ layer (or as defined in the <filename>local.conf</filename>
file) at the location
<filename>conf/distro/include/tcmode-*.inc</filename>.
</para>
<para>
- In addition to the toolchain configuration, you also need a
+ In addition to the toolchain configuration, you also need a
corresponding toolchain recipe file.
- This recipe file needs to package up any pre-built objects in
- the toolchain such as <filename>libgcc</filename>,
- <filename>libstdcc++</filename>, any locales, and
+ This recipe file needs to package up any pre-built objects in
+ the toolchain such as <filename>libgcc</filename>,
+ <filename>libstdcc++</filename>, any locales, and
<filename>libc</filename>.
- An example is the
- <filename>external-sourcery-toolchain.bb</filename>, which is
- located in <filename>meta/recipes-core/meta/</filename> within
+ An example is the
+ <filename>external-sourcery-toolchain.bb</filename>, which is
+ located in <filename>meta/recipes-core/meta/</filename> within
the Source Directory.
</para>
<para>
- For information on installing and using cross-development
- toolchains, see the
+ For information on installing and using cross-development
+ toolchains, 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.
+ For general information on cross-development toolchains, see
+ the
+ "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+ section.
</para>
</answer>
</qandaentry>
<literallayout class='monospaced'>
BB_FETCH_PREMIRRORONLY = "1"
</literallayout>
- This statement limits the build system to pulling source
+ This statement limits the build system to pulling source
from the <filename>PREMIRRORS</filename> only.
Again, this technique is useful for reproducing builds.
</para>
<literallayout class='monospaced'>
BB_GENERATE_MIRROR_TARBALLS = "1"
</literallayout>
- This statement tells the build system to generate mirror
+ This statement tells the build system to generate mirror
tarballs.
This technique is useful if you want to create a mirror server.
If not, however, the technique can simply waste time during
<answer>
<para>
Yes - you can easily do this.
- When you use BitBake to build an image, all the build output
- goes into the directory created when you source the
+ When you use BitBake to build an image, all the build output
+ goes into the directory created when you source the
<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
setup script.
By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
</para>
<para>
- Within the Build Directory, is the <filename>tmp</filename>
+ Within the Build Directory, is the <filename>tmp</filename>
directory.
- To remove all the build output yet preserve any source code or
- downloaded files from previous builds, simply remove the
+ To remove all the build output yet preserve any source code or
+ downloaded files from previous builds, simply remove the
<filename>tmp</filename> directory.
</para>
</answer>
projects / thirdparty / openembedded / openembedded-core-contrib.git / commitdiff
