sdk-manual: Applied more review edits to the manual per Eggleton.
(From yocto-docs rev: 8987852ad23e8a4694be55425e2c76bcd4301850) Signed-off-by: Scott Rifenbark <srifenbark@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
b44d9e553a
commit
64241e0dfb
|
@ -95,24 +95,53 @@
|
||||||
<title>Using <filename>devtool</filename> in Your SDK Workflow</title>
|
<title>Using <filename>devtool</filename> in Your SDK Workflow</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
<filename>devtool</filename> helps you easily develop projects whose
|
The cornerstone of the extensible SDK is a command-line tool
|
||||||
build output must be part of an image built using the OpenEmbedded
|
called <filename>devtool</filename>.
|
||||||
build system.
|
This tool provides a number of features that help
|
||||||
|
you build, test and package software within the extensible SDK, and
|
||||||
|
optionally integrate it into an image built by the OpenEmbedded build
|
||||||
|
system.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
These entry points exist that allow you to develop using
|
The <filename>devtool</filename> command line is organized similarly
|
||||||
<filename>devtool</filename>:
|
to
|
||||||
|
<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> in that it has a
|
||||||
|
number of sub-commands for each function.
|
||||||
|
You can run <filename>devtool --help</filename> to see all the
|
||||||
|
commands.
|
||||||
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Two <filename>devtool</filename> subcommands that provide
|
||||||
|
entry-points into development are:
|
||||||
<itemizedlist>
|
<itemizedlist>
|
||||||
<listitem><para><emphasis><filename>devtool add</filename></emphasis>
|
<listitem><para><emphasis><filename>devtool add</filename></emphasis>:
|
||||||
|
Assists in adding new software to be built.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para><emphasis><filename>devtool modify</filename></emphasis>
|
<listitem><para><emphasis><filename>devtool modify</filename></emphasis>:
|
||||||
|
Sets up an environment to enable you to modify the source of
|
||||||
|
an existing component.
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
|
As with the OpenEmbedded build system, "recipes" represent software
|
||||||
|
packages within <filename>devtool</filename>.
|
||||||
|
When you use <filename>devtool add</filename>, a recipe is
|
||||||
|
automatically created.
|
||||||
|
When you use <filename>devtool modify</filename>, the specified
|
||||||
|
existing recipe is used in order to determine where to get the source
|
||||||
|
code and how to patch it.
|
||||||
|
In both cases, an environment is set up so that when you build the
|
||||||
|
recipe a source tree that is under your control is used in order to
|
||||||
|
allow you to make changes to the source as desired.
|
||||||
|
By default, both new recipes and the source go into a "workspace"
|
||||||
|
directory under the SDK.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The remainder of this section presents these workflows.
|
The remainder of this section presents the
|
||||||
|
<filename>devtool add</filename> and
|
||||||
|
<filename>devtool modify</filename> workflows.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<section id='sdk-use-devtool-to-add-an-application'>
|
<section id='sdk-use-devtool-to-add-an-application'>
|
||||||
|
@ -494,9 +523,9 @@
|
||||||
</para></listitem>
|
</para></listitem>
|
||||||
<listitem><para><emphasis>Deploy the Build Output</emphasis>:
|
<listitem><para><emphasis>Deploy the Build Output</emphasis>:
|
||||||
When you use the <filename>devtool build</filename>
|
When you use the <filename>devtool build</filename>
|
||||||
command or <filename>bitbake</filename> to build out your
|
command to build out your recipe, you probably want to see
|
||||||
recipe, you probably want to see if the resulting build
|
if the resulting build output works as expected on target
|
||||||
output works as expected on target hardware.
|
hardware.
|
||||||
<note>
|
<note>
|
||||||
This step assumes you have a previously built
|
This step assumes you have a previously built
|
||||||
image that is already either running in QEMU or
|
image that is already either running in QEMU or
|
||||||
|
|
|
@ -109,7 +109,6 @@
|
||||||
<literallayout class='monospaced'>
|
<literallayout class='monospaced'>
|
||||||
$ chmod +x poky-glibc-x86_64-core-image-sato-i586-toolchain-2.1.sh
|
$ chmod +x poky-glibc-x86_64-core-image-sato-i586-toolchain-2.1.sh
|
||||||
</literallayout>
|
</literallayout>
|
||||||
This example makes the installation script executable.
|
|
||||||
</note>
|
</note>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue