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:
parent
6cecded9ef
commit
aba386b92c
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 |
|
@ -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>
|
||||||
|
|
|
@ -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>
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue