sdk-manual: Updated SDK workflow

A new command devtool finish has superceded the final commands
in the SDK workflow.  I updated the two figures (add and modify)
to reflect this new flow.  I also updated the ordered number list
to match reality.

(From yocto-docs rev: 0ba31e730cd748d06eab8d46b38764cda5c4e3bd)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2016-09-13 18:05:31 -07:00 committed by Richard Purdie
parent 6cecded9ef
commit aba386b92c
4 changed files with 96 additions and 73 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 175 KiB

After

Width:  |  Height:  |  Size: 174 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 143 KiB

After

Width:  |  Height:  |  Size: 160 KiB

View File

@ -384,12 +384,15 @@
<para> <para>
You can explicitly control whether or not to include the toolchain You can explicitly control whether or not to include the toolchain
when you build and SDK by setting the when you build an SDK by setting the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN'><filename>SDK_INCLUDE_TOOLCHAIN</filename></ulink> <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN'><filename>SDK_INCLUDE_TOOLCHAIN</filename></ulink>
variable. variable to "1".
When you set this variable to "1", you cause the toolchain to be In particular, it is useful to include the toolchain when you
included even when <filename>SDK_EXT_TYPE</filename> is set to have set <filename>SDK_EXT_TYPE</filename> to
"minimal". "minimal", which by default, excludes the toolchain.
Also, it is helpful if you are building a small SDK for use with
an IDE, such as Eclipse, or some other tool where you do not want
to take extra steps to install a toolchain.
</para> </para>
</section> </section>
</appendix> </appendix>

View File

@ -343,42 +343,40 @@
However, <filename>devtool</filename> does not provide a However, <filename>devtool</filename> does not provide a
specific command that allows you to do this. specific command that allows you to do this.
</para></listitem> </para></listitem>
<listitem><para><emphasis>Optionally Update the Recipe With Patch Files</emphasis>: <listitem><para>
Once you are satisfied with the recipe, if you have made <emphasis>Finish Your Work With the Recipe</emphasis>:
any changes to the source tree that you want to have The <filename>devtool finish</filename> command creates
applied by the recipe, you need to generate patches any patches corresponding to commits in the local
from those changes. Git repository, moves the new recipe to a more permanent
You do this before moving the recipe layer, and then resets the recipe so that the recipe is
to its final layer and cleaning up the workspace area built normally rather than from the workspace.
<filename>devtool</filename> uses. <literallayout class='monospaced'>
This optional step is especially relevant if you are $ devtool finish <replaceable>recipe layer</replaceable>
using or adding third-party software.</para> </literallayout></para>
<para>To convert commits created using Git to patch files,
use the <filename>devtool update-recipe</filename> command. <para>Part of the <filename>devtool finish</filename>
command converts commits created using Git to patch files.
<note> <note>
Any changes you want to turn into patches must be Any changes you want to turn into patches must be
committed to the Git repository in the source tree. committed to the Git repository in the source tree.
</note></para>
<para>As mentioned, the <filename>devtool finish</filename>
command moves the final recipe to its permanent layer.
</para>
<para>As a final process of the
<filename>devtool finish</filename> command, the state
of the standard layers and the upstream source is
restored so that you can build the recipe from those
areas rather than the workspace.
<note>
You can use the <filename>devtool reset</filename>
command to put things back should you decide you
do not want to proceed with your work.
If you do use this command, realize that the source
tree is preserved.
</note> </note>
<literallayout class='monospaced'>
$ devtool update-recipe <replaceable>recipe</replaceable>
</literallayout>
</para></listitem>
<listitem><para><emphasis>Move the Recipe to its Permanent Layer</emphasis>:
Before cleaning up the workspace, you need to move the
final recipe to its permanent layer.
You must do this before using the
<filename>devtool reset</filename> command if you want to
retain the recipe.
</para></listitem>
<listitem><para><emphasis>Reset the Recipe</emphasis>:
As a final step, you can restore the state such that
standard layers and the upstream source is used to build
the recipe rather than data in the workspace.
To reset the recipe, use the <filename>devtool reset</filename>
command:
<literallayout class='monospaced'>
$ devtool reset <replaceable>recipe</replaceable>
</literallayout>
</para></listitem> </para></listitem>
</orderedlist> </orderedlist>
</para> </para>
@ -569,42 +567,43 @@
However, <filename>devtool</filename> does not provide a However, <filename>devtool</filename> does not provide a
specific command that allows you to do this. specific command that allows you to do this.
</para></listitem> </para></listitem>
<listitem><para><emphasis>Optionally Create Patch Files for Your Changes</emphasis>: <listitem><para>
After you have debugged your changes, you can <emphasis>Finish Your Work With the Recipe</emphasis>:
use <filename>devtool update-recipe</filename> to The <filename>devtool finish</filename> command creates
generate patch files for all the commits you have any patches corresponding to commits in the local
made. Git repository and then resets the recipe so that the
<note> recipe is built normally rather than from the workspace.
Patch files are generated only for changes
you have committed.
</note>
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ devtool update-recipe <replaceable>recipe</replaceable> $ devtool finish <replaceable>recipe layer</replaceable>
</literallayout> </literallayout></para>
By default, the
<filename>devtool update-recipe</filename> command <para>Part of the <filename>devtool finish</filename>
creates the patch files in a folder named the same command converts commits created using Git to patch files.
as the recipe beneath the folder in which the recipe
resides, and updates the recipe's
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
statement to point to the generated patch files.
<note> <note>
You can use the Any changes you want to turn into patches must be
"--append <replaceable>LAYERDIR</replaceable>" committed to the Git repository in the source tree.
option to cause the command to create append files </note></para>
in a specific layer rather than the default
recipe layer. <para>Because there is no need to move the recipe,
<filename>devtool finish</filename> either updates the
original recipe in the original layer or the command
creates a <filename>.bbappend</filename> in a different
layer as provided by <replaceable>layer</replaceable>.
</para>
<para>As a final process of the
<filename>devtool finish</filename> command, the state
of the standard layers and the upstream source is
restored so that you can build the recipe from those
areas rather than the workspace.
<note>
You can use the <filename>devtool reset</filename>
command to put things back should you decide you
do not want to proceed with your work.
If you do use this command, realize that the source
tree is preserved.
</note> </note>
</para></listitem> </para></listitem>
<listitem><para><emphasis>Restore the Workspace</emphasis>:
The <filename>devtool reset</filename> restores the
state so that standard layers and upstream sources are
used to build the recipe rather than what is in the
workspace.
<literallayout class='monospaced'>
$ devtool reset <replaceable>recipe</replaceable>
</literallayout>
</para></listitem>
</orderedlist> </orderedlist>
</para> </para>
</section> </section>
@ -641,8 +640,7 @@
Binary package (i.e. "-b" option) Binary package (i.e. "-b" option)
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
Node.js module through Node.js module
<filename>npm</filename>
</para></listitem> </para></listitem>
<listitem><para> <listitem><para>
Python modules that use <filename>setuptools</filename> Python modules that use <filename>setuptools</filename>
@ -921,8 +919,15 @@
<title>Adding Node.js Modules</title> <title>Adding Node.js Modules</title>
<para> <para>
You can use the <filename>devtool add</filename> command in the You can use the <filename>devtool add</filename> command two
following form to add Node.js modules: different ways to add Node.js modules: 1) Through
<filename>npm</filename> and, 2) from a repository or local
source.
</para>
<para>
Use the following form to add Node.js modules through
<filename>npm</filename>:
<literallayout class='monospaced'> <literallayout class='monospaced'>
$ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1" $ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1"
</literallayout> </literallayout>
@ -955,6 +960,21 @@
</itemizedlist> </itemizedlist>
</note> </note>
</para> </para>
<para>
As mentioned earlier, you can also add Node.js modules
directly from a repository or local source tree.
To add modules this way, use <filename>devtool add</filename> in
the following form:
<literallayout class='monospaced'>
$ devtool add https://github.com/diversario/node-ssdp
</literallayout>
In this example, <filename>devtool</filename> fetches the specified
Git repository, detects that the code is Node.js code, fetches
dependencies using <filename>npm</filename>, and sets
<ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
accordingly.
</para>
</section> </section>
</section> </section>