diff options
author | Scott Rifenbark <srifenbark@gmail.com> | 2016-09-13 18:05:31 -0700 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2016-09-23 15:27:34 +0100 |
commit | aba386b92cb1bd926a69f703587b133363374dee (patch) | |
tree | 72a8b0c555d8149b1ac1f0fbb8c52caec742ed89 /documentation/sdk-manual | |
parent | 6cecded9ef1bd09fb7b89ed28c4268c40272665d (diff) | |
download | poky-aba386b92cb1bd926a69f703587b133363374dee.tar.gz |
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>
Diffstat (limited to 'documentation/sdk-manual')
-rw-r--r-- | documentation/sdk-manual/figures/sdk-devtool-add-flow.png | bin | 179361 -> 177945 bytes | |||
-rw-r--r-- | documentation/sdk-manual/figures/sdk-devtool-modify-flow.png | bin | 146467 -> 164192 bytes | |||
-rw-r--r-- | documentation/sdk-manual/sdk-appendix-customizing.xml | 13 | ||||
-rw-r--r-- | documentation/sdk-manual/sdk-extensible.xml | 156 |
4 files changed, 96 insertions, 73 deletions
diff --git a/documentation/sdk-manual/figures/sdk-devtool-add-flow.png b/documentation/sdk-manual/figures/sdk-devtool-add-flow.png index c09e60e355..985ac331f1 100644 --- a/documentation/sdk-manual/figures/sdk-devtool-add-flow.png +++ b/documentation/sdk-manual/figures/sdk-devtool-add-flow.png | |||
Binary files differ | |||
diff --git a/documentation/sdk-manual/figures/sdk-devtool-modify-flow.png b/documentation/sdk-manual/figures/sdk-devtool-modify-flow.png index cd06c01813..fd684ffbe9 100644 --- a/documentation/sdk-manual/figures/sdk-devtool-modify-flow.png +++ b/documentation/sdk-manual/figures/sdk-devtool-modify-flow.png | |||
Binary files differ | |||
diff --git a/documentation/sdk-manual/sdk-appendix-customizing.xml b/documentation/sdk-manual/sdk-appendix-customizing.xml index 0695707af3..e8a8b8cc9b 100644 --- a/documentation/sdk-manual/sdk-appendix-customizing.xml +++ b/documentation/sdk-manual/sdk-appendix-customizing.xml | |||
@@ -384,12 +384,15 @@ | |||
384 | 384 | ||
385 | <para> | 385 | <para> |
386 | You can explicitly control whether or not to include the toolchain | 386 | You can explicitly control whether or not to include the toolchain |
387 | when you build and SDK by setting the | 387 | when you build an SDK by setting the |
388 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN'><filename>SDK_INCLUDE_TOOLCHAIN</filename></ulink> | 388 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN'><filename>SDK_INCLUDE_TOOLCHAIN</filename></ulink> |
389 | variable. | 389 | variable to "1". |
390 | When you set this variable to "1", you cause the toolchain to be | 390 | In particular, it is useful to include the toolchain when you |
391 | included even when <filename>SDK_EXT_TYPE</filename> is set to | 391 | have set <filename>SDK_EXT_TYPE</filename> to |
392 | "minimal". | 392 | "minimal", which by default, excludes the toolchain. |
393 | Also, it is helpful if you are building a small SDK for use with | ||
394 | an IDE, such as Eclipse, or some other tool where you do not want | ||
395 | to take extra steps to install a toolchain. | ||
393 | </para> | 396 | </para> |
394 | </section> | 397 | </section> |
395 | </appendix> | 398 | </appendix> |
diff --git a/documentation/sdk-manual/sdk-extensible.xml b/documentation/sdk-manual/sdk-extensible.xml index 9b788622f9..8f64745d52 100644 --- a/documentation/sdk-manual/sdk-extensible.xml +++ b/documentation/sdk-manual/sdk-extensible.xml | |||
@@ -343,42 +343,40 @@ | |||
343 | However, <filename>devtool</filename> does not provide a | 343 | However, <filename>devtool</filename> does not provide a |
344 | specific command that allows you to do this. | 344 | specific command that allows you to do this. |
345 | </para></listitem> | 345 | </para></listitem> |
346 | <listitem><para><emphasis>Optionally Update the Recipe With Patch Files</emphasis>: | 346 | <listitem><para> |
347 | Once you are satisfied with the recipe, if you have made | 347 | <emphasis>Finish Your Work With the Recipe</emphasis>: |
348 | any changes to the source tree that you want to have | 348 | The <filename>devtool finish</filename> command creates |
349 | applied by the recipe, you need to generate patches | 349 | any patches corresponding to commits in the local |
350 | from those changes. | 350 | Git repository, moves the new recipe to a more permanent |
351 | You do this before moving the recipe | 351 | layer, and then resets the recipe so that the recipe is |
352 | to its final layer and cleaning up the workspace area | 352 | built normally rather than from the workspace. |
353 | <filename>devtool</filename> uses. | 353 | <literallayout class='monospaced'> |
354 | This optional step is especially relevant if you are | 354 | $ devtool finish <replaceable>recipe layer</replaceable> |
355 | using or adding third-party software.</para> | 355 | </literallayout></para> |
356 | <para>To convert commits created using Git to patch files, | 356 | |
357 | use the <filename>devtool update-recipe</filename> command. | 357 | <para>Part of the <filename>devtool finish</filename> |
358 | command converts commits created using Git to patch files. | ||
358 | <note> | 359 | <note> |
359 | Any changes you want to turn into patches must be | 360 | Any changes you want to turn into patches must be |
360 | committed to the Git repository in the source tree. | 361 | committed to the Git repository in the source tree. |
362 | </note></para> | ||
363 | |||
364 | <para>As mentioned, the <filename>devtool finish</filename> | ||
365 | command moves the final recipe to its permanent layer. | ||
366 | </para> | ||
367 | |||
368 | <para>As a final process of the | ||
369 | <filename>devtool finish</filename> command, the state | ||
370 | of the standard layers and the upstream source is | ||
371 | restored so that you can build the recipe from those | ||
372 | areas rather than the workspace. | ||
373 | <note> | ||
374 | You can use the <filename>devtool reset</filename> | ||
375 | command to put things back should you decide you | ||
376 | do not want to proceed with your work. | ||
377 | If you do use this command, realize that the source | ||
378 | tree is preserved. | ||
361 | </note> | 379 | </note> |
362 | <literallayout class='monospaced'> | ||
363 | $ devtool update-recipe <replaceable>recipe</replaceable> | ||
364 | </literallayout> | ||
365 | </para></listitem> | ||
366 | <listitem><para><emphasis>Move the Recipe to its Permanent Layer</emphasis>: | ||
367 | Before cleaning up the workspace, you need to move the | ||
368 | final recipe to its permanent layer. | ||
369 | You must do this before using the | ||
370 | <filename>devtool reset</filename> command if you want to | ||
371 | retain the recipe. | ||
372 | </para></listitem> | ||
373 | <listitem><para><emphasis>Reset the Recipe</emphasis>: | ||
374 | As a final step, you can restore the state such that | ||
375 | standard layers and the upstream source is used to build | ||
376 | the recipe rather than data in the workspace. | ||
377 | To reset the recipe, use the <filename>devtool reset</filename> | ||
378 | command: | ||
379 | <literallayout class='monospaced'> | ||
380 | $ devtool reset <replaceable>recipe</replaceable> | ||
381 | </literallayout> | ||
382 | </para></listitem> | 380 | </para></listitem> |
383 | </orderedlist> | 381 | </orderedlist> |
384 | </para> | 382 | </para> |
@@ -569,42 +567,43 @@ | |||
569 | However, <filename>devtool</filename> does not provide a | 567 | However, <filename>devtool</filename> does not provide a |
570 | specific command that allows you to do this. | 568 | specific command that allows you to do this. |
571 | </para></listitem> | 569 | </para></listitem> |
572 | <listitem><para><emphasis>Optionally Create Patch Files for Your Changes</emphasis>: | 570 | <listitem><para> |
573 | After you have debugged your changes, you can | 571 | <emphasis>Finish Your Work With the Recipe</emphasis>: |
574 | use <filename>devtool update-recipe</filename> to | 572 | The <filename>devtool finish</filename> command creates |
575 | generate patch files for all the commits you have | 573 | any patches corresponding to commits in the local |
576 | made. | 574 | Git repository and then resets the recipe so that the |
577 | <note> | 575 | recipe is built normally rather than from the workspace. |
578 | Patch files are generated only for changes | ||
579 | you have committed. | ||
580 | </note> | ||
581 | <literallayout class='monospaced'> | 576 | <literallayout class='monospaced'> |
582 | $ devtool update-recipe <replaceable>recipe</replaceable> | 577 | $ devtool finish <replaceable>recipe layer</replaceable> |
583 | </literallayout> | 578 | </literallayout></para> |
584 | By default, the | 579 | |
585 | <filename>devtool update-recipe</filename> command | 580 | <para>Part of the <filename>devtool finish</filename> |
586 | creates the patch files in a folder named the same | 581 | command converts commits created using Git to patch files. |
587 | as the recipe beneath the folder in which the recipe | 582 | <note> |
588 | resides, and updates the recipe's | 583 | Any changes you want to turn into patches must be |
589 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> | 584 | committed to the Git repository in the source tree. |
590 | statement to point to the generated patch files. | 585 | </note></para> |
586 | |||
587 | <para>Because there is no need to move the recipe, | ||
588 | <filename>devtool finish</filename> either updates the | ||
589 | original recipe in the original layer or the command | ||
590 | creates a <filename>.bbappend</filename> in a different | ||
591 | layer as provided by <replaceable>layer</replaceable>. | ||
592 | </para> | ||
593 | |||
594 | <para>As a final process of the | ||
595 | <filename>devtool finish</filename> command, the state | ||
596 | of the standard layers and the upstream source is | ||
597 | restored so that you can build the recipe from those | ||
598 | areas rather than the workspace. | ||
591 | <note> | 599 | <note> |
592 | You can use the | 600 | You can use the <filename>devtool reset</filename> |
593 | "--append <replaceable>LAYERDIR</replaceable>" | 601 | command to put things back should you decide you |
594 | option to cause the command to create append files | 602 | do not want to proceed with your work. |
595 | in a specific layer rather than the default | 603 | If you do use this command, realize that the source |
596 | recipe layer. | 604 | tree is preserved. |
597 | </note> | 605 | </note> |
598 | </para></listitem> | 606 | </para></listitem> |
599 | <listitem><para><emphasis>Restore the Workspace</emphasis>: | ||
600 | The <filename>devtool reset</filename> restores the | ||
601 | state so that standard layers and upstream sources are | ||
602 | used to build the recipe rather than what is in the | ||
603 | workspace. | ||
604 | <literallayout class='monospaced'> | ||
605 | $ devtool reset <replaceable>recipe</replaceable> | ||
606 | </literallayout> | ||
607 | </para></listitem> | ||
608 | </orderedlist> | 607 | </orderedlist> |
609 | </para> | 608 | </para> |
610 | </section> | 609 | </section> |
@@ -641,8 +640,7 @@ | |||
641 | Binary package (i.e. "-b" option) | 640 | Binary package (i.e. "-b" option) |
642 | </para></listitem> | 641 | </para></listitem> |
643 | <listitem><para> | 642 | <listitem><para> |
644 | Node.js module through | 643 | Node.js module |
645 | <filename>npm</filename> | ||
646 | </para></listitem> | 644 | </para></listitem> |
647 | <listitem><para> | 645 | <listitem><para> |
648 | Python modules that use <filename>setuptools</filename> | 646 | Python modules that use <filename>setuptools</filename> |
@@ -921,8 +919,15 @@ | |||
921 | <title>Adding Node.js Modules</title> | 919 | <title>Adding Node.js Modules</title> |
922 | 920 | ||
923 | <para> | 921 | <para> |
924 | You can use the <filename>devtool add</filename> command in the | 922 | You can use the <filename>devtool add</filename> command two |
925 | following form to add Node.js modules: | 923 | different ways to add Node.js modules: 1) Through |
924 | <filename>npm</filename> and, 2) from a repository or local | ||
925 | source. | ||
926 | </para> | ||
927 | |||
928 | <para> | ||
929 | Use the following form to add Node.js modules through | ||
930 | <filename>npm</filename>: | ||
926 | <literallayout class='monospaced'> | 931 | <literallayout class='monospaced'> |
927 | $ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1" | 932 | $ devtool add "npm://registry.npmjs.org;name=forever;version=0.15.1" |
928 | </literallayout> | 933 | </literallayout> |
@@ -955,6 +960,21 @@ | |||
955 | </itemizedlist> | 960 | </itemizedlist> |
956 | </note> | 961 | </note> |
957 | </para> | 962 | </para> |
963 | |||
964 | <para> | ||
965 | As mentioned earlier, you can also add Node.js modules | ||
966 | directly from a repository or local source tree. | ||
967 | To add modules this way, use <filename>devtool add</filename> in | ||
968 | the following form: | ||
969 | <literallayout class='monospaced'> | ||
970 | $ devtool add https://github.com/diversario/node-ssdp | ||
971 | </literallayout> | ||
972 | In this example, <filename>devtool</filename> fetches the specified | ||
973 | Git repository, detects that the code is Node.js code, fetches | ||
974 | dependencies using <filename>npm</filename>, and sets | ||
975 | <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> | ||
976 | accordingly. | ||
977 | </para> | ||
958 | </section> | 978 | </section> |
959 | </section> | 979 | </section> |
960 | 980 | ||