"do_install" tasks.
The <glossterm><link linkend='var-S'>S</link></glossterm> variable defines the
directory containing the source code, which is set to <glossterm><link linkend='var-WORKDIR'>
- WORKDIR</link></glossterm> in this case - the directory Bitbake uses for the build.
+ WORKDIR</link></glossterm> in this case - the directory BitBake uses for the build.
</para>
<programlisting>
DESCRIPTION = "Simple helloworld application"
}
</programlisting>
<para>
- By default, the "helloworld", "helloworld-dbg" and "hellworld-dev"
+ By default, the "helloworld", "helloworld-dbg" and "helloworld-dev"
packages are built.
For information on how to customize the packaging process, see
<link linkend='usingpoky-extend-addpkg-files'>Controlling Package Content</link>.
Applications that use autotools such as <filename>autoconf</filename> and
<filename>automake</filename> require a recipe that has a source archive listed in
<glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> and
- <filename>also inherits autotools</filename>, which instructs Bitbake to use the
+ <filename>also inherits autotools</filename>, which instructs BitBake to use the
<filename>autotools.bbclass</filename> file, which contains the definitions of all the steps
needed to build an autotooled application.
The result of the build is automatically packaged.
<para>
Applications that use GNU <filename>make</filename> also require a recipe that has
the source archive listed in <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm>.
- You do not need to add a <function>do_compile</function> step since by default Bitbake
+ You do not need to add a <function>do_compile</function> step since by default BitBake
starts the <filename>make</filename> command to compile the application.
If you need additional <filename>make</filename> options you should store them in the
<glossterm><link linkend='var-EXTRA_OEMAKE'>EXTRA_OEMAKE</link></glossterm> variable.
- Bitbake passes these options into the <filename>make</filename> GNU invocation.
+ BitBake passes these options into the <filename>make</filename> GNU invocation.
Note that a "do_install" task is still required.
- Otherwise Bitbake runs an empty "do_install" task by default.
+ Otherwise BitBake runs an empty "do_install" task by default.
</para>
<para>
Some applications might require extra parameters to be passed to the compiler.
<section id="usingpoky-changes">
<title>Making and Maintaining Changes</title>
<para>
- Because Poky offers extreme configurability and flexibility, we recognize that people will want
+ Because Poky is extremely configurable and flexible, we recognize that people will want
to extend, configure or optimize Poky for their specific uses.
To best keep pace with future Poky changes we recommend you make controlled changes to Poky.
</para>
</para>
<section id="usingpoky-changes-layers">
- <title>Bitbake Layers</title>
+ <title>BitBake Layers</title>
<para>
Often, people want to extend Poky either by adding packages
or by overriding files contained within Poky to add their own
functionality.
- Bitbake has a powerful mechanism called
+ BitBake has a powerful mechanism called
"layers", which provides a way to handle this extension in a fully
supported and non-invasive fashion.
</para>
</para>
<para>
- Bitbake parses each <filename>conf/layer.conf</filename> file for each layer in BBLAYERS
+ BitBake parses each <filename>conf/layer.conf</filename> file for each layer in BBLAYERS
and adds the recipes, classes and configuration contained within the layer to Poky.
To create your own layer, independent of the main Poky repository,
simply create a directory with a <filename>conf/layer.conf</filename> file and
Note the use of the <glossterm><link linkend='var-LAYERDIR'>LAYERDIR</link></glossterm>
variable with the immediate expansion operator.
The LAYERDIR variable expands to the directory of the current layer and
- requires the immediate expansion operator so that Bitbake does not wait to expand the variable
+ requires the immediate expansion operator so that BitBake does not wait to expand the variable
when it's parsing a different directory.
</para>
<para>
- Bitbake can locate where other bbclass and configuration files are applied through
+ BitBake can locate where other bbclass and configuration files are applied through
the <glossterm><link linkend='var-BBPATH'>BBPATH</link></glossterm>
environment variable.
- For these cases, Bitbake uses the first file with the matching name found in BBPATH.
+ For these cases, BitBake uses the first file with the matching name found in BBPATH.
This is similar to the way the PATH variable is used for binaries.
We recommend, therefore, that you use unique bbclass and configuration file names in your
custom layer.
<para>
The core component of any development effort with Poky is often an
automated build testing framework and an image generation process.
- You can use these core components to check that the metadata is buildable,
+ You can use these core components to check that the metadata can be built,
highlight when commits break the build, and provide up-to-date images that
allow people to test the end result and use it as a base platform for further
development.
This practice allow you to just track the "COPYING" file as long as it is kept up to date.
</para>
<tip>
- If you specify an empty or invalid "md5" parameter, Bitbake returns an md5 mis-match
+ If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match
error and displays the correct "md5" parameter value during the build. The correct parameter
is also captured in the build log.
</tip>
