diff options
Diffstat (limited to 'documentation/sdk-manual/extensible.rst')
-rw-r--r-- | documentation/sdk-manual/extensible.rst | 254 |
1 files changed, 108 insertions, 146 deletions
diff --git a/documentation/sdk-manual/extensible.rst b/documentation/sdk-manual/extensible.rst index 9e08e57a4e..355c6cb0e4 100644 --- a/documentation/sdk-manual/extensible.rst +++ b/documentation/sdk-manual/extensible.rst | |||
@@ -48,18 +48,20 @@ Extensible SDK can be installed in two different ways, and both have | |||
48 | their own pros and cons: | 48 | their own pros and cons: |
49 | 49 | ||
50 | #. *Setting up the Extensible SDK environment directly in a Yocto build*. This | 50 | #. *Setting up the Extensible SDK environment directly in a Yocto build*. This |
51 | avoids having to produce, test, distribute and maintain separate SDK installer | 51 | avoids having to produce, test, distribute and maintain separate SDK |
52 | archives, which can get very large. There is only one environment for the regular | 52 | installer archives, which can get very large. There is only one environment |
53 | Yocto build and the SDK and less code paths where things can go not according to plan. | 53 | for the regular Yocto build and the SDK and less code paths where things can |
54 | It's easier to update the SDK: it simply means updating the Yocto layers with | 54 | go not according to plan. It's easier to update the SDK: it simply means |
55 | git fetch or layer management tooling. The SDK extensibility is better than in the | 55 | updating the Yocto layers with git fetch or layer management tooling. The |
56 | second option: just run ``bitbake`` again to add more things to the sysroot, or add layers | 56 | SDK extensibility is better than in the second option: just run ``bitbake`` |
57 | if even more things are required. | 57 | again to add more things to the sysroot, or add layers if even more things |
58 | 58 | are required. | |
59 | #. *Setting up the Extensible SDK from a standalone installer*. This has the benefit of | 59 | |
60 | having a single, self-contained archive that includes all the needed binary artifacts. | 60 | #. *Setting up the Extensible SDK from a standalone installer*. This has the |
61 | So nothing needs to be rebuilt, and there is no need to provide a well-functioning | 61 | benefit of having a single, self-contained archive that includes all the |
62 | binary artefact cache over the network for developers with underpowered laptops. | 62 | needed binary artifacts. So nothing needs to be rebuilt, and there is no |
63 | need to provide a well-functioning binary artefact cache over the network | ||
64 | for developers with underpowered laptops. | ||
63 | 65 | ||
64 | Setting up the Extensible SDK environment directly in a Yocto build | 66 | Setting up the Extensible SDK environment directly in a Yocto build |
65 | ------------------------------------------------------------------- | 67 | ------------------------------------------------------------------- |
@@ -67,12 +69,12 @@ Setting up the Extensible SDK environment directly in a Yocto build | |||
67 | #. Set up all the needed layers and a Yocto :term:`Build Directory`, e.g. a regular Yocto | 69 | #. Set up all the needed layers and a Yocto :term:`Build Directory`, e.g. a regular Yocto |
68 | build where ``bitbake`` can be executed. | 70 | build where ``bitbake`` can be executed. |
69 | 71 | ||
70 | #. Run: | 72 | #. Run:: |
71 | $ bitbake meta-ide-support | ||
72 | $ bitbake -c populate_sysroot gtk+3 | ||
73 | (or any other target or native item that the application developer would need) | ||
74 | $ bitbake build-sysroots | ||
75 | 73 | ||
74 | $ bitbake meta-ide-support | ||
75 | $ bitbake -c populate_sysroot gtk+3 | ||
76 | # or any other target or native item that the application developer would need | ||
77 | $ bitbake build-sysroots | ||
76 | 78 | ||
77 | Setting up the Extensible SDK from a standalone installer | 79 | Setting up the Extensible SDK from a standalone installer |
78 | --------------------------------------------------------- | 80 | --------------------------------------------------------- |
@@ -194,15 +196,13 @@ script is for an IA-based target machine using i586 tuning:: | |||
194 | Run devtool --help for further details. | 196 | Run devtool --help for further details. |
195 | 197 | ||
196 | When using the environment script directly in a Yocto build, it can | 198 | When using the environment script directly in a Yocto build, it can |
197 | be run similarly: | 199 | be run similarly:: |
198 | 200 | ||
199 | $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux | 201 | $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux |
200 | 202 | ||
201 | Running the setup script defines many environment variables needed in | 203 | Running the setup script defines many environment variables needed in order to |
202 | order to use the SDK (e.g. ``PATH``, | 204 | use the SDK (e.g. ``PATH``, :term:`CC`, :term:`LD`, and so forth). If you want |
203 | :term:`CC`, | 205 | to see all the environment variables the script exports, examine the |
204 | :term:`LD`, and so forth). If you want to | ||
205 | see all the environment variables the script exports, examine the | ||
206 | installation file itself. | 206 | installation file itself. |
207 | 207 | ||
208 | Using ``devtool`` in Your SDK Workflow | 208 | Using ``devtool`` in Your SDK Workflow |
@@ -216,11 +216,8 @@ system. | |||
216 | 216 | ||
217 | .. note:: | 217 | .. note:: |
218 | 218 | ||
219 | The use of | 219 | The use of ``devtool`` is not limited to the extensible SDK. You can use |
220 | devtool | 220 | ``devtool`` to help you easily develop any project whose build output must be |
221 | is not limited to the extensible SDK. You can use | ||
222 | devtool | ||
223 | to help you easily develop any project whose build output must be | ||
224 | part of an image built using the build system. | 221 | part of an image built using the build system. |
225 | 222 | ||
226 | The ``devtool`` command line is organized similarly to | 223 | The ``devtool`` command line is organized similarly to |
@@ -230,15 +227,10 @@ all the commands. | |||
230 | 227 | ||
231 | .. note:: | 228 | .. note:: |
232 | 229 | ||
233 | See the " | 230 | See the ":doc:`/ref-manual/devtool-reference`" |
234 | devtool | 231 | section in the Yocto Project Reference Manual. |
235 | Quick Reference | ||
236 | " in the Yocto Project Reference Manual for a | ||
237 | devtool | ||
238 | quick reference. | ||
239 | 232 | ||
240 | Three ``devtool`` subcommands provide entry-points into | 233 | Three ``devtool`` subcommands provide entry-points into development: |
241 | development: | ||
242 | 234 | ||
243 | - *devtool add*: Assists in adding new software to be built. | 235 | - *devtool add*: Assists in adding new software to be built. |
244 | 236 | ||
@@ -315,9 +307,8 @@ command: | |||
315 | 307 | ||
316 | .. note:: | 308 | .. note:: |
317 | 309 | ||
318 | If required, | 310 | If required, ``devtool`` always creates a Git repository locally |
319 | devtool | 311 | during the extraction. |
320 | always creates a Git repository locally during the extraction. | ||
321 | 312 | ||
322 | Furthermore, the first positional argument ``srctree`` in this case | 313 | Furthermore, the first positional argument ``srctree`` in this case |
323 | identifies where the ``devtool add`` command will locate the | 314 | identifies where the ``devtool add`` command will locate the |
@@ -326,8 +317,7 @@ command: | |||
326 | 317 | ||
327 | $ devtool add recipe srctree fetchuri | 318 | $ devtool add recipe srctree fetchuri |
328 | 319 | ||
329 | In summary, | 320 | In summary, the source code is pulled from fetchuri and extracted into the |
330 | the source code is pulled from fetchuri and extracted into the | ||
331 | location defined by ``srctree`` as a local Git repository. | 321 | location defined by ``srctree`` as a local Git repository. |
332 | 322 | ||
333 | Within workspace, ``devtool`` creates a recipe named recipe along | 323 | Within workspace, ``devtool`` creates a recipe named recipe along |
@@ -358,16 +348,14 @@ command: | |||
358 | 348 | ||
359 | $ devtool edit-recipe recipe | 349 | $ devtool edit-recipe recipe |
360 | 350 | ||
361 | From within the editor, you | 351 | From within the editor, you can make modifications to the recipe that |
362 | can make modifications to the recipe that take effect when you build | 352 | take effect when you build it later. |
363 | it later. | ||
364 | 353 | ||
365 | #. *Build the Recipe or Rebuild the Image*: The next step you take | 354 | #. *Build the Recipe or Rebuild the Image*: The next step you take |
366 | depends on what you are going to do with the new code. | 355 | depends on what you are going to do with the new code. |
367 | 356 | ||
368 | If you need to eventually move the build output to the target | 357 | If you need to eventually move the build output to the target |
369 | hardware, use the following ``devtool`` command: | 358 | hardware, use the following ``devtool`` command:: |
370 | :; | ||
371 | 359 | ||
372 | $ devtool build recipe | 360 | $ devtool build recipe |
373 | 361 | ||
@@ -392,8 +380,11 @@ command: | |||
392 | development machine. | 380 | development machine. |
393 | 381 | ||
394 | You can deploy your build output to that target hardware by using the | 382 | You can deploy your build output to that target hardware by using the |
395 | ``devtool deploy-target`` command: $ devtool deploy-target recipe | 383 | ``devtool deploy-target`` command:: |
396 | target The target is a live target machine running as an SSH server. | 384 | |
385 | $ devtool deploy-target recipe target | ||
386 | |||
387 | The target is a live target machine running as an SSH server. | ||
397 | 388 | ||
398 | You can, of course, also deploy the image you build to actual | 389 | You can, of course, also deploy the image you build to actual |
399 | hardware by using the ``devtool build-image`` command. However, | 390 | hardware by using the ``devtool build-image`` command. However, |
@@ -422,11 +413,9 @@ command: | |||
422 | 413 | ||
423 | .. note:: | 414 | .. note:: |
424 | 415 | ||
425 | You can use the | 416 | You can use the ``devtool reset`` command to put things back should you |
426 | devtool reset | 417 | decide you do not want to proceed with your work. If you do use this |
427 | command to put things back should you decide you do not want to | 418 | command, realize that the source tree is preserved. |
428 | proceed with your work. If you do use this command, realize that | ||
429 | the source tree is preserved. | ||
430 | 419 | ||
431 | Use ``devtool modify`` to Modify the Source of an Existing Component | 420 | Use ``devtool modify`` to Modify the Source of an Existing Component |
432 | -------------------------------------------------------------------- | 421 | -------------------------------------------------------------------- |
@@ -473,11 +462,9 @@ command: | |||
473 | 462 | ||
474 | $ devtool modify recipe | 463 | $ devtool modify recipe |
475 | 464 | ||
476 | Once | 465 | Once ``devtool`` locates the recipe, ``devtool`` uses the recipe's |
477 | ``devtool``\ locates the recipe, ``devtool`` uses the recipe's | 466 | :term:`SRC_URI` statements to locate the source code and any local |
478 | :term:`SRC_URI` statements to | 467 | patch files from other developers. |
479 | locate the source code and any local patch files from other | ||
480 | developers. | ||
481 | 468 | ||
482 | With this scenario, there is no ``srctree`` argument. Consequently, the | 469 | With this scenario, there is no ``srctree`` argument. Consequently, the |
483 | default behavior of the ``devtool modify`` command is to extract | 470 | default behavior of the ``devtool modify`` command is to extract |
@@ -513,11 +500,7 @@ command: | |||
513 | 500 | ||
514 | .. note:: | 501 | .. note:: |
515 | 502 | ||
516 | You cannot provide a URL for | 503 | You cannot provide a URL for ``srctree`` using the ``devtool`` command. |
517 | srctree | ||
518 | using the | ||
519 | devtool | ||
520 | command. | ||
521 | 504 | ||
522 | As with all extractions, the command uses the recipe's :term:`SRC_URI` | 505 | As with all extractions, the command uses the recipe's :term:`SRC_URI` |
523 | statements to locate the source files and any associated patch | 506 | statements to locate the source files and any associated patch |
@@ -570,7 +553,9 @@ command: | |||
570 | On the other hand, if you want an image to contain the recipe's | 553 | On the other hand, if you want an image to contain the recipe's |
571 | packages from the workspace for immediate deployment onto a device | 554 | packages from the workspace for immediate deployment onto a device |
572 | (e.g. for testing purposes), you can use the ``devtool build-image`` | 555 | (e.g. for testing purposes), you can use the ``devtool build-image`` |
573 | command: $ devtool build-image image | 556 | command:: |
557 | |||
558 | $ devtool build-image image | ||
574 | 559 | ||
575 | #. *Deploy the Build Output*: When you use the ``devtool build`` command | 560 | #. *Deploy the Build Output*: When you use the ``devtool build`` command |
576 | to build out your recipe, you probably want to see if the resulting | 561 | to build out your recipe, you probably want to see if the resulting |
@@ -610,8 +595,7 @@ command: | |||
610 | 595 | ||
611 | Any changes you want to turn into patches must be staged and | 596 | Any changes you want to turn into patches must be staged and |
612 | committed within the local Git repository before you use the | 597 | committed within the local Git repository before you use the |
613 | devtool finish | 598 | ``devtool finish`` command. |
614 | command. | ||
615 | 599 | ||
616 | Because there is no need to move the recipe, ``devtool finish`` | 600 | Because there is no need to move the recipe, ``devtool finish`` |
617 | either updates the original recipe in the original layer or the | 601 | either updates the original recipe in the original layer or the |
@@ -626,11 +610,9 @@ command: | |||
626 | 610 | ||
627 | .. note:: | 611 | .. note:: |
628 | 612 | ||
629 | You can use the | 613 | You can use the ``devtool reset`` command to put things back should you |
630 | devtool reset | 614 | decide you do not want to proceed with your work. If you do use this |
631 | command to put things back should you decide you do not want to | 615 | command, realize that the source tree is preserved. |
632 | proceed with your work. If you do use this command, realize that | ||
633 | the source tree is preserved. | ||
634 | 616 | ||
635 | Use ``devtool upgrade`` to Create a Version of the Recipe that Supports a Newer Version of the Software | 617 | Use ``devtool upgrade`` to Create a Version of the Recipe that Supports a Newer Version of the Software |
636 | ------------------------------------------------------------------------------------------------------- | 618 | ------------------------------------------------------------------------------------------------------- |
@@ -644,12 +626,11 @@ counterparts. | |||
644 | 626 | ||
645 | .. note:: | 627 | .. note:: |
646 | 628 | ||
647 | Several methods exist by which you can upgrade recipes - | 629 | Several methods exist by which you can upgrade recipes --- |
648 | ``devtool upgrade`` | 630 | ``devtool upgrade`` happens to be one. You can read about all the methods by |
649 | happens to be one. You can read about all the methods by which you | 631 | which you can upgrade recipes in the |
650 | can upgrade recipes in the | 632 | :ref:`dev-manual/upgrading-recipes:upgrading recipes` section of the Yocto |
651 | :ref:`dev-manual/upgrading-recipes:upgrading recipes` section | 633 | Project Development Tasks Manual. |
652 | of the Yocto Project Development Tasks Manual. | ||
653 | 634 | ||
654 | The ``devtool upgrade`` command is flexible enough to allow you to specify | 635 | The ``devtool upgrade`` command is flexible enough to allow you to specify |
655 | source code revision and versioning schemes, extract code into or out of the | 636 | source code revision and versioning schemes, extract code into or out of the |
@@ -755,8 +736,11 @@ The following diagram shows the common development flow used with the | |||
755 | development machine. | 736 | development machine. |
756 | 737 | ||
757 | You can deploy your build output to that target hardware by using the | 738 | You can deploy your build output to that target hardware by using the |
758 | ``devtool deploy-target`` command: $ devtool deploy-target recipe | 739 | ``devtool deploy-target`` command:: |
759 | target The target is a live target machine running as an SSH server. | 740 | |
741 | $ devtool deploy-target recipe target | ||
742 | |||
743 | The target is a live target machine running as an SSH server. | ||
760 | 744 | ||
761 | You can, of course, also deploy the image you build using the | 745 | You can, of course, also deploy the image you build using the |
762 | ``devtool build-image`` command to actual hardware. However, | 746 | ``devtool build-image`` command to actual hardware. However, |
@@ -790,11 +774,9 @@ The following diagram shows the common development flow used with the | |||
790 | 774 | ||
791 | .. note:: | 775 | .. note:: |
792 | 776 | ||
793 | You can use the | 777 | You can use the ``devtool reset`` command to put things back should you |
794 | devtool reset | 778 | decide you do not want to proceed with your work. If you do use this |
795 | command to put things back should you decide you do not want to | 779 | command, realize that the source tree is preserved. |
796 | proceed with your work. If you do use this command, realize that | ||
797 | the source tree is preserved. | ||
798 | 780 | ||
799 | A Closer Look at ``devtool add`` | 781 | A Closer Look at ``devtool add`` |
800 | ================================ | 782 | ================================ |
@@ -862,10 +844,9 @@ run ``devtool add`` again and provide the name or the version. | |||
862 | Dependency Detection and Mapping | 844 | Dependency Detection and Mapping |
863 | -------------------------------- | 845 | -------------------------------- |
864 | 846 | ||
865 | The ``devtool add`` command attempts to detect build-time dependencies | 847 | The ``devtool add`` command attempts to detect build-time dependencies and map |
866 | and map them to other recipes in the system. During this mapping, the | 848 | them to other recipes in the system. During this mapping, the command fills in |
867 | command fills in the names of those recipes as part of the | 849 | the names of those recipes as part of the :term:`DEPENDS` variable within the |
868 | :term:`DEPENDS` variable within the | ||
869 | recipe. If a dependency cannot be mapped, ``devtool`` places a comment | 850 | recipe. If a dependency cannot be mapped, ``devtool`` places a comment |
870 | in the recipe indicating such. The inability to map a dependency can | 851 | in the recipe indicating such. The inability to map a dependency can |
871 | result from naming not being recognized or because the dependency simply | 852 | result from naming not being recognized or because the dependency simply |
@@ -882,10 +863,8 @@ following to your recipe:: | |||
882 | 863 | ||
883 | .. note:: | 864 | .. note:: |
884 | 865 | ||
885 | The | 866 | The ``devtool add`` command often cannot distinguish between mandatory and |
886 | devtool add | 867 | optional dependencies. Consequently, some of the detected dependencies might |
887 | command often cannot distinguish between mandatory and optional | ||
888 | dependencies. Consequently, some of the detected dependencies might | ||
889 | in fact be optional. When in doubt, consult the documentation or the | 868 | in fact be optional. When in doubt, consult the documentation or the |
890 | configure script for the software the recipe is building for further | 869 | configure script for the software the recipe is building for further |
891 | details. In some cases, you might find you can substitute the | 870 | details. In some cases, you might find you can substitute the |
@@ -895,16 +874,14 @@ following to your recipe:: | |||
895 | License Detection | 874 | License Detection |
896 | ----------------- | 875 | ----------------- |
897 | 876 | ||
898 | The ``devtool add`` command attempts to determine if the software you | 877 | The ``devtool add`` command attempts to determine if the software you are |
899 | are adding is able to be distributed under a common, open-source | 878 | adding is able to be distributed under a common, open-source license. If |
900 | license. If so, the command sets the | 879 | so, the command sets the :term:`LICENSE` value accordingly. |
901 | :term:`LICENSE` value accordingly. | ||
902 | You should double-check the value added by the command against the | 880 | You should double-check the value added by the command against the |
903 | documentation or source files for the software you are building and, if | 881 | documentation or source files for the software you are building and, if |
904 | necessary, update that :term:`LICENSE` value. | 882 | necessary, update that :term:`LICENSE` value. |
905 | 883 | ||
906 | The ``devtool add`` command also sets the | 884 | The ``devtool add`` command also sets the :term:`LIC_FILES_CHKSUM` |
907 | :term:`LIC_FILES_CHKSUM` | ||
908 | value to point to all files that appear to be license-related. Realize | 885 | value to point to all files that appear to be license-related. Realize |
909 | that license statements often appear in comments at the top of source | 886 | that license statements often appear in comments at the top of source |
910 | files or within the documentation. In such cases, the command does not | 887 | files or within the documentation. In such cases, the command does not |
@@ -984,10 +961,9 @@ mind: | |||
984 | Adding Native Tools | 961 | Adding Native Tools |
985 | ------------------- | 962 | ------------------- |
986 | 963 | ||
987 | Often, you need to build additional tools that run on the :term:`Build | 964 | Often, you need to build additional tools that run on the :term:`Build Host` |
988 | Host` as opposed to | 965 | as opposed to the target. You should indicate this requirement by using one of |
989 | the target. You should indicate this requirement by using one of the | 966 | the following methods when you run ``devtool add``: |
990 | following methods when you run ``devtool add``: | ||
991 | 967 | ||
992 | - Specify the name of the recipe such that it ends with "-native". | 968 | - Specify the name of the recipe such that it ends with "-native". |
993 | Specifying the name like this produces a recipe that only builds for | 969 | Specifying the name like this produces a recipe that only builds for |
@@ -1011,8 +987,7 @@ Adding Node.js Modules | |||
1011 | ---------------------- | 987 | ---------------------- |
1012 | 988 | ||
1013 | You can use the ``devtool add`` command two different ways to add | 989 | You can use the ``devtool add`` command two different ways to add |
1014 | Node.js modules: 1) Through ``npm`` and, 2) from a repository or local | 990 | Node.js modules: through ``npm`` or from a repository or local source. |
1015 | source. | ||
1016 | 991 | ||
1017 | Use the following form to add Node.js modules through ``npm``:: | 992 | Use the following form to add Node.js modules through ``npm``:: |
1018 | 993 | ||
@@ -1027,7 +1002,7 @@ these behaviors ensure the reproducibility and integrity of the build. | |||
1027 | 1002 | ||
1028 | .. note:: | 1003 | .. note:: |
1029 | 1004 | ||
1030 | - You must use quotes around the URL. The ``devtool add`` does not | 1005 | - You must use quotes around the URL. ``devtool add`` does not |
1031 | require the quotes, but the shell considers ";" as a splitter | 1006 | require the quotes, but the shell considers ";" as a splitter |
1032 | between multiple commands. Thus, without the quotes, | 1007 | between multiple commands. Thus, without the quotes, |
1033 | ``devtool add`` does not receive the other parts, which results in | 1008 | ``devtool add`` does not receive the other parts, which results in |
@@ -1042,9 +1017,8 @@ repository or local source tree. To add modules this way, use | |||
1042 | 1017 | ||
1043 | $ devtool add https://github.com/diversario/node-ssdp | 1018 | $ devtool add https://github.com/diversario/node-ssdp |
1044 | 1019 | ||
1045 | In this example, ``devtool`` | 1020 | In this example, ``devtool`` fetches the specified Git repository, detects the |
1046 | fetches the specified Git repository, detects the code as Node.js code, | 1021 | code as Node.js code, fetches dependencies using ``npm``, and sets |
1047 | fetches dependencies using ``npm``, and sets | ||
1048 | :term:`SRC_URI` accordingly. | 1022 | :term:`SRC_URI` accordingly. |
1049 | 1023 | ||
1050 | Working With Recipes | 1024 | Working With Recipes |
@@ -1121,18 +1095,13 @@ Setting Configure Arguments | |||
1121 | 1095 | ||
1122 | If the software your recipe is building uses GNU autoconf, then a fixed | 1096 | If the software your recipe is building uses GNU autoconf, then a fixed |
1123 | set of arguments is passed to it to enable cross-compilation plus any | 1097 | set of arguments is passed to it to enable cross-compilation plus any |
1124 | extras specified by | 1098 | extras specified by :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS` |
1125 | :term:`EXTRA_OECONF` or | ||
1126 | :term:`PACKAGECONFIG_CONFARGS` | ||
1127 | set within the recipe. If you wish to pass additional options, add them | 1099 | set within the recipe. If you wish to pass additional options, add them |
1128 | to :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS`. Other supported build | 1100 | to :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS`. Other supported build |
1129 | tools have similar variables (e.g. | 1101 | tools have similar variables (e.g. :term:`EXTRA_OECMAKE` for CMake, |
1130 | :term:`EXTRA_OECMAKE` for | 1102 | :term:`EXTRA_OESCONS` for Scons, and so forth). If you need to pass anything on |
1131 | CMake, :term:`EXTRA_OESCONS` | 1103 | the ``make`` command line, you can use :term:`EXTRA_OEMAKE` or the |
1132 | for Scons, and so forth). If you need to pass anything on the ``make`` | 1104 | :term:`PACKAGECONFIG_CONFARGS` variables to do so. |
1133 | command line, you can use :term:`EXTRA_OEMAKE` or the | ||
1134 | :term:`PACKAGECONFIG_CONFARGS` | ||
1135 | variables to do so. | ||
1136 | 1105 | ||
1137 | You can use the ``devtool configure-help`` command to help you set the | 1106 | You can use the ``devtool configure-help`` command to help you set the |
1138 | arguments listed in the previous paragraph. The command determines the | 1107 | arguments listed in the previous paragraph. The command determines the |
@@ -1156,8 +1125,7 @@ the build host. | |||
1156 | 1125 | ||
1157 | Recipes should never write files directly into the sysroot. Instead, | 1126 | Recipes should never write files directly into the sysroot. Instead, |
1158 | files should be installed into standard locations during the | 1127 | files should be installed into standard locations during the |
1159 | :ref:`ref-tasks-install` task within | 1128 | :ref:`ref-tasks-install` task within the ``${``\ :term:`D`\ ``}`` directory. A |
1160 | the ``${``\ :term:`D`\ ``}`` directory. A | ||
1161 | subset of these files automatically goes into the sysroot. The reason | 1129 | subset of these files automatically goes into the sysroot. The reason |
1162 | for this limitation is that almost all files that go into the sysroot | 1130 | for this limitation is that almost all files that go into the sysroot |
1163 | are cataloged in manifests in order to ensure they can be removed later | 1131 | are cataloged in manifests in order to ensure they can be removed later |
@@ -1173,14 +1141,12 @@ the target device, it is important to understand packaging because the | |||
1173 | contents of the image are expressed in terms of packages and not | 1141 | contents of the image are expressed in terms of packages and not |
1174 | recipes. | 1142 | recipes. |
1175 | 1143 | ||
1176 | During the :ref:`ref-tasks-package` | 1144 | During the :ref:`ref-tasks-package` task, files installed during the |
1177 | task, files installed during the | 1145 | :ref:`ref-tasks-install` task are split into one main package, which is almost |
1178 | :ref:`ref-tasks-install` task are | 1146 | always named the same as the recipe, and into several other packages. This |
1179 | split into one main package, which is almost always named the same as | 1147 | separation exists because not all of those installed files are useful in every |
1180 | the recipe, and into several other packages. This separation exists | 1148 | image. For example, you probably do not need any of the documentation installed |
1181 | because not all of those installed files are useful in every image. For | 1149 | in a production image. Consequently, for each recipe the documentation |
1182 | example, you probably do not need any of the documentation installed in | ||
1183 | a production image. Consequently, for each recipe the documentation | ||
1184 | files are separated into a ``-doc`` package. Recipes that package | 1150 | files are separated into a ``-doc`` package. Recipes that package |
1185 | software containing optional modules or plugins might undergo additional | 1151 | software containing optional modules or plugins might undergo additional |
1186 | package splitting as well. | 1152 | package splitting as well. |
@@ -1188,8 +1154,7 @@ package splitting as well. | |||
1188 | After building a recipe, you can see where files have gone by looking in | 1154 | After building a recipe, you can see where files have gone by looking in |
1189 | the ``oe-workdir/packages-split`` directory, which contains a | 1155 | the ``oe-workdir/packages-split`` directory, which contains a |
1190 | subdirectory for each package. Apart from some advanced cases, the | 1156 | subdirectory for each package. Apart from some advanced cases, the |
1191 | :term:`PACKAGES` and | 1157 | :term:`PACKAGES` and :term:`FILES` variables controls |
1192 | :term:`FILES` variables controls | ||
1193 | splitting. The :term:`PACKAGES` variable lists all of the packages to be | 1158 | splitting. The :term:`PACKAGES` variable lists all of the packages to be |
1194 | produced, while the :term:`FILES` variable specifies which files to include | 1159 | produced, while the :term:`FILES` variable specifies which files to include |
1195 | in each package by using an override to specify the package. For | 1160 | in each package by using an override to specify the package. For |
@@ -1231,16 +1196,11 @@ target machine. | |||
1231 | 1196 | ||
1232 | .. note:: | 1197 | .. note:: |
1233 | 1198 | ||
1234 | The | 1199 | The ``devtool deploy-target`` and ``devtool undeploy-target`` commands do |
1235 | devtool deploy-target | 1200 | not currently interact with any package management system on the target |
1236 | and | 1201 | device (e.g. RPM or OPKG). Consequently, you should not intermingle |
1237 | devtool undeploy-target | 1202 | ``devtool deploy-target`` and package manager operations on the target |
1238 | commands do not currently interact with any package management system | 1203 | device. Doing so could result in a conflicting set of files. |
1239 | on the target device (e.g. RPM or OPKG). Consequently, you should not | ||
1240 | intermingle | ||
1241 | devtool deploy-target | ||
1242 | and package manager operations on the target device. Doing so could | ||
1243 | result in a conflicting set of files. | ||
1244 | 1204 | ||
1245 | Installing Additional Items Into the Extensible SDK | 1205 | Installing Additional Items Into the Extensible SDK |
1246 | =================================================== | 1206 | =================================================== |
@@ -1264,7 +1224,7 @@ When using the extensible SDK directly in a Yocto build | |||
1264 | 1224 | ||
1265 | In this scenario, the Yocto build tooling, e.g. ``bitbake`` | 1225 | In this scenario, the Yocto build tooling, e.g. ``bitbake`` |
1266 | is directly accessible to build additional items, and it | 1226 | is directly accessible to build additional items, and it |
1267 | can simply be executed directly: | 1227 | can simply be executed directly:: |
1268 | 1228 | ||
1269 | $ bitbake mesa | 1229 | $ bitbake mesa |
1270 | $ bitbake build-sysroots | 1230 | $ bitbake build-sysroots |
@@ -1272,6 +1232,8 @@ can simply be executed directly: | |||
1272 | When using a standalone installer for the Extensible SDK | 1232 | When using a standalone installer for the Extensible SDK |
1273 | -------------------------------------------------------- | 1233 | -------------------------------------------------------- |
1274 | 1234 | ||
1235 | :: | ||
1236 | |||
1275 | $ devtool sdk-install mesa | 1237 | $ devtool sdk-install mesa |
1276 | 1238 | ||
1277 | By default, the ``devtool sdk-install`` command assumes | 1239 | By default, the ``devtool sdk-install`` command assumes |
@@ -1297,13 +1259,13 @@ To update your installed SDK, use ``devtool`` as follows:: | |||
1297 | 1259 | ||
1298 | $ devtool sdk-update | 1260 | $ devtool sdk-update |
1299 | 1261 | ||
1300 | The previous command assumes your SDK provider has set the | 1262 | The previous command assumes your SDK provider has set the default update URL |
1301 | default update URL for you through the :term:`SDK_UPDATE_URL` | 1263 | for you through the :term:`SDK_UPDATE_URL` variable as described in the |
1302 | variable as described in the | ||
1303 | ":ref:`sdk-manual/appendix-customizing:Providing Updates to the Extensible SDK After Installation`" | 1264 | ":ref:`sdk-manual/appendix-customizing:Providing Updates to the Extensible SDK After Installation`" |
1304 | section. If the SDK provider has not set that default URL, you need to | 1265 | section. If the SDK provider has not set that default URL, you need to |
1305 | specify it yourself in the command as follows: $ devtool sdk-update | 1266 | specify it yourself in the command as follows:: |
1306 | path_to_update_directory | 1267 | |
1268 | $ devtool sdk-update path_to_update_directory | ||
1307 | 1269 | ||
1308 | .. note:: | 1270 | .. note:: |
1309 | 1271 | ||