diff options
Diffstat (limited to 'documentation')
28 files changed, 347 insertions, 347 deletions
diff --git a/documentation/dev-manual/bmaptool.rst b/documentation/dev-manual/bmaptool.rst index 4ee6f5e48b..9add72cf3b 100644 --- a/documentation/dev-manual/bmaptool.rst +++ b/documentation/dev-manual/bmaptool.rst | |||
@@ -28,18 +28,18 @@ Following, is an example that shows how to flash a Wic image. Realize | |||
28 | that while this example uses a Wic image, you can use Bmaptool to flash | 28 | that while this example uses a Wic image, you can use Bmaptool to flash |
29 | any type of image. Use these steps to flash an image using Bmaptool: | 29 | any type of image. Use these steps to flash an image using Bmaptool: |
30 | 30 | ||
31 | 1. *Update your local.conf File:* You need to have the following set | 31 | #. *Update your local.conf File:* You need to have the following set |
32 | in your ``local.conf`` file before building your image:: | 32 | in your ``local.conf`` file before building your image:: |
33 | 33 | ||
34 | IMAGE_FSTYPES += "wic wic.bmap" | 34 | IMAGE_FSTYPES += "wic wic.bmap" |
35 | 35 | ||
36 | 2. *Get Your Image:* Either have your image ready (pre-built with the | 36 | #. *Get Your Image:* Either have your image ready (pre-built with the |
37 | :term:`IMAGE_FSTYPES` | 37 | :term:`IMAGE_FSTYPES` |
38 | setting previously mentioned) or take the step to build the image:: | 38 | setting previously mentioned) or take the step to build the image:: |
39 | 39 | ||
40 | $ bitbake image | 40 | $ bitbake image |
41 | 41 | ||
42 | 3. *Flash the Device:* Flash the device with the image by using Bmaptool | 42 | #. *Flash the Device:* Flash the device with the image by using Bmaptool |
43 | depending on your particular setup. The following commands assume the | 43 | depending on your particular setup. The following commands assume the |
44 | image resides in the :term:`Build Directory`'s ``deploy/images/`` area: | 44 | image resides in the :term:`Build Directory`'s ``deploy/images/`` area: |
45 | 45 | ||
diff --git a/documentation/dev-manual/building.rst b/documentation/dev-manual/building.rst index 2798dd3e98..3064974cc5 100644 --- a/documentation/dev-manual/building.rst +++ b/documentation/dev-manual/building.rst | |||
@@ -43,11 +43,11 @@ The following figure and list overviews the build process: | |||
43 | .. image:: figures/bitbake-build-flow.png | 43 | .. image:: figures/bitbake-build-flow.png |
44 | :width: 100% | 44 | :width: 100% |
45 | 45 | ||
46 | 1. *Set up Your Host Development System to Support Development Using the | 46 | #. *Set up Your Host Development System to Support Development Using the |
47 | Yocto Project*: See the ":doc:`start`" section for options on how to get a | 47 | Yocto Project*: See the ":doc:`start`" section for options on how to get a |
48 | build host ready to use the Yocto Project. | 48 | build host ready to use the Yocto Project. |
49 | 49 | ||
50 | 2. *Initialize the Build Environment:* Initialize the build environment | 50 | #. *Initialize the Build Environment:* Initialize the build environment |
51 | by sourcing the build environment script (i.e. | 51 | by sourcing the build environment script (i.e. |
52 | :ref:`structure-core-script`):: | 52 | :ref:`structure-core-script`):: |
53 | 53 | ||
@@ -66,7 +66,7 @@ The following figure and list overviews the build process: | |||
66 | event, it's typically cleaner to locate the :term:`Build Directory` | 66 | event, it's typically cleaner to locate the :term:`Build Directory` |
67 | somewhere outside of your source directory. | 67 | somewhere outside of your source directory. |
68 | 68 | ||
69 | 3. *Make Sure Your* ``local.conf`` *File is Correct*: Ensure the | 69 | #. *Make Sure Your* ``local.conf`` *File is Correct*: Ensure the |
70 | ``conf/local.conf`` configuration file, which is found in the | 70 | ``conf/local.conf`` configuration file, which is found in the |
71 | :term:`Build Directory`, is set up how you want it. This file defines many | 71 | :term:`Build Directory`, is set up how you want it. This file defines many |
72 | aspects of the build environment including the target machine architecture | 72 | aspects of the build environment including the target machine architecture |
@@ -74,7 +74,7 @@ The following figure and list overviews the build process: | |||
74 | the build (:term:`PACKAGE_CLASSES`), and a centralized tarball download | 74 | the build (:term:`PACKAGE_CLASSES`), and a centralized tarball download |
75 | directory through the :term:`DL_DIR` variable. | 75 | directory through the :term:`DL_DIR` variable. |
76 | 76 | ||
77 | 4. *Build the Image:* Build the image using the ``bitbake`` command:: | 77 | #. *Build the Image:* Build the image using the ``bitbake`` command:: |
78 | 78 | ||
79 | $ bitbake target | 79 | $ bitbake target |
80 | 80 | ||
@@ -273,12 +273,12 @@ loading modules needed to locate and mount the final root filesystem. | |||
273 | 273 | ||
274 | Follow these steps to create an :term:`Initramfs` image: | 274 | Follow these steps to create an :term:`Initramfs` image: |
275 | 275 | ||
276 | 1. *Create the :term:`Initramfs` Image Recipe:* You can reference the | 276 | #. *Create the :term:`Initramfs` Image Recipe:* You can reference the |
277 | ``core-image-minimal-initramfs.bb`` recipe found in the | 277 | ``core-image-minimal-initramfs.bb`` recipe found in the |
278 | ``meta/recipes-core`` directory of the :term:`Source Directory` | 278 | ``meta/recipes-core`` directory of the :term:`Source Directory` |
279 | as an example from which to work. | 279 | as an example from which to work. |
280 | 280 | ||
281 | 2. *Decide if You Need to Bundle the :term:`Initramfs` Image Into the Kernel | 281 | #. *Decide if You Need to Bundle the :term:`Initramfs` Image Into the Kernel |
282 | Image:* If you want the :term:`Initramfs` image that is built to be bundled | 282 | Image:* If you want the :term:`Initramfs` image that is built to be bundled |
283 | in with the kernel image, set the :term:`INITRAMFS_IMAGE_BUNDLE` | 283 | in with the kernel image, set the :term:`INITRAMFS_IMAGE_BUNDLE` |
284 | variable to ``"1"`` in your ``local.conf`` configuration file and set the | 284 | variable to ``"1"`` in your ``local.conf`` configuration file and set the |
@@ -290,7 +290,7 @@ Follow these steps to create an :term:`Initramfs` image: | |||
290 | :term:`CONFIG_INITRAMFS_SOURCE` variable, allowing the :term:`Initramfs` | 290 | :term:`CONFIG_INITRAMFS_SOURCE` variable, allowing the :term:`Initramfs` |
291 | image to be built into the kernel normally. | 291 | image to be built into the kernel normally. |
292 | 292 | ||
293 | 3. *Optionally Add Items to the Initramfs Image Through the Initramfs | 293 | #. *Optionally Add Items to the Initramfs Image Through the Initramfs |
294 | Image Recipe:* If you add items to the :term:`Initramfs` image by way of its | 294 | Image Recipe:* If you add items to the :term:`Initramfs` image by way of its |
295 | recipe, you should use :term:`PACKAGE_INSTALL` rather than | 295 | recipe, you should use :term:`PACKAGE_INSTALL` rather than |
296 | :term:`IMAGE_INSTALL`. :term:`PACKAGE_INSTALL` gives more direct control of | 296 | :term:`IMAGE_INSTALL`. :term:`PACKAGE_INSTALL` gives more direct control of |
@@ -298,7 +298,7 @@ Follow these steps to create an :term:`Initramfs` image: | |||
298 | necessarily want that are set by the :ref:`image <ref-classes-image>` | 298 | necessarily want that are set by the :ref:`image <ref-classes-image>` |
299 | or :ref:`core-image <ref-classes-core-image>` classes. | 299 | or :ref:`core-image <ref-classes-core-image>` classes. |
300 | 300 | ||
301 | 4. *Build the Kernel Image and the Initramfs Image:* Build your kernel | 301 | #. *Build the Kernel Image and the Initramfs Image:* Build your kernel |
302 | image using BitBake. Because the :term:`Initramfs` image recipe is a | 302 | image using BitBake. Because the :term:`Initramfs` image recipe is a |
303 | dependency of the kernel image, the :term:`Initramfs` image is built as well | 303 | dependency of the kernel image, the :term:`Initramfs` image is built as well |
304 | and bundled with the kernel image if you used the | 304 | and bundled with the kernel image if you used the |
@@ -316,7 +316,7 @@ to override it. | |||
316 | 316 | ||
317 | To achieve this, you need to perform some additional steps: | 317 | To achieve this, you need to perform some additional steps: |
318 | 318 | ||
319 | 1. *Create a multiconfig for your Initramfs image:* You can perform the steps | 319 | #. *Create a multiconfig for your Initramfs image:* You can perform the steps |
320 | on ":ref:`dev-manual/building:building images for multiple targets using multiple configurations`" to create a separate multiconfig. | 320 | on ":ref:`dev-manual/building:building images for multiple targets using multiple configurations`" to create a separate multiconfig. |
321 | For the sake of simplicity let's assume such multiconfig is called: ``initramfscfg.conf`` and | 321 | For the sake of simplicity let's assume such multiconfig is called: ``initramfscfg.conf`` and |
322 | contains the variables:: | 322 | contains the variables:: |
@@ -324,7 +324,7 @@ To achieve this, you need to perform some additional steps: | |||
324 | TMPDIR="${TOPDIR}/tmp-initramfscfg" | 324 | TMPDIR="${TOPDIR}/tmp-initramfscfg" |
325 | TCLIBC="musl" | 325 | TCLIBC="musl" |
326 | 326 | ||
327 | 2. *Set additional Initramfs variables on your main configuration:* | 327 | #. *Set additional Initramfs variables on your main configuration:* |
328 | Additionally, on your main configuration (``local.conf``) you need to set the | 328 | Additionally, on your main configuration (``local.conf``) you need to set the |
329 | variables:: | 329 | variables:: |
330 | 330 | ||
@@ -599,13 +599,13 @@ are a couple of areas to experiment with: | |||
599 | 599 | ||
600 | - ``glibc``: In general, follow this process: | 600 | - ``glibc``: In general, follow this process: |
601 | 601 | ||
602 | 1. Remove ``glibc`` features from | 602 | #. Remove ``glibc`` features from |
603 | :term:`DISTRO_FEATURES` | 603 | :term:`DISTRO_FEATURES` |
604 | that you think you do not need. | 604 | that you think you do not need. |
605 | 605 | ||
606 | 2. Build your distribution. | 606 | #. Build your distribution. |
607 | 607 | ||
608 | 3. If the build fails due to missing symbols in a package, determine | 608 | #. If the build fails due to missing symbols in a package, determine |
609 | if you can reconfigure the package to not need those features. For | 609 | if you can reconfigure the package to not need those features. For |
610 | example, change the configuration to not support wide character | 610 | example, change the configuration to not support wide character |
611 | support as is done for ``ncurses``. Or, if support for those | 611 | support as is done for ``ncurses``. Or, if support for those |
@@ -837,13 +837,13 @@ build. | |||
837 | 837 | ||
838 | Follow these steps to populate your Downloads directory: | 838 | Follow these steps to populate your Downloads directory: |
839 | 839 | ||
840 | 1. *Create a Clean Downloads Directory:* Start with an empty downloads | 840 | #. *Create a Clean Downloads Directory:* Start with an empty downloads |
841 | directory (:term:`DL_DIR`). You | 841 | directory (:term:`DL_DIR`). You |
842 | start with an empty downloads directory by either removing the files | 842 | start with an empty downloads directory by either removing the files |
843 | in the existing directory or by setting :term:`DL_DIR` to point to either | 843 | in the existing directory or by setting :term:`DL_DIR` to point to either |
844 | an empty location or one that does not yet exist. | 844 | an empty location or one that does not yet exist. |
845 | 845 | ||
846 | 2. *Generate Tarballs of the Source Git Repositories:* Edit your | 846 | #. *Generate Tarballs of the Source Git Repositories:* Edit your |
847 | ``local.conf`` configuration file as follows:: | 847 | ``local.conf`` configuration file as follows:: |
848 | 848 | ||
849 | DL_DIR = "/home/your-download-dir/" | 849 | DL_DIR = "/home/your-download-dir/" |
@@ -856,7 +856,7 @@ Follow these steps to populate your Downloads directory: | |||
856 | :term:`BB_GENERATE_MIRROR_TARBALLS` | 856 | :term:`BB_GENERATE_MIRROR_TARBALLS` |
857 | variable for more information. | 857 | variable for more information. |
858 | 858 | ||
859 | 3. *Populate Your Downloads Directory Without Building:* Use BitBake to | 859 | #. *Populate Your Downloads Directory Without Building:* Use BitBake to |
860 | fetch your sources but inhibit the build:: | 860 | fetch your sources but inhibit the build:: |
861 | 861 | ||
862 | $ bitbake target --runonly=fetch | 862 | $ bitbake target --runonly=fetch |
@@ -865,7 +865,7 @@ Follow these steps to populate your Downloads directory: | |||
865 | a "snapshot" of the source files in the form of tarballs, which can | 865 | a "snapshot" of the source files in the form of tarballs, which can |
866 | be used for the build. | 866 | be used for the build. |
867 | 867 | ||
868 | 4. *Optionally Remove Any Git or other SCM Subdirectories From the | 868 | #. *Optionally Remove Any Git or other SCM Subdirectories From the |
869 | Downloads Directory:* If you want, you can clean up your downloads | 869 | Downloads Directory:* If you want, you can clean up your downloads |
870 | directory by removing any Git or other Source Control Management | 870 | directory by removing any Git or other Source Control Management |
871 | (SCM) subdirectories such as ``${DL_DIR}/git2/*``. The tarballs | 871 | (SCM) subdirectories such as ``${DL_DIR}/git2/*``. The tarballs |
@@ -879,7 +879,7 @@ any machine and at any time. | |||
879 | Follow these steps to build your target using the files in the downloads | 879 | Follow these steps to build your target using the files in the downloads |
880 | directory: | 880 | directory: |
881 | 881 | ||
882 | 1. *Using Local Files Only:* Inside your ``local.conf`` file, add the | 882 | #. *Using Local Files Only:* Inside your ``local.conf`` file, add the |
883 | :term:`SOURCE_MIRROR_URL` variable, inherit the | 883 | :term:`SOURCE_MIRROR_URL` variable, inherit the |
884 | :ref:`own-mirrors <ref-classes-own-mirrors>` class, and use the | 884 | :ref:`own-mirrors <ref-classes-own-mirrors>` class, and use the |
885 | :term:`BB_NO_NETWORK` variable to your ``local.conf``:: | 885 | :term:`BB_NO_NETWORK` variable to your ``local.conf``:: |
@@ -894,11 +894,11 @@ directory: | |||
894 | BitBake's fetching process in step 3 stays local, which means files | 894 | BitBake's fetching process in step 3 stays local, which means files |
895 | from your "own-mirror" are used. | 895 | from your "own-mirror" are used. |
896 | 896 | ||
897 | 2. *Start With a Clean Build:* You can start with a clean build by | 897 | #. *Start With a Clean Build:* You can start with a clean build by |
898 | removing the ``${``\ :term:`TMPDIR`\ ``}`` directory or using a new | 898 | removing the ``${``\ :term:`TMPDIR`\ ``}`` directory or using a new |
899 | :term:`Build Directory`. | 899 | :term:`Build Directory`. |
900 | 900 | ||
901 | 3. *Build Your Target:* Use BitBake to build your target:: | 901 | #. *Build Your Target:* Use BitBake to build your target:: |
902 | 902 | ||
903 | $ bitbake target | 903 | $ bitbake target |
904 | 904 | ||
@@ -925,16 +925,16 @@ directory: | |||
925 | If you do have recipes that use :term:`AUTOREV`, you can take steps to | 925 | If you do have recipes that use :term:`AUTOREV`, you can take steps to |
926 | still use the recipes in an offline build. Do the following: | 926 | still use the recipes in an offline build. Do the following: |
927 | 927 | ||
928 | 1. Use a configuration generated by enabling :ref:`build | 928 | #. Use a configuration generated by enabling :ref:`build |
929 | history <dev-manual/build-quality:maintaining build output quality>`. | 929 | history <dev-manual/build-quality:maintaining build output quality>`. |
930 | 930 | ||
931 | 2. Use the ``buildhistory-collect-srcrevs`` command to collect the | 931 | #. Use the ``buildhistory-collect-srcrevs`` command to collect the |
932 | stored :term:`SRCREV` values from the build's history. For more | 932 | stored :term:`SRCREV` values from the build's history. For more |
933 | information on collecting these values, see the | 933 | information on collecting these values, see the |
934 | ":ref:`dev-manual/build-quality:build history package information`" | 934 | ":ref:`dev-manual/build-quality:build history package information`" |
935 | section. | 935 | section. |
936 | 936 | ||
937 | 3. Once you have the correct source revisions, you can modify | 937 | #. Once you have the correct source revisions, you can modify |
938 | those recipes to set :term:`SRCREV` to specific versions of the | 938 | those recipes to set :term:`SRCREV` to specific versions of the |
939 | software. | 939 | software. |
940 | 940 | ||
diff --git a/documentation/dev-manual/changes.rst b/documentation/dev-manual/changes.rst index 8ccbf0d7ee..9cb25f3549 100644 --- a/documentation/dev-manual/changes.rst +++ b/documentation/dev-manual/changes.rst | |||
@@ -22,40 +22,40 @@ steps, see the Yocto Project | |||
22 | 22 | ||
23 | Use the following general steps to submit a bug: | 23 | Use the following general steps to submit a bug: |
24 | 24 | ||
25 | 1. Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`. | 25 | #. Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`. |
26 | 26 | ||
27 | 2. Click "File a Bug" to enter a new bug. | 27 | #. Click "File a Bug" to enter a new bug. |
28 | 28 | ||
29 | 3. Choose the appropriate "Classification", "Product", and "Component" | 29 | #. Choose the appropriate "Classification", "Product", and "Component" |
30 | for which the bug was found. Bugs for the Yocto Project fall into | 30 | for which the bug was found. Bugs for the Yocto Project fall into |
31 | one of several classifications, which in turn break down into | 31 | one of several classifications, which in turn break down into |
32 | several products and components. For example, for a bug against the | 32 | several products and components. For example, for a bug against the |
33 | ``meta-intel`` layer, you would choose "Build System, Metadata & | 33 | ``meta-intel`` layer, you would choose "Build System, Metadata & |
34 | Runtime", "BSPs", and "bsps-meta-intel", respectively. | 34 | Runtime", "BSPs", and "bsps-meta-intel", respectively. |
35 | 35 | ||
36 | 4. Choose the "Version" of the Yocto Project for which you found the | 36 | #. Choose the "Version" of the Yocto Project for which you found the |
37 | bug (e.g. &DISTRO;). | 37 | bug (e.g. &DISTRO;). |
38 | 38 | ||
39 | 5. Determine and select the "Severity" of the bug. The severity | 39 | #. Determine and select the "Severity" of the bug. The severity |
40 | indicates how the bug impacted your work. | 40 | indicates how the bug impacted your work. |
41 | 41 | ||
42 | 6. Choose the "Hardware" that the bug impacts. | 42 | #. Choose the "Hardware" that the bug impacts. |
43 | 43 | ||
44 | 7. Choose the "Architecture" that the bug impacts. | 44 | #. Choose the "Architecture" that the bug impacts. |
45 | 45 | ||
46 | 8. Choose a "Documentation change" item for the bug. Fixing a bug might | 46 | #. Choose a "Documentation change" item for the bug. Fixing a bug might |
47 | or might not affect the Yocto Project documentation. If you are | 47 | or might not affect the Yocto Project documentation. If you are |
48 | unsure of the impact to the documentation, select "Don't Know". | 48 | unsure of the impact to the documentation, select "Don't Know". |
49 | 49 | ||
50 | 9. Provide a brief "Summary" of the bug. Try to limit your summary to | 50 | #. Provide a brief "Summary" of the bug. Try to limit your summary to |
51 | just a line or two and be sure to capture the essence of the bug. | 51 | just a line or two and be sure to capture the essence of the bug. |
52 | 52 | ||
53 | 10. Provide a detailed "Description" of the bug. You should provide as | 53 | #. Provide a detailed "Description" of the bug. You should provide as |
54 | much detail as you can about the context, behavior, output, and so | 54 | much detail as you can about the context, behavior, output, and so |
55 | forth that surrounds the bug. You can even attach supporting files | 55 | forth that surrounds the bug. You can even attach supporting files |
56 | for output from logs by using the "Add an attachment" button. | 56 | for output from logs by using the "Add an attachment" button. |
57 | 57 | ||
58 | 11. Click the "Submit Bug" button submit the bug. A new Bugzilla number | 58 | #. Click the "Submit Bug" button submit the bug. A new Bugzilla number |
59 | is assigned to the bug and the defect is logged in the bug tracking | 59 | is assigned to the bug and the defect is logged in the bug tracking |
60 | system. | 60 | system. |
61 | 61 | ||
@@ -162,16 +162,16 @@ The following sections provide procedures for submitting a change. | |||
162 | Preparing Changes for Submission | 162 | Preparing Changes for Submission |
163 | -------------------------------- | 163 | -------------------------------- |
164 | 164 | ||
165 | 1. *Make Your Changes Locally:* Make your changes in your local Git | 165 | #. *Make Your Changes Locally:* Make your changes in your local Git |
166 | repository. You should make small, controlled, isolated changes. | 166 | repository. You should make small, controlled, isolated changes. |
167 | Keeping changes small and isolated aids review, makes | 167 | Keeping changes small and isolated aids review, makes |
168 | merging/rebasing easier and keeps the change history clean should | 168 | merging/rebasing easier and keeps the change history clean should |
169 | anyone need to refer to it in future. | 169 | anyone need to refer to it in future. |
170 | 170 | ||
171 | 2. *Stage Your Changes:* Stage your changes by using the ``git add`` | 171 | #. *Stage Your Changes:* Stage your changes by using the ``git add`` |
172 | command on each file you changed. | 172 | command on each file you changed. |
173 | 173 | ||
174 | 3. *Commit Your Changes:* Commit the change by using the ``git commit`` | 174 | #. *Commit Your Changes:* Commit the change by using the ``git commit`` |
175 | command. Make sure your commit information follows standards by | 175 | command. Make sure your commit information follows standards by |
176 | following these accepted conventions: | 176 | following these accepted conventions: |
177 | 177 | ||
@@ -257,7 +257,7 @@ Here is the general procedure on how to submit a patch through email | |||
257 | without using the scripts once the steps in | 257 | without using the scripts once the steps in |
258 | :ref:`dev-manual/changes:preparing changes for submission` have been followed: | 258 | :ref:`dev-manual/changes:preparing changes for submission` have been followed: |
259 | 259 | ||
260 | 1. *Format the Commit:* Format the commit into an email message. To | 260 | #. *Format the Commit:* Format the commit into an email message. To |
261 | format commits, use the ``git format-patch`` command. When you | 261 | format commits, use the ``git format-patch`` command. When you |
262 | provide the command, you must include a revision list or a number of | 262 | provide the command, you must include a revision list or a number of |
263 | patches as part of the command. For example, either of these two | 263 | patches as part of the command. For example, either of these two |
@@ -289,7 +289,7 @@ without using the scripts once the steps in | |||
289 | or to OpenEmbedded, you might consider requesting a contrib area | 289 | or to OpenEmbedded, you might consider requesting a contrib area |
290 | and the necessary associated rights. | 290 | and the necessary associated rights. |
291 | 291 | ||
292 | 2. *Send the patches via email:* Send the patches to the recipients and | 292 | #. *Send the patches via email:* Send the patches to the recipients and |
293 | relevant mailing lists by using the ``git send-email`` command. | 293 | relevant mailing lists by using the ``git send-email`` command. |
294 | 294 | ||
295 | .. note:: | 295 | .. note:: |
@@ -352,7 +352,7 @@ been followed: | |||
352 | in the | 352 | in the |
353 | `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__. | 353 | `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__. |
354 | 354 | ||
355 | 1. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for | 355 | #. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for |
356 | permissions to push to an upstream contrib repository, push the | 356 | permissions to push to an upstream contrib repository, push the |
357 | change to that repository:: | 357 | change to that repository:: |
358 | 358 | ||
@@ -367,7 +367,7 @@ been followed: | |||
367 | 367 | ||
368 | $ git push meta-intel-contrib your_name/README | 368 | $ git push meta-intel-contrib your_name/README |
369 | 369 | ||
370 | 2. *Determine Who to Notify:* Determine the maintainer or the mailing | 370 | #. *Determine Who to Notify:* Determine the maintainer or the mailing |
371 | list that you need to notify for the change. | 371 | list that you need to notify for the change. |
372 | 372 | ||
373 | Before submitting any change, you need to be sure who the maintainer | 373 | Before submitting any change, you need to be sure who the maintainer |
@@ -395,7 +395,7 @@ been followed: | |||
395 | lists <resources-mailinglist>`" section in | 395 | lists <resources-mailinglist>`" section in |
396 | the Yocto Project Reference Manual. | 396 | the Yocto Project Reference Manual. |
397 | 397 | ||
398 | 3. *Make a Pull Request:* Notify the maintainer or the mailing list that | 398 | #. *Make a Pull Request:* Notify the maintainer or the mailing list that |
399 | you have pushed a change by making a pull request. | 399 | you have pushed a change by making a pull request. |
400 | 400 | ||
401 | The Yocto Project provides two scripts that conveniently let you | 401 | The Yocto Project provides two scripts that conveniently let you |
@@ -486,30 +486,30 @@ branch can be obtained from the | |||
486 | With this in mind, the steps to submit a change for a stable branch are as | 486 | With this in mind, the steps to submit a change for a stable branch are as |
487 | follows: | 487 | follows: |
488 | 488 | ||
489 | 1. *Identify the bug or CVE to be fixed:* This information should be | 489 | #. *Identify the bug or CVE to be fixed:* This information should be |
490 | collected so that it can be included in your submission. | 490 | collected so that it can be included in your submission. |
491 | 491 | ||
492 | See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities` | 492 | See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities` |
493 | for details about CVE tracking. | 493 | for details about CVE tracking. |
494 | 494 | ||
495 | 2. *Check if the fix is already present in the master branch:* This will | 495 | #. *Check if the fix is already present in the master branch:* This will |
496 | result in the most straightforward path into the stable branch for the | 496 | result in the most straightforward path into the stable branch for the |
497 | fix. | 497 | fix. |
498 | 498 | ||
499 | a. *If the fix is present in the master branch --- submit a backport request | 499 | #. *If the fix is present in the master branch --- submit a backport request |
500 | by email:* You should send an email to the relevant stable branch | 500 | by email:* You should send an email to the relevant stable branch |
501 | maintainer and the mailing list with details of the bug or CVE to be | 501 | maintainer and the mailing list with details of the bug or CVE to be |
502 | fixed, the commit hash on the master branch that fixes the issue and | 502 | fixed, the commit hash on the master branch that fixes the issue and |
503 | the stable branches which you would like this fix to be backported to. | 503 | the stable branches which you would like this fix to be backported to. |
504 | 504 | ||
505 | b. *If the fix is not present in the master branch --- submit the fix to the | 505 | #. *If the fix is not present in the master branch --- submit the fix to the |
506 | master branch first:* This will ensure that the fix passes through the | 506 | master branch first:* This will ensure that the fix passes through the |
507 | project's usual patch review and test processes before being accepted. | 507 | project's usual patch review and test processes before being accepted. |
508 | It will also ensure that bugs are not left unresolved in the master | 508 | It will also ensure that bugs are not left unresolved in the master |
509 | branch itself. Once the fix is accepted in the master branch a backport | 509 | branch itself. Once the fix is accepted in the master branch a backport |
510 | request can be submitted as above. | 510 | request can be submitted as above. |
511 | 511 | ||
512 | c. *If the fix is unsuitable for the master branch --- submit a patch | 512 | #. *If the fix is unsuitable for the master branch --- submit a patch |
513 | directly for the stable branch:* This method should be considered as a | 513 | directly for the stable branch:* This method should be considered as a |
514 | last resort. It is typically necessary when the master branch is using | 514 | last resort. It is typically necessary when the master branch is using |
515 | a newer version of the software which includes an upstream fix for the | 515 | a newer version of the software which includes an upstream fix for the |
diff --git a/documentation/dev-manual/debugging.rst b/documentation/dev-manual/debugging.rst index f433e8e6a9..921022475f 100644 --- a/documentation/dev-manual/debugging.rst +++ b/documentation/dev-manual/debugging.rst | |||
@@ -297,11 +297,11 @@ If you are unsure whether a variable dependency is being picked up | |||
297 | automatically for a given task, you can list the variable dependencies | 297 | automatically for a given task, you can list the variable dependencies |
298 | BitBake has determined by doing the following: | 298 | BitBake has determined by doing the following: |
299 | 299 | ||
300 | 1. Build the recipe containing the task:: | 300 | #. Build the recipe containing the task:: |
301 | 301 | ||
302 | $ bitbake recipename | 302 | $ bitbake recipename |
303 | 303 | ||
304 | 2. Inside the :term:`STAMPS_DIR` | 304 | #. Inside the :term:`STAMPS_DIR` |
305 | directory, find the signature data (``sigdata``) file that | 305 | directory, find the signature data (``sigdata``) file that |
306 | corresponds to the task. The ``sigdata`` files contain a pickled | 306 | corresponds to the task. The ``sigdata`` files contain a pickled |
307 | Python database of all the metadata that went into creating the input | 307 | Python database of all the metadata that went into creating the input |
@@ -319,7 +319,7 @@ BitBake has determined by doing the following: | |||
319 | the cached task output. The ``siginfo`` files contain exactly the | 319 | the cached task output. The ``siginfo`` files contain exactly the |
320 | same information as ``sigdata`` files. | 320 | same information as ``sigdata`` files. |
321 | 321 | ||
322 | 3. Run ``bitbake-dumpsig`` on the ``sigdata`` or ``siginfo`` file. Here | 322 | #. Run ``bitbake-dumpsig`` on the ``sigdata`` or ``siginfo`` file. Here |
323 | is an example:: | 323 | is an example:: |
324 | 324 | ||
325 | $ bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1 | 325 | $ bitbake-dumpsig ${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1 |
@@ -992,7 +992,7 @@ site <https://sourceware.org/gdb/documentation/>`__. | |||
992 | The following steps show you how to debug using the GNU project | 992 | The following steps show you how to debug using the GNU project |
993 | debugger. | 993 | debugger. |
994 | 994 | ||
995 | 1. *Configure your build system to construct the companion debug | 995 | #. *Configure your build system to construct the companion debug |
996 | filesystem:* | 996 | filesystem:* |
997 | 997 | ||
998 | In your ``local.conf`` file, set the following:: | 998 | In your ``local.conf`` file, set the following:: |
@@ -1012,7 +1012,7 @@ debugger. | |||
1012 | the full filesystem for debugging. Subsequent steps in this procedure | 1012 | the full filesystem for debugging. Subsequent steps in this procedure |
1013 | show how to combine the partial filesystem with the full filesystem. | 1013 | show how to combine the partial filesystem with the full filesystem. |
1014 | 1014 | ||
1015 | 2. *Configure the system to include gdbserver in the target filesystem:* | 1015 | #. *Configure the system to include gdbserver in the target filesystem:* |
1016 | 1016 | ||
1017 | Make the following addition in your ``local.conf`` file:: | 1017 | Make the following addition in your ``local.conf`` file:: |
1018 | 1018 | ||
@@ -1021,7 +1021,7 @@ debugger. | |||
1021 | The change makes | 1021 | The change makes |
1022 | sure the ``gdbserver`` package is included. | 1022 | sure the ``gdbserver`` package is included. |
1023 | 1023 | ||
1024 | 3. *Build the environment:* | 1024 | #. *Build the environment:* |
1025 | 1025 | ||
1026 | Use the following command to construct the image and the companion | 1026 | Use the following command to construct the image and the companion |
1027 | Debug Filesystem:: | 1027 | Debug Filesystem:: |
@@ -1057,7 +1057,7 @@ debugger. | |||
1057 | the actual image (e.g. ``gdb-cross-i586``). The suggestion is usually the | 1057 | the actual image (e.g. ``gdb-cross-i586``). The suggestion is usually the |
1058 | actual name you want to use. | 1058 | actual name you want to use. |
1059 | 1059 | ||
1060 | 4. *Set up the*Â ``debugfs``\ *:* | 1060 | #. *Set up the*Â ``debugfs``\ *:* |
1061 | 1061 | ||
1062 | Run the following commands to set up the ``debugfs``:: | 1062 | Run the following commands to set up the ``debugfs``:: |
1063 | 1063 | ||
@@ -1066,7 +1066,7 @@ debugger. | |||
1066 | $ tar xvfj build-dir/tmp/deploy/images/machine/image.rootfs.tar.bz2 | 1066 | $ tar xvfj build-dir/tmp/deploy/images/machine/image.rootfs.tar.bz2 |
1067 | $ tar xvfj build-dir/tmp/deploy/images/machine/image-dbg.rootfs.tar.bz2 | 1067 | $ tar xvfj build-dir/tmp/deploy/images/machine/image-dbg.rootfs.tar.bz2 |
1068 | 1068 | ||
1069 | 5. *Set up GDB:* | 1069 | #. *Set up GDB:* |
1070 | 1070 | ||
1071 | Install the SDK (if you built one) and then source the correct | 1071 | Install the SDK (if you built one) and then source the correct |
1072 | environment file. Sourcing the environment file puts the SDK in your | 1072 | environment file. Sourcing the environment file puts the SDK in your |
@@ -1075,7 +1075,7 @@ debugger. | |||
1075 | If you are using the build system, Gdb is located in | 1075 | If you are using the build system, Gdb is located in |
1076 | `build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb`` | 1076 | `build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb`` |
1077 | 1077 | ||
1078 | 6. *Boot the target:* | 1078 | #. *Boot the target:* |
1079 | 1079 | ||
1080 | For information on how to run QEMU, see the `QEMU | 1080 | For information on how to run QEMU, see the `QEMU |
1081 | Documentation <https://wiki.qemu.org/Documentation/GettingStartedDevelopers>`__. | 1081 | Documentation <https://wiki.qemu.org/Documentation/GettingStartedDevelopers>`__. |
@@ -1084,7 +1084,7 @@ debugger. | |||
1084 | 1084 | ||
1085 | Be sure to verify that your host can access the target via TCP. | 1085 | Be sure to verify that your host can access the target via TCP. |
1086 | 1086 | ||
1087 | 7. *Debug a program:* | 1087 | #. *Debug a program:* |
1088 | 1088 | ||
1089 | Debugging a program involves running gdbserver on the target and then | 1089 | Debugging a program involves running gdbserver on the target and then |
1090 | running Gdb on the host. The example in this step debugs ``gzip``: | 1090 | running Gdb on the host. The example in this step debugs ``gzip``: |
@@ -1116,7 +1116,7 @@ debugger. | |||
1116 | users ``~/.gdbinit`` file. Upon starting, Gdb automatically runs whatever | 1116 | users ``~/.gdbinit`` file. Upon starting, Gdb automatically runs whatever |
1117 | commands are in that file. | 1117 | commands are in that file. |
1118 | 1118 | ||
1119 | 8. *Deploying without a full image rebuild:* | 1119 | #. *Deploying without a full image rebuild:* |
1120 | 1120 | ||
1121 | In many cases, during development you want a quick method to deploy a | 1121 | In many cases, during development you want a quick method to deploy a |
1122 | new binary to the target and debug it, without waiting for a full | 1122 | new binary to the target and debug it, without waiting for a full |
diff --git a/documentation/dev-manual/gobject-introspection.rst b/documentation/dev-manual/gobject-introspection.rst index 89f21b7d10..28e51240c3 100644 --- a/documentation/dev-manual/gobject-introspection.rst +++ b/documentation/dev-manual/gobject-introspection.rst | |||
@@ -39,11 +39,11 @@ Enabling the Generation of Introspection Data | |||
39 | Enabling the generation of introspection data (GIR files) in your | 39 | Enabling the generation of introspection data (GIR files) in your |
40 | library package involves the following: | 40 | library package involves the following: |
41 | 41 | ||
42 | 1. Inherit the | 42 | #. Inherit the |
43 | :ref:`gobject-introspection <ref-classes-gobject-introspection>` | 43 | :ref:`gobject-introspection <ref-classes-gobject-introspection>` |
44 | class. | 44 | class. |
45 | 45 | ||
46 | 2. Make sure introspection is not disabled anywhere in the recipe or | 46 | #. Make sure introspection is not disabled anywhere in the recipe or |
47 | from anything the recipe includes. Also, make sure that | 47 | from anything the recipe includes. Also, make sure that |
48 | "gobject-introspection-data" is not in | 48 | "gobject-introspection-data" is not in |
49 | :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` | 49 | :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` |
@@ -51,7 +51,7 @@ library package involves the following: | |||
51 | :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`. | 51 | :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`. |
52 | In either of these conditions, nothing will happen. | 52 | In either of these conditions, nothing will happen. |
53 | 53 | ||
54 | 3. Try to build the recipe. If you encounter build errors that look like | 54 | #. Try to build the recipe. If you encounter build errors that look like |
55 | something is unable to find ``.so`` libraries, check where these | 55 | something is unable to find ``.so`` libraries, check where these |
56 | libraries are located in the source tree and add the following to the | 56 | libraries are located in the source tree and add the following to the |
57 | recipe:: | 57 | recipe:: |
@@ -63,7 +63,7 @@ library package involves the following: | |||
63 | See recipes in the ``oe-core`` repository that use that | 63 | See recipes in the ``oe-core`` repository that use that |
64 | :term:`GIR_EXTRA_LIBS_PATH` variable as an example. | 64 | :term:`GIR_EXTRA_LIBS_PATH` variable as an example. |
65 | 65 | ||
66 | 4. Look for any other errors, which probably mean that introspection | 66 | #. Look for any other errors, which probably mean that introspection |
67 | support in a package is not entirely standard, and thus breaks down | 67 | support in a package is not entirely standard, and thus breaks down |
68 | in a cross-compilation environment. For such cases, custom-made fixes | 68 | in a cross-compilation environment. For such cases, custom-made fixes |
69 | are needed. A good place to ask and receive help in these cases is | 69 | are needed. A good place to ask and receive help in these cases is |
@@ -116,21 +116,21 @@ Testing that Introspection Works in an Image | |||
116 | Use the following procedure to test if generating introspection data is | 116 | Use the following procedure to test if generating introspection data is |
117 | working in an image: | 117 | working in an image: |
118 | 118 | ||
119 | 1. Make sure that "gobject-introspection-data" is not in | 119 | #. Make sure that "gobject-introspection-data" is not in |
120 | :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` | 120 | :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED` |
121 | and that "qemu-usermode" is not in | 121 | and that "qemu-usermode" is not in |
122 | :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`. | 122 | :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`. |
123 | 123 | ||
124 | 2. Build ``core-image-sato``. | 124 | #. Build ``core-image-sato``. |
125 | 125 | ||
126 | 3. Launch a Terminal and then start Python in the terminal. | 126 | #. Launch a Terminal and then start Python in the terminal. |
127 | 127 | ||
128 | 4. Enter the following in the terminal:: | 128 | #. Enter the following in the terminal:: |
129 | 129 | ||
130 | >>> from gi.repository import GLib | 130 | >>> from gi.repository import GLib |
131 | >>> GLib.get_host_name() | 131 | >>> GLib.get_host_name() |
132 | 132 | ||
133 | 5. For something a little more advanced, enter the following see: | 133 | #. For something a little more advanced, enter the following see: |
134 | https://python-gtk-3-tutorial.readthedocs.io/en/latest/introduction.html | 134 | https://python-gtk-3-tutorial.readthedocs.io/en/latest/introduction.html |
135 | 135 | ||
136 | Known Issues | 136 | Known Issues |
diff --git a/documentation/dev-manual/layers.rst b/documentation/dev-manual/layers.rst index ad22524833..2d809562d1 100644 --- a/documentation/dev-manual/layers.rst +++ b/documentation/dev-manual/layers.rst | |||
@@ -28,14 +28,14 @@ Creating Your Own Layer | |||
28 | 28 | ||
29 | Follow these general steps to create your layer without using tools: | 29 | Follow these general steps to create your layer without using tools: |
30 | 30 | ||
31 | 1. *Check Existing Layers:* Before creating a new layer, you should be | 31 | #. *Check Existing Layers:* Before creating a new layer, you should be |
32 | sure someone has not already created a layer containing the Metadata | 32 | sure someone has not already created a layer containing the Metadata |
33 | you need. You can see the :oe_layerindex:`OpenEmbedded Metadata Index <>` | 33 | you need. You can see the :oe_layerindex:`OpenEmbedded Metadata Index <>` |
34 | for a list of layers from the OpenEmbedded community that can be used in | 34 | for a list of layers from the OpenEmbedded community that can be used in |
35 | the Yocto Project. You could find a layer that is identical or close | 35 | the Yocto Project. You could find a layer that is identical or close |
36 | to what you need. | 36 | to what you need. |
37 | 37 | ||
38 | 2. *Create a Directory:* Create the directory for your layer. When you | 38 | #. *Create a Directory:* Create the directory for your layer. When you |
39 | create the layer, be sure to create the directory in an area not | 39 | create the layer, be sure to create the directory in an area not |
40 | associated with the Yocto Project :term:`Source Directory` | 40 | associated with the Yocto Project :term:`Source Directory` |
41 | (e.g. the cloned ``poky`` repository). | 41 | (e.g. the cloned ``poky`` repository). |
@@ -58,7 +58,7 @@ Follow these general steps to create your layer without using tools: | |||
58 | "meta-" string are appended to several variables used in the | 58 | "meta-" string are appended to several variables used in the |
59 | configuration. | 59 | configuration. |
60 | 60 | ||
61 | 3. *Create a Layer Configuration File:* Inside your new layer folder, | 61 | #. *Create a Layer Configuration File:* Inside your new layer folder, |
62 | you need to create a ``conf/layer.conf`` file. It is easiest to take | 62 | you need to create a ``conf/layer.conf`` file. It is easiest to take |
63 | an existing layer configuration file and copy that to your layer's | 63 | an existing layer configuration file and copy that to your layer's |
64 | ``conf`` directory and then modify the file as needed. | 64 | ``conf`` directory and then modify the file as needed. |
@@ -128,7 +128,7 @@ Follow these general steps to create your layer without using tools: | |||
128 | variable is a good way to indicate if your particular layer is | 128 | variable is a good way to indicate if your particular layer is |
129 | current. | 129 | current. |
130 | 130 | ||
131 | 4. *Add Content:* Depending on the type of layer, add the content. If | 131 | #. *Add Content:* Depending on the type of layer, add the content. If |
132 | the layer adds support for a machine, add the machine configuration | 132 | the layer adds support for a machine, add the machine configuration |
133 | in a ``conf/machine/`` file within the layer. If the layer adds | 133 | in a ``conf/machine/`` file within the layer. If the layer adds |
134 | distro policy, add the distro configuration in a ``conf/distro/`` | 134 | distro policy, add the distro configuration in a ``conf/distro/`` |
@@ -141,7 +141,7 @@ Follow these general steps to create your layer without using tools: | |||
141 | Yocto Project, see the ":ref:`bsp-guide/bsp:example filesystem layout`" | 141 | Yocto Project, see the ":ref:`bsp-guide/bsp:example filesystem layout`" |
142 | section in the Yocto Project Board Support Package (BSP) Developer's Guide. | 142 | section in the Yocto Project Board Support Package (BSP) Developer's Guide. |
143 | 143 | ||
144 | 5. *Optionally Test for Compatibility:* If you want permission to use | 144 | #. *Optionally Test for Compatibility:* If you want permission to use |
145 | the Yocto Project Compatibility logo with your layer or application | 145 | the Yocto Project Compatibility logo with your layer or application |
146 | that uses your layer, perform the steps to apply for compatibility. | 146 | that uses your layer, perform the steps to apply for compatibility. |
147 | See the | 147 | See the |
@@ -292,13 +292,13 @@ The Yocto Project Compatibility Program consists of a layer application | |||
292 | process that requests permission to use the Yocto Project Compatibility | 292 | process that requests permission to use the Yocto Project Compatibility |
293 | Logo for your layer and application. The process consists of two parts: | 293 | Logo for your layer and application. The process consists of two parts: |
294 | 294 | ||
295 | 1. Successfully passing a script (``yocto-check-layer``) that when run | 295 | #. Successfully passing a script (``yocto-check-layer``) that when run |
296 | against your layer, tests it against constraints based on experiences | 296 | against your layer, tests it against constraints based on experiences |
297 | of how layers have worked in the real world and where pitfalls have | 297 | of how layers have worked in the real world and where pitfalls have |
298 | been found. Getting a "PASS" result from the script is required for | 298 | been found. Getting a "PASS" result from the script is required for |
299 | successful compatibility registration. | 299 | successful compatibility registration. |
300 | 300 | ||
301 | 2. Completion of an application acceptance form, which you can find at | 301 | #. Completion of an application acceptance form, which you can find at |
302 | :yocto_home:`/webform/yocto-project-compatible-registration`. | 302 | :yocto_home:`/webform/yocto-project-compatible-registration`. |
303 | 303 | ||
304 | To be granted permission to use the logo, you need to satisfy the | 304 | To be granted permission to use the logo, you need to satisfy the |
@@ -870,10 +870,10 @@ checked out first), or into a completely independent location. | |||
870 | The replication of the layers is performed by running the ``setup-layers`` script provided | 870 | The replication of the layers is performed by running the ``setup-layers`` script provided |
871 | above: | 871 | above: |
872 | 872 | ||
873 | 1. Clone the bootstrap layer or some other repository to obtain | 873 | #. Clone the bootstrap layer or some other repository to obtain |
874 | the json config and the setup script that can use it. | 874 | the json config and the setup script that can use it. |
875 | 875 | ||
876 | 2. Run the script directly with no options:: | 876 | #. Run the script directly with no options:: |
877 | 877 | ||
878 | alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers | 878 | alex@Zen2:/srv/work/alex/my-build$ meta-alex/setup-layers |
879 | Note: not checking out source meta-alex, use --force-bootstraplayer-checkout to override. | 879 | Note: not checking out source meta-alex, use --force-bootstraplayer-checkout to override. |
diff --git a/documentation/dev-manual/packages.rst b/documentation/dev-manual/packages.rst index afd8bfc945..2decdcb253 100644 --- a/documentation/dev-manual/packages.rst +++ b/documentation/dev-manual/packages.rst | |||
@@ -554,10 +554,10 @@ to use. In your configuration, you use the | |||
554 | :term:`PACKAGE_CLASSES` | 554 | :term:`PACKAGE_CLASSES` |
555 | variable to specify the format: | 555 | variable to specify the format: |
556 | 556 | ||
557 | 1. Open the ``local.conf`` file inside your :term:`Build Directory` (e.g. | 557 | #. Open the ``local.conf`` file inside your :term:`Build Directory` (e.g. |
558 | ``poky/build/conf/local.conf``). | 558 | ``poky/build/conf/local.conf``). |
559 | 559 | ||
560 | 2. Select the desired package format as follows:: | 560 | #. Select the desired package format as follows:: |
561 | 561 | ||
562 | PACKAGE_CLASSES ?= "package_packageformat" | 562 | PACKAGE_CLASSES ?= "package_packageformat" |
563 | 563 | ||
diff --git a/documentation/dev-manual/qemu.rst b/documentation/dev-manual/qemu.rst index 084e67580d..d431ea4b99 100644 --- a/documentation/dev-manual/qemu.rst +++ b/documentation/dev-manual/qemu.rst | |||
@@ -44,13 +44,13 @@ To use QEMU, you need to have QEMU installed and initialized as well as | |||
44 | have the proper artifacts (i.e. image files and root filesystems) | 44 | have the proper artifacts (i.e. image files and root filesystems) |
45 | available. Follow these general steps to run QEMU: | 45 | available. Follow these general steps to run QEMU: |
46 | 46 | ||
47 | 1. *Install QEMU:* QEMU is made available with the Yocto Project a | 47 | #. *Install QEMU:* QEMU is made available with the Yocto Project a |
48 | number of ways. One method is to install a Software Development Kit | 48 | number of ways. One method is to install a Software Development Kit |
49 | (SDK). See ":ref:`sdk-manual/intro:the qemu emulator`" section in the | 49 | (SDK). See ":ref:`sdk-manual/intro:the qemu emulator`" section in the |
50 | Yocto Project Application Development and the Extensible Software | 50 | Yocto Project Application Development and the Extensible Software |
51 | Development Kit (eSDK) manual for information on how to install QEMU. | 51 | Development Kit (eSDK) manual for information on how to install QEMU. |
52 | 52 | ||
53 | 2. *Setting Up the Environment:* How you set up the QEMU environment | 53 | #. *Setting Up the Environment:* How you set up the QEMU environment |
54 | depends on how you installed QEMU: | 54 | depends on how you installed QEMU: |
55 | 55 | ||
56 | - If you cloned the ``poky`` repository or you downloaded and | 56 | - If you cloned the ``poky`` repository or you downloaded and |
@@ -66,7 +66,7 @@ available. Follow these general steps to run QEMU: | |||
66 | 66 | ||
67 | . poky_sdk/environment-setup-core2-64-poky-linux | 67 | . poky_sdk/environment-setup-core2-64-poky-linux |
68 | 68 | ||
69 | 3. *Ensure the Artifacts are in Place:* You need to be sure you have a | 69 | #. *Ensure the Artifacts are in Place:* You need to be sure you have a |
70 | pre-built kernel that will boot in QEMU. You also need the target | 70 | pre-built kernel that will boot in QEMU. You also need the target |
71 | root filesystem for your target machine's architecture: | 71 | root filesystem for your target machine's architecture: |
72 | 72 | ||
@@ -84,7 +84,7 @@ available. Follow these general steps to run QEMU: | |||
84 | Extensible Software Development Kit (eSDK) manual for information on | 84 | Extensible Software Development Kit (eSDK) manual for information on |
85 | how to extract a root filesystem. | 85 | how to extract a root filesystem. |
86 | 86 | ||
87 | 4. *Run QEMU:* The basic ``runqemu`` command syntax is as follows:: | 87 | #. *Run QEMU:* The basic ``runqemu`` command syntax is as follows:: |
88 | 88 | ||
89 | $ runqemu [option ] [...] | 89 | $ runqemu [option ] [...] |
90 | 90 | ||
@@ -184,7 +184,7 @@ the system does not need root privileges to run. It uses a user space | |||
184 | NFS server to avoid that. Follow these steps to set up for running QEMU | 184 | NFS server to avoid that. Follow these steps to set up for running QEMU |
185 | using an NFS server. | 185 | using an NFS server. |
186 | 186 | ||
187 | 1. *Extract a Root Filesystem:* Once you are able to run QEMU in your | 187 | #. *Extract a Root Filesystem:* Once you are able to run QEMU in your |
188 | environment, you can use the ``runqemu-extract-sdk`` script, which is | 188 | environment, you can use the ``runqemu-extract-sdk`` script, which is |
189 | located in the ``scripts`` directory along with the ``runqemu`` | 189 | located in the ``scripts`` directory along with the ``runqemu`` |
190 | script. | 190 | script. |
@@ -198,7 +198,7 @@ using an NFS server. | |||
198 | 198 | ||
199 | runqemu-extract-sdk ./tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64.tar.bz2 test-nfs | 199 | runqemu-extract-sdk ./tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64.tar.bz2 test-nfs |
200 | 200 | ||
201 | 2. *Start QEMU:* Once you have extracted the file system, you can run | 201 | #. *Start QEMU:* Once you have extracted the file system, you can run |
202 | ``runqemu`` normally with the additional location of the file system. | 202 | ``runqemu`` normally with the additional location of the file system. |
203 | You can then also make changes to the files within ``./test-nfs`` and | 203 | You can then also make changes to the files within ``./test-nfs`` and |
204 | see those changes appear in the image in real time. Here is an | 204 | see those changes appear in the image in real time. Here is an |
diff --git a/documentation/dev-manual/quilt.rst b/documentation/dev-manual/quilt.rst index 1dd9ff02d4..24343e2fac 100644 --- a/documentation/dev-manual/quilt.rst +++ b/documentation/dev-manual/quilt.rst | |||
@@ -20,32 +20,32 @@ form of a patch all using Quilt. | |||
20 | 20 | ||
21 | Follow these general steps: | 21 | Follow these general steps: |
22 | 22 | ||
23 | 1. *Find the Source Code:* Temporary source code used by the | 23 | #. *Find the Source Code:* Temporary source code used by the |
24 | OpenEmbedded build system is kept in the :term:`Build Directory`. See the | 24 | OpenEmbedded build system is kept in the :term:`Build Directory`. See the |
25 | ":ref:`dev-manual/temporary-source-code:finding temporary source code`" section to | 25 | ":ref:`dev-manual/temporary-source-code:finding temporary source code`" section to |
26 | learn how to locate the directory that has the temporary source code for a | 26 | learn how to locate the directory that has the temporary source code for a |
27 | particular package. | 27 | particular package. |
28 | 28 | ||
29 | 2. *Change Your Working Directory:* You need to be in the directory that | 29 | #. *Change Your Working Directory:* You need to be in the directory that |
30 | has the temporary source code. That directory is defined by the | 30 | has the temporary source code. That directory is defined by the |
31 | :term:`S` variable. | 31 | :term:`S` variable. |
32 | 32 | ||
33 | 3. *Create a New Patch:* Before modifying source code, you need to | 33 | #. *Create a New Patch:* Before modifying source code, you need to |
34 | create a new patch. To create a new patch file, use ``quilt new`` as | 34 | create a new patch. To create a new patch file, use ``quilt new`` as |
35 | below:: | 35 | below:: |
36 | 36 | ||
37 | $ quilt new my_changes.patch | 37 | $ quilt new my_changes.patch |
38 | 38 | ||
39 | 4. *Notify Quilt and Add Files:* After creating the patch, you need to | 39 | #. *Notify Quilt and Add Files:* After creating the patch, you need to |
40 | notify Quilt about the files you plan to edit. You notify Quilt by | 40 | notify Quilt about the files you plan to edit. You notify Quilt by |
41 | adding the files to the patch you just created:: | 41 | adding the files to the patch you just created:: |
42 | 42 | ||
43 | $ quilt add file1.c file2.c file3.c | 43 | $ quilt add file1.c file2.c file3.c |
44 | 44 | ||
45 | 5. *Edit the Files:* Make your changes in the source code to the files | 45 | #. *Edit the Files:* Make your changes in the source code to the files |
46 | you added to the patch. | 46 | you added to the patch. |
47 | 47 | ||
48 | 6. *Test Your Changes:* Once you have modified the source code, the | 48 | #. *Test Your Changes:* Once you have modified the source code, the |
49 | easiest way to test your changes is by calling the :ref:`ref-tasks-compile` | 49 | easiest way to test your changes is by calling the :ref:`ref-tasks-compile` |
50 | task as shown in the following example:: | 50 | task as shown in the following example:: |
51 | 51 | ||
@@ -65,7 +65,7 @@ Follow these general steps: | |||
65 | the ":ref:`dev-manual/disk-space:conserving disk space during builds`" | 65 | the ":ref:`dev-manual/disk-space:conserving disk space during builds`" |
66 | section. | 66 | section. |
67 | 67 | ||
68 | 7. *Generate the Patch:* Once your changes work as expected, you need to | 68 | #. *Generate the Patch:* Once your changes work as expected, you need to |
69 | use Quilt to generate the final patch that contains all your | 69 | use Quilt to generate the final patch that contains all your |
70 | modifications:: | 70 | modifications:: |
71 | 71 | ||
@@ -78,7 +78,7 @@ Follow these general steps: | |||
78 | You can find the resulting patch file in the ``patches/`` | 78 | You can find the resulting patch file in the ``patches/`` |
79 | subdirectory of the source (:term:`S`) directory. | 79 | subdirectory of the source (:term:`S`) directory. |
80 | 80 | ||
81 | 8. *Copy the Patch File:* For simplicity, copy the patch file into a | 81 | #. *Copy the Patch File:* For simplicity, copy the patch file into a |
82 | directory named ``files``, which you can create in the same directory | 82 | directory named ``files``, which you can create in the same directory |
83 | that holds the recipe (``.bb``) file or the append (``.bbappend``) | 83 | that holds the recipe (``.bb``) file or the append (``.bbappend``) |
84 | file. Placing the patch here guarantees that the OpenEmbedded build | 84 | file. Placing the patch here guarantees that the OpenEmbedded build |
diff --git a/documentation/dev-manual/runtime-testing.rst b/documentation/dev-manual/runtime-testing.rst index 88b3ed541b..36ccf746ee 100644 --- a/documentation/dev-manual/runtime-testing.rst +++ b/documentation/dev-manual/runtime-testing.rst | |||
@@ -84,25 +84,25 @@ In order to run tests, you need to do the following: | |||
84 | 84 | ||
85 | Once you start running the tests, the following happens: | 85 | Once you start running the tests, the following happens: |
86 | 86 | ||
87 | 1. A copy of the root filesystem is written to ``${WORKDIR}/testimage``. | 87 | #. A copy of the root filesystem is written to ``${WORKDIR}/testimage``. |
88 | 88 | ||
89 | 2. The image is booted under QEMU using the standard ``runqemu`` script. | 89 | #. The image is booted under QEMU using the standard ``runqemu`` script. |
90 | 90 | ||
91 | 3. A default timeout of 500 seconds occurs to allow for the boot process | 91 | #. A default timeout of 500 seconds occurs to allow for the boot process |
92 | to reach the login prompt. You can change the timeout period by | 92 | to reach the login prompt. You can change the timeout period by |
93 | setting | 93 | setting |
94 | :term:`TEST_QEMUBOOT_TIMEOUT` | 94 | :term:`TEST_QEMUBOOT_TIMEOUT` |
95 | in the ``local.conf`` file. | 95 | in the ``local.conf`` file. |
96 | 96 | ||
97 | 4. Once the boot process is reached and the login prompt appears, the | 97 | #. Once the boot process is reached and the login prompt appears, the |
98 | tests run. The full boot log is written to | 98 | tests run. The full boot log is written to |
99 | ``${WORKDIR}/testimage/qemu_boot_log``. | 99 | ``${WORKDIR}/testimage/qemu_boot_log``. |
100 | 100 | ||
101 | 5. Each test module loads in the order found in :term:`TEST_SUITES`. You can | 101 | #. Each test module loads in the order found in :term:`TEST_SUITES`. You can |
102 | find the full output of the commands run over SSH in | 102 | find the full output of the commands run over SSH in |
103 | ``${WORKDIR}/testimgage/ssh_target_log``. | 103 | ``${WORKDIR}/testimgage/ssh_target_log``. |
104 | 104 | ||
105 | 6. If no failures occur, the task running the tests ends successfully. | 105 | #. If no failures occur, the task running the tests ends successfully. |
106 | You can find the output from the ``unittest`` in the task log at | 106 | You can find the output from the ``unittest`` in the task log at |
107 | ``${WORKDIR}/temp/log.do_testimage``. | 107 | ``${WORKDIR}/temp/log.do_testimage``. |
108 | 108 | ||
@@ -117,13 +117,13 @@ For automated deployment, a "controller image" is installed onto the | |||
117 | hardware once as part of setup. Then, each time tests are to be run, the | 117 | hardware once as part of setup. Then, each time tests are to be run, the |
118 | following occurs: | 118 | following occurs: |
119 | 119 | ||
120 | 1. The controller image is booted into and used to write the image to be | 120 | #. The controller image is booted into and used to write the image to be |
121 | tested to a second partition. | 121 | tested to a second partition. |
122 | 122 | ||
123 | 2. The device is then rebooted using an external script that you need to | 123 | #. The device is then rebooted using an external script that you need to |
124 | provide. | 124 | provide. |
125 | 125 | ||
126 | 3. The device boots into the image to be tested. | 126 | #. The device boots into the image to be tested. |
127 | 127 | ||
128 | When running tests (independent of whether the image has been deployed | 128 | When running tests (independent of whether the image has been deployed |
129 | automatically or not), the device is expected to be connected to a | 129 | automatically or not), the device is expected to be connected to a |
@@ -188,11 +188,11 @@ not need any information in this section. You can skip down to the | |||
188 | If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to | 188 | If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to |
189 | perform a one-time setup of your controller image by doing the following: | 189 | perform a one-time setup of your controller image by doing the following: |
190 | 190 | ||
191 | 1. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows:: | 191 | #. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows:: |
192 | 192 | ||
193 | EFI_PROVIDER = "systemd-boot" | 193 | EFI_PROVIDER = "systemd-boot" |
194 | 194 | ||
195 | 2. *Build the controller image:* Build the ``core-image-testmaster`` image. | 195 | #. *Build the controller image:* Build the ``core-image-testmaster`` image. |
196 | The ``core-image-testmaster`` recipe is provided as an example for a | 196 | The ``core-image-testmaster`` recipe is provided as an example for a |
197 | "controller" image and you can customize the image recipe as you would | 197 | "controller" image and you can customize the image recipe as you would |
198 | any other recipe. | 198 | any other recipe. |
@@ -219,13 +219,13 @@ perform a one-time setup of your controller image by doing the following: | |||
219 | - Another partition labeled "testrootfs" where test images get | 219 | - Another partition labeled "testrootfs" where test images get |
220 | deployed. | 220 | deployed. |
221 | 221 | ||
222 | 3. *Install image:* Install the image that you just built on the target | 222 | #. *Install image:* Install the image that you just built on the target |
223 | system. | 223 | system. |
224 | 224 | ||
225 | The final thing you need to do when setting :term:`TEST_TARGET` to | 225 | The final thing you need to do when setting :term:`TEST_TARGET` to |
226 | "SystemdbootTarget" is to set up the test image: | 226 | "SystemdbootTarget" is to set up the test image: |
227 | 227 | ||
228 | 1. *Set up your local.conf file:* Make sure you have the following | 228 | #. *Set up your local.conf file:* Make sure you have the following |
229 | statements in your ``local.conf`` file:: | 229 | statements in your ``local.conf`` file:: |
230 | 230 | ||
231 | IMAGE_FSTYPES += "tar.gz" | 231 | IMAGE_FSTYPES += "tar.gz" |
@@ -233,7 +233,7 @@ The final thing you need to do when setting :term:`TEST_TARGET` to | |||
233 | TEST_TARGET = "SystemdbootTarget" | 233 | TEST_TARGET = "SystemdbootTarget" |
234 | TEST_TARGET_IP = "192.168.2.3" | 234 | TEST_TARGET_IP = "192.168.2.3" |
235 | 235 | ||
236 | 2. *Build your test image:* Use BitBake to build the image:: | 236 | #. *Build your test image:* Use BitBake to build the image:: |
237 | 237 | ||
238 | $ bitbake core-image-sato | 238 | $ bitbake core-image-sato |
239 | 239 | ||
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst index b02e961608..498734a04d 100644 --- a/documentation/dev-manual/start.rst +++ b/documentation/dev-manual/start.rst | |||
@@ -29,7 +29,7 @@ however, keep in mind, the procedure here is simply a starting point. | |||
29 | You can build off these steps and customize the procedure to fit any | 29 | You can build off these steps and customize the procedure to fit any |
30 | particular working environment and set of practices. | 30 | particular working environment and set of practices. |
31 | 31 | ||
32 | 1. *Determine Who is Going to be Developing:* You first need to | 32 | #. *Determine Who is Going to be Developing:* You first need to |
33 | understand who is going to be doing anything related to the Yocto | 33 | understand who is going to be doing anything related to the Yocto |
34 | Project and determine their roles. Making this determination is | 34 | Project and determine their roles. Making this determination is |
35 | essential to completing subsequent steps, which are to get your | 35 | essential to completing subsequent steps, which are to get your |
@@ -52,7 +52,7 @@ particular working environment and set of practices. | |||
52 | automated tests that are used to ensure all application and core | 52 | automated tests that are used to ensure all application and core |
53 | system development meets desired quality standards. | 53 | system development meets desired quality standards. |
54 | 54 | ||
55 | 2. *Gather the Hardware:* Based on the size and make-up of the team, | 55 | #. *Gather the Hardware:* Based on the size and make-up of the team, |
56 | get the hardware together. Ideally, any development, build, or test | 56 | get the hardware together. Ideally, any development, build, or test |
57 | engineer uses a system that runs a supported Linux distribution. | 57 | engineer uses a system that runs a supported Linux distribution. |
58 | These systems, in general, should be high performance (e.g. dual, | 58 | These systems, in general, should be high performance (e.g. dual, |
@@ -66,13 +66,13 @@ particular working environment and set of practices. | |||
66 | building Yocto Project development containers to be run under | 66 | building Yocto Project development containers to be run under |
67 | Docker, which is described later. | 67 | Docker, which is described later. |
68 | 68 | ||
69 | 3. *Understand the Hardware Topology of the Environment:* Once you | 69 | #. *Understand the Hardware Topology of the Environment:* Once you |
70 | understand the hardware involved and the make-up of the team, you | 70 | understand the hardware involved and the make-up of the team, you |
71 | can understand the hardware topology of the development environment. | 71 | can understand the hardware topology of the development environment. |
72 | You can get a visual idea of the machines and their roles across the | 72 | You can get a visual idea of the machines and their roles across the |
73 | development environment. | 73 | development environment. |
74 | 74 | ||
75 | 4. *Use Git as Your Source Control Manager (SCM):* Keeping your | 75 | #. *Use Git as Your Source Control Manager (SCM):* Keeping your |
76 | :term:`Metadata` (i.e. recipes, | 76 | :term:`Metadata` (i.e. recipes, |
77 | configuration files, classes, and so forth) and any software you are | 77 | configuration files, classes, and so forth) and any software you are |
78 | developing under the control of an SCM system that is compatible | 78 | developing under the control of an SCM system that is compatible |
@@ -109,7 +109,7 @@ particular working environment and set of practices. | |||
109 | Documentation on how to create interfaces and frontends for | 109 | Documentation on how to create interfaces and frontends for |
110 | Git. | 110 | Git. |
111 | 111 | ||
112 | 5. *Set up the Application Development Machines:* As mentioned earlier, | 112 | #. *Set up the Application Development Machines:* As mentioned earlier, |
113 | application developers are creating applications on top of existing | 113 | application developers are creating applications on top of existing |
114 | software stacks. Following are some best practices for setting up | 114 | software stacks. Following are some best practices for setting up |
115 | machines used for application development: | 115 | machines used for application development: |
@@ -128,7 +128,7 @@ particular working environment and set of practices. | |||
128 | - Use multiple toolchains installed locally into different | 128 | - Use multiple toolchains installed locally into different |
129 | locations to allow development across versions. | 129 | locations to allow development across versions. |
130 | 130 | ||
131 | 6. *Set up the Core Development Machines:* As mentioned earlier, core | 131 | #. *Set up the Core Development Machines:* As mentioned earlier, core |
132 | developers work on the contents of the operating system itself. | 132 | developers work on the contents of the operating system itself. |
133 | Following are some best practices for setting up machines used for | 133 | Following are some best practices for setting up machines used for |
134 | developing images: | 134 | developing images: |
@@ -145,7 +145,7 @@ particular working environment and set of practices. | |||
145 | - Share layers amongst the developers of a particular project and | 145 | - Share layers amongst the developers of a particular project and |
146 | contain the policy configuration that defines the project. | 146 | contain the policy configuration that defines the project. |
147 | 147 | ||
148 | 7. *Set up an Autobuilder:* Autobuilders are often the core of the | 148 | #. *Set up an Autobuilder:* Autobuilders are often the core of the |
149 | development environment. It is here that changes from individual | 149 | development environment. It is here that changes from individual |
150 | developers are brought together and centrally tested. Based on this | 150 | developers are brought together and centrally tested. Based on this |
151 | automated build and test environment, subsequent decisions about | 151 | automated build and test environment, subsequent decisions about |
@@ -183,12 +183,12 @@ particular working environment and set of practices. | |||
183 | - Allows scheduling of builds so that resources can be used | 183 | - Allows scheduling of builds so that resources can be used |
184 | efficiently. | 184 | efficiently. |
185 | 185 | ||
186 | 8. *Set up Test Machines:* Use a small number of shared, high | 186 | #. *Set up Test Machines:* Use a small number of shared, high |
187 | performance systems for testing purposes. Developers can use these | 187 | performance systems for testing purposes. Developers can use these |
188 | systems for wider, more extensive testing while they continue to | 188 | systems for wider, more extensive testing while they continue to |
189 | develop locally using their primary development system. | 189 | develop locally using their primary development system. |
190 | 190 | ||
191 | 9. *Document Policies and Change Flow:* The Yocto Project uses a | 191 | #. *Document Policies and Change Flow:* The Yocto Project uses a |
192 | hierarchical structure and a pull model. There are scripts to create and | 192 | hierarchical structure and a pull model. There are scripts to create and |
193 | send pull requests (i.e. ``create-pull-request`` and | 193 | send pull requests (i.e. ``create-pull-request`` and |
194 | ``send-pull-request``). This model is in line with other open source | 194 | ``send-pull-request``). This model is in line with other open source |
@@ -213,7 +213,7 @@ particular working environment and set of practices. | |||
213 | possible. Chances are if you have discovered the need for changes, | 213 | possible. Chances are if you have discovered the need for changes, |
214 | someone else in the community needs them also. | 214 | someone else in the community needs them also. |
215 | 215 | ||
216 | 10. *Development Environment Summary:* Aside from the previous steps, | 216 | #. *Development Environment Summary:* Aside from the previous steps, |
217 | here are best practices within the Yocto Project development | 217 | here are best practices within the Yocto Project development |
218 | environment: | 218 | environment: |
219 | 219 | ||
@@ -296,7 +296,7 @@ Setting Up a Native Linux Host | |||
296 | Follow these steps to prepare a native Linux machine as your Yocto | 296 | Follow these steps to prepare a native Linux machine as your Yocto |
297 | Project Build Host: | 297 | Project Build Host: |
298 | 298 | ||
299 | 1. *Use a Supported Linux Distribution:* You should have a reasonably | 299 | #. *Use a Supported Linux Distribution:* You should have a reasonably |
300 | current Linux-based host system. You will have the best results with | 300 | current Linux-based host system. You will have the best results with |
301 | a recent release of Fedora, openSUSE, Debian, Ubuntu, RHEL or CentOS | 301 | a recent release of Fedora, openSUSE, Debian, Ubuntu, RHEL or CentOS |
302 | as these releases are frequently tested against the Yocto Project and | 302 | as these releases are frequently tested against the Yocto Project and |
@@ -306,10 +306,10 @@ Project Build Host: | |||
306 | section in the Yocto Project Reference Manual and the wiki page at | 306 | section in the Yocto Project Reference Manual and the wiki page at |
307 | :yocto_wiki:`Distribution Support </Distribution_Support>`. | 307 | :yocto_wiki:`Distribution Support </Distribution_Support>`. |
308 | 308 | ||
309 | 2. *Have Enough Free Memory:* Your system should have at least 50 Gbytes | 309 | #. *Have Enough Free Memory:* Your system should have at least 50 Gbytes |
310 | of free disk space for building images. | 310 | of free disk space for building images. |
311 | 311 | ||
312 | 3. *Meet Minimal Version Requirements:* The OpenEmbedded build system | 312 | #. *Meet Minimal Version Requirements:* The OpenEmbedded build system |
313 | should be able to run on any modern distribution that has the | 313 | should be able to run on any modern distribution that has the |
314 | following versions for Git, tar, Python, gcc and make. | 314 | following versions for Git, tar, Python, gcc and make. |
315 | 315 | ||
@@ -329,7 +329,7 @@ Project Build Host: | |||
329 | ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`" | 329 | ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`" |
330 | section in the Yocto Project Reference Manual for information. | 330 | section in the Yocto Project Reference Manual for information. |
331 | 331 | ||
332 | 4. *Install Development Host Packages:* Required development host | 332 | #. *Install Development Host Packages:* Required development host |
333 | packages vary depending on your build host and what you want to do | 333 | packages vary depending on your build host and what you want to do |
334 | with the Yocto Project. Collectively, the number of required packages | 334 | with the Yocto Project. Collectively, the number of required packages |
335 | is large if you want to be able to cover all cases. | 335 | is large if you want to be able to cover all cases. |
@@ -361,7 +361,7 @@ Yocto Project on a Windows, Mac, or Linux machine. | |||
361 | Follow these general steps to prepare a Windows, Mac, or Linux machine | 361 | Follow these general steps to prepare a Windows, Mac, or Linux machine |
362 | as your Yocto Project build host: | 362 | as your Yocto Project build host: |
363 | 363 | ||
364 | 1. *Determine What Your Build Host Needs:* | 364 | #. *Determine What Your Build Host Needs:* |
365 | `Docker <https://www.docker.com/what-docker>`__ is a software | 365 | `Docker <https://www.docker.com/what-docker>`__ is a software |
366 | container platform that you need to install on the build host. | 366 | container platform that you need to install on the build host. |
367 | Depending on your build host, you might have to install different | 367 | Depending on your build host, you might have to install different |
@@ -370,20 +370,20 @@ as your Yocto Project build host: | |||
370 | Platforms <https://docs.docker.com/engine/install/#supported-platforms>`__" | 370 | Platforms <https://docs.docker.com/engine/install/#supported-platforms>`__" |
371 | your build host needs to run containers. | 371 | your build host needs to run containers. |
372 | 372 | ||
373 | 2. *Choose What To Install:* Depending on whether or not your build host | 373 | #. *Choose What To Install:* Depending on whether or not your build host |
374 | meets system requirements, you need to install "Docker CE Stable" or | 374 | meets system requirements, you need to install "Docker CE Stable" or |
375 | the "Docker Toolbox". Most situations call for Docker CE. However, if | 375 | the "Docker Toolbox". Most situations call for Docker CE. However, if |
376 | you have a build host that does not meet requirements (e.g. | 376 | you have a build host that does not meet requirements (e.g. |
377 | Pre-Windows 10 or Windows 10 "Home" version), you must install Docker | 377 | Pre-Windows 10 or Windows 10 "Home" version), you must install Docker |
378 | Toolbox instead. | 378 | Toolbox instead. |
379 | 379 | ||
380 | 3. *Go to the Install Site for Your Platform:* Click the link for the | 380 | #. *Go to the Install Site for Your Platform:* Click the link for the |
381 | Docker edition associated with your build host's native software. For | 381 | Docker edition associated with your build host's native software. For |
382 | example, if your build host is running Microsoft Windows Version 10 | 382 | example, if your build host is running Microsoft Windows Version 10 |
383 | and you want the Docker CE Stable edition, click that link under | 383 | and you want the Docker CE Stable edition, click that link under |
384 | "Supported Platforms". | 384 | "Supported Platforms". |
385 | 385 | ||
386 | 4. *Install the Software:* Once you have understood all the | 386 | #. *Install the Software:* Once you have understood all the |
387 | pre-requisites, you can download and install the appropriate | 387 | pre-requisites, you can download and install the appropriate |
388 | software. Follow the instructions for your specific machine and the | 388 | software. Follow the instructions for your specific machine and the |
389 | type of the software you need to install: | 389 | type of the software you need to install: |
@@ -412,15 +412,15 @@ as your Yocto Project build host: | |||
412 | Ubuntu <https://docs.docker.com/engine/install/ubuntu/>`__ | 412 | Ubuntu <https://docs.docker.com/engine/install/ubuntu/>`__ |
413 | for Linux build hosts running the Ubuntu distribution. | 413 | for Linux build hosts running the Ubuntu distribution. |
414 | 414 | ||
415 | 5. *Optionally Orient Yourself With Docker:* If you are unfamiliar with | 415 | #. *Optionally Orient Yourself With Docker:* If you are unfamiliar with |
416 | Docker and the container concept, you can learn more here - | 416 | Docker and the container concept, you can learn more here - |
417 | https://docs.docker.com/get-started/. | 417 | https://docs.docker.com/get-started/. |
418 | 418 | ||
419 | 6. *Launch Docker or Docker Toolbox:* You should be able to launch | 419 | #. *Launch Docker or Docker Toolbox:* You should be able to launch |
420 | Docker or the Docker Toolbox and have a terminal shell on your | 420 | Docker or the Docker Toolbox and have a terminal shell on your |
421 | development host. | 421 | development host. |
422 | 422 | ||
423 | 7. *Set Up the Containers to Use the Yocto Project:* Go to | 423 | #. *Set Up the Containers to Use the Yocto Project:* Go to |
424 | https://github.com/crops/docker-win-mac-docs/wiki and follow | 424 | https://github.com/crops/docker-win-mac-docs/wiki and follow |
425 | the directions for your particular build host (i.e. Linux, Mac, or | 425 | the directions for your particular build host (i.e. Linux, Mac, or |
426 | Windows). | 426 | Windows). |
@@ -453,7 +453,7 @@ in which you can develop using the Yocto Project. | |||
453 | Follow these general steps to prepare a Windows machine using WSL 2 as | 453 | Follow these general steps to prepare a Windows machine using WSL 2 as |
454 | your Yocto Project build host: | 454 | your Yocto Project build host: |
455 | 455 | ||
456 | 1. *Make sure your Windows machine is capable of running WSL 2:* | 456 | #. *Make sure your Windows machine is capable of running WSL 2:* |
457 | 457 | ||
458 | While all Windows 11 and Windows Server 2022 builds support WSL 2, | 458 | While all Windows 11 and Windows Server 2022 builds support WSL 2, |
459 | the first versions of Windows 10 and Windows Server 2019 didn't. | 459 | the first versions of Windows 10 and Windows Server 2019 didn't. |
@@ -469,7 +469,7 @@ your Yocto Project build host: | |||
469 | 469 | ||
470 | Microsoft Windows [Version 10.0.19041.153] | 470 | Microsoft Windows [Version 10.0.19041.153] |
471 | 471 | ||
472 | 2. *Install the Linux distribution of your choice inside WSL 2:* | 472 | #. *Install the Linux distribution of your choice inside WSL 2:* |
473 | Once you know your version of Windows supports WSL 2, you can | 473 | Once you know your version of Windows supports WSL 2, you can |
474 | install the distribution of your choice from the Microsoft Store. | 474 | install the distribution of your choice from the Microsoft Store. |
475 | Open the Microsoft Store and search for Linux. While there are | 475 | Open the Microsoft Store and search for Linux. While there are |
@@ -479,7 +479,7 @@ your Yocto Project build host: | |||
479 | making your selection, simply click "Get" to download and install the | 479 | making your selection, simply click "Get" to download and install the |
480 | distribution. | 480 | distribution. |
481 | 481 | ||
482 | 3. *Check which Linux distribution WSL 2 is using:* Open a Windows | 482 | #. *Check which Linux distribution WSL 2 is using:* Open a Windows |
483 | PowerShell and run:: | 483 | PowerShell and run:: |
484 | 484 | ||
485 | C:\WINDOWS\system32> wsl -l -v | 485 | C:\WINDOWS\system32> wsl -l -v |
@@ -489,13 +489,13 @@ your Yocto Project build host: | |||
489 | Note that WSL 2 supports running as many different Linux distributions | 489 | Note that WSL 2 supports running as many different Linux distributions |
490 | as you want to install. | 490 | as you want to install. |
491 | 491 | ||
492 | 4. *Optionally Get Familiar with WSL:* You can learn more on | 492 | #. *Optionally Get Familiar with WSL:* You can learn more on |
493 | https://docs.microsoft.com/en-us/windows/wsl/wsl2-about. | 493 | https://docs.microsoft.com/en-us/windows/wsl/wsl2-about. |
494 | 494 | ||
495 | 5. *Launch your WSL Distibution:* From the Windows start menu simply | 495 | #. *Launch your WSL Distibution:* From the Windows start menu simply |
496 | launch your WSL distribution just like any other application. | 496 | launch your WSL distribution just like any other application. |
497 | 497 | ||
498 | 6. *Optimize your WSL 2 storage often:* Due to the way storage is | 498 | #. *Optimize your WSL 2 storage often:* Due to the way storage is |
499 | handled on WSL 2, the storage space used by the underlying Linux | 499 | handled on WSL 2, the storage space used by the underlying Linux |
500 | distribution is not reflected immediately, and since BitBake heavily | 500 | distribution is not reflected immediately, and since BitBake heavily |
501 | uses storage, after several builds, you may be unaware you are | 501 | uses storage, after several builds, you may be unaware you are |
@@ -597,14 +597,14 @@ repository at :yocto_git:`/poky`. | |||
597 | Use the following procedure to locate the latest upstream copy of the | 597 | Use the following procedure to locate the latest upstream copy of the |
598 | ``poky`` Git repository: | 598 | ``poky`` Git repository: |
599 | 599 | ||
600 | 1. *Access Repositories:* Open a browser and go to | 600 | #. *Access Repositories:* Open a browser and go to |
601 | :yocto_git:`/` to access the GUI-based interface into the | 601 | :yocto_git:`/` to access the GUI-based interface into the |
602 | Yocto Project source repositories. | 602 | Yocto Project source repositories. |
603 | 603 | ||
604 | 2. *Select the Repository:* Click on the repository in which you are | 604 | #. *Select the Repository:* Click on the repository in which you are |
605 | interested (e.g. ``poky``). | 605 | interested (e.g. ``poky``). |
606 | 606 | ||
607 | 3. *Find the URL Used to Clone the Repository:* At the bottom of the | 607 | #. *Find the URL Used to Clone the Repository:* At the bottom of the |
608 | page, note the URL used to clone that repository | 608 | page, note the URL used to clone that repository |
609 | (e.g. :yocto_git:`/poky`). | 609 | (e.g. :yocto_git:`/poky`). |
610 | 610 | ||
@@ -630,7 +630,7 @@ of a given component. | |||
630 | 630 | ||
631 | Follow these steps to locate and download a particular tarball: | 631 | Follow these steps to locate and download a particular tarball: |
632 | 632 | ||
633 | 1. *Access the Index of Releases:* Open a browser and go to | 633 | #. *Access the Index of Releases:* Open a browser and go to |
634 | :yocto_dl:`Index of Releases </releases>`. The | 634 | :yocto_dl:`Index of Releases </releases>`. The |
635 | list represents released components (e.g. ``bitbake``, ``sato``, and | 635 | list represents released components (e.g. ``bitbake``, ``sato``, and |
636 | so on). | 636 | so on). |
@@ -642,14 +642,14 @@ Follow these steps to locate and download a particular tarball: | |||
642 | historically used for very early releases and exists now only for | 642 | historically used for very early releases and exists now only for |
643 | retroactive completeness. | 643 | retroactive completeness. |
644 | 644 | ||
645 | 2. *Select a Component:* Click on any released component in which you | 645 | #. *Select a Component:* Click on any released component in which you |
646 | are interested (e.g. ``yocto``). | 646 | are interested (e.g. ``yocto``). |
647 | 647 | ||
648 | 3. *Find the Tarball:* Drill down to find the associated tarball. For | 648 | #. *Find the Tarball:* Drill down to find the associated tarball. For |
649 | example, click on ``yocto-&DISTRO;`` to view files associated with the | 649 | example, click on ``yocto-&DISTRO;`` to view files associated with the |
650 | Yocto Project &DISTRO; release. | 650 | Yocto Project &DISTRO; release. |
651 | 651 | ||
652 | 4. *Download the Tarball:* Click the tarball to download and save a | 652 | #. *Download the Tarball:* Click the tarball to download and save a |
653 | snapshot of the given component. | 653 | snapshot of the given component. |
654 | 654 | ||
655 | Using the Downloads Page | 655 | Using the Downloads Page |
@@ -661,13 +661,13 @@ release. Rather than Git repositories, these files represent snapshot | |||
661 | tarballs similar to the tarballs located in the Index of Releases | 661 | tarballs similar to the tarballs located in the Index of Releases |
662 | described in the ":ref:`dev-manual/start:accessing index of releases`" section. | 662 | described in the ":ref:`dev-manual/start:accessing index of releases`" section. |
663 | 663 | ||
664 | 1. *Go to the Yocto Project Website:* Open The | 664 | #. *Go to the Yocto Project Website:* Open The |
665 | :yocto_home:`Yocto Project Website <>` in your browser. | 665 | :yocto_home:`Yocto Project Website <>` in your browser. |
666 | 666 | ||
667 | 2. *Get to the Downloads Area:* Select the "DOWNLOADS" item from the | 667 | #. *Get to the Downloads Area:* Select the "DOWNLOADS" item from the |
668 | pull-down "SOFTWARE" tab menu near the top of the page. | 668 | pull-down "SOFTWARE" tab menu near the top of the page. |
669 | 669 | ||
670 | 3. *Select a Yocto Project Release:* Use the menu next to "RELEASE" to | 670 | #. *Select a Yocto Project Release:* Use the menu next to "RELEASE" to |
671 | display and choose a recent or past supported Yocto Project release | 671 | display and choose a recent or past supported Yocto Project release |
672 | (e.g. &DISTRO_NAME_NO_CAP;, &DISTRO_NAME_NO_CAP_MINUS_ONE;, and so forth). | 672 | (e.g. &DISTRO_NAME_NO_CAP;, &DISTRO_NAME_NO_CAP_MINUS_ONE;, and so forth). |
673 | 673 | ||
@@ -679,7 +679,7 @@ described in the ":ref:`dev-manual/start:accessing index of releases`" section. | |||
679 | You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto | 679 | You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto |
680 | Project releases. | 680 | Project releases. |
681 | 681 | ||
682 | 4. *Download Tools or Board Support Packages (BSPs):* From the | 682 | #. *Download Tools or Board Support Packages (BSPs):* From the |
683 | "DOWNLOADS" page, you can download tools or BSPs as well. Just scroll | 683 | "DOWNLOADS" page, you can download tools or BSPs as well. Just scroll |
684 | down the page and look for what you need. | 684 | down the page and look for what you need. |
685 | 685 | ||
@@ -707,10 +707,10 @@ Cloning the ``poky`` Repository | |||
707 | Follow these steps to create a local version of the upstream | 707 | Follow these steps to create a local version of the upstream |
708 | :term:`Poky` Git repository. | 708 | :term:`Poky` Git repository. |
709 | 709 | ||
710 | 1. *Set Your Directory:* Change your working directory to where you want | 710 | #. *Set Your Directory:* Change your working directory to where you want |
711 | to create your local copy of ``poky``. | 711 | to create your local copy of ``poky``. |
712 | 712 | ||
713 | 2. *Clone the Repository:* The following example command clones the | 713 | #. *Clone the Repository:* The following example command clones the |
714 | ``poky`` repository and uses the default name "poky" for your local | 714 | ``poky`` repository and uses the default name "poky" for your local |
715 | repository:: | 715 | repository:: |
716 | 716 | ||
@@ -766,13 +766,13 @@ and then specifically check out that development branch. | |||
766 | Further development on top of the branch that occurs after check it | 766 | Further development on top of the branch that occurs after check it |
767 | out can occur. | 767 | out can occur. |
768 | 768 | ||
769 | 1. *Switch to the Poky Directory:* If you have a local poky Git | 769 | #. *Switch to the Poky Directory:* If you have a local poky Git |
770 | repository, switch to that directory. If you do not have the local | 770 | repository, switch to that directory. If you do not have the local |
771 | copy of poky, see the | 771 | copy of poky, see the |
772 | ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" | 772 | ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" |
773 | section. | 773 | section. |
774 | 774 | ||
775 | 2. *Determine Existing Branch Names:* | 775 | #. *Determine Existing Branch Names:* |
776 | :: | 776 | :: |
777 | 777 | ||
778 | $ git branch -a | 778 | $ git branch -a |
@@ -793,7 +793,7 @@ and then specifically check out that development branch. | |||
793 | remotes/origin/zeus-next | 793 | remotes/origin/zeus-next |
794 | ... and so on ... | 794 | ... and so on ... |
795 | 795 | ||
796 | 3. *Check out the Branch:* Check out the development branch in which you | 796 | #. *Check out the Branch:* Check out the development branch in which you |
797 | want to work. For example, to access the files for the Yocto Project | 797 | want to work. For example, to access the files for the Yocto Project |
798 | &DISTRO; Release (&DISTRO_NAME;), use the following command:: | 798 | &DISTRO; Release (&DISTRO_NAME;), use the following command:: |
799 | 799 | ||
@@ -827,19 +827,19 @@ similar to checking out by branch name except you use tag names. | |||
827 | Checking out a branch based on a tag gives you a stable set of files | 827 | Checking out a branch based on a tag gives you a stable set of files |
828 | not affected by development on the branch above the tag. | 828 | not affected by development on the branch above the tag. |
829 | 829 | ||
830 | 1. *Switch to the Poky Directory:* If you have a local poky Git | 830 | #. *Switch to the Poky Directory:* If you have a local poky Git |
831 | repository, switch to that directory. If you do not have the local | 831 | repository, switch to that directory. If you do not have the local |
832 | copy of poky, see the | 832 | copy of poky, see the |
833 | ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" | 833 | ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" |
834 | section. | 834 | section. |
835 | 835 | ||
836 | 2. *Fetch the Tag Names:* To checkout the branch based on a tag name, | 836 | #. *Fetch the Tag Names:* To checkout the branch based on a tag name, |
837 | you need to fetch the upstream tags into your local repository:: | 837 | you need to fetch the upstream tags into your local repository:: |
838 | 838 | ||
839 | $ git fetch --tags | 839 | $ git fetch --tags |
840 | $ | 840 | $ |
841 | 841 | ||
842 | 3. *List the Tag Names:* You can list the tag names now:: | 842 | #. *List the Tag Names:* You can list the tag names now:: |
843 | 843 | ||
844 | $ git tag | 844 | $ git tag |
845 | 1.1_M1.final | 845 | 1.1_M1.final |
@@ -861,7 +861,7 @@ similar to checking out by branch name except you use tag names. | |||
861 | yocto_1.5_M5.rc8 | 861 | yocto_1.5_M5.rc8 |
862 | 862 | ||
863 | 863 | ||
864 | 4. *Check out the Branch:* | 864 | #. *Check out the Branch:* |
865 | :: | 865 | :: |
866 | 866 | ||
867 | $ git checkout tags/yocto-&DISTRO; -b my_yocto_&DISTRO; | 867 | $ git checkout tags/yocto-&DISTRO; -b my_yocto_&DISTRO; |
diff --git a/documentation/dev-manual/upgrading-recipes.rst b/documentation/dev-manual/upgrading-recipes.rst index c41e3e1a5d..dd220cc6c8 100644 --- a/documentation/dev-manual/upgrading-recipes.rst +++ b/documentation/dev-manual/upgrading-recipes.rst | |||
@@ -51,12 +51,12 @@ commit messages in the layer's tree for the changes made to recipes. | |||
51 | 51 | ||
52 | The following steps describe how to set up the AUH utility: | 52 | The following steps describe how to set up the AUH utility: |
53 | 53 | ||
54 | 1. *Be Sure the Development Host is Set Up:* You need to be sure that | 54 | #. *Be Sure the Development Host is Set Up:* You need to be sure that |
55 | your development host is set up to use the Yocto Project. For | 55 | your development host is set up to use the Yocto Project. For |
56 | information on how to set up your host, see the | 56 | information on how to set up your host, see the |
57 | ":ref:`dev-manual/start:Preparing the Build Host`" section. | 57 | ":ref:`dev-manual/start:Preparing the Build Host`" section. |
58 | 58 | ||
59 | 2. *Make Sure Git is Configured:* The AUH utility requires Git to be | 59 | #. *Make Sure Git is Configured:* The AUH utility requires Git to be |
60 | configured because AUH uses Git to save upgrades. Thus, you must have | 60 | configured because AUH uses Git to save upgrades. Thus, you must have |
61 | Git user and email configured. The following command shows your | 61 | Git user and email configured. The following command shows your |
62 | configurations:: | 62 | configurations:: |
@@ -69,7 +69,7 @@ The following steps describe how to set up the AUH utility: | |||
69 | $ git config --global user.name some_name | 69 | $ git config --global user.name some_name |
70 | $ git config --global user.email username@domain.com | 70 | $ git config --global user.email username@domain.com |
71 | 71 | ||
72 | 3. *Clone the AUH Repository:* To use AUH, you must clone the repository | 72 | #. *Clone the AUH Repository:* To use AUH, you must clone the repository |
73 | onto your development host. The following command uses Git to create | 73 | onto your development host. The following command uses Git to create |
74 | a local copy of the repository on your system:: | 74 | a local copy of the repository on your system:: |
75 | 75 | ||
@@ -84,7 +84,7 @@ The following steps describe how to set up the AUH utility: | |||
84 | AUH is not part of the :term:`OpenEmbedded-Core (OE-Core)` or | 84 | AUH is not part of the :term:`OpenEmbedded-Core (OE-Core)` or |
85 | :term:`Poky` repositories. | 85 | :term:`Poky` repositories. |
86 | 86 | ||
87 | 4. *Create a Dedicated Build Directory:* Run the :ref:`structure-core-script` | 87 | #. *Create a Dedicated Build Directory:* Run the :ref:`structure-core-script` |
88 | script to create a fresh :term:`Build Directory` that you use exclusively | 88 | script to create a fresh :term:`Build Directory` that you use exclusively |
89 | for running the AUH utility:: | 89 | for running the AUH utility:: |
90 | 90 | ||
@@ -95,7 +95,7 @@ The following steps describe how to set up the AUH utility: | |||
95 | recommended as existing settings could cause AUH to fail or behave | 95 | recommended as existing settings could cause AUH to fail or behave |
96 | undesirably. | 96 | undesirably. |
97 | 97 | ||
98 | 5. *Make Configurations in Your Local Configuration File:* Several | 98 | #. *Make Configurations in Your Local Configuration File:* Several |
99 | settings are needed in the ``local.conf`` file in the build | 99 | settings are needed in the ``local.conf`` file in the build |
100 | directory you just created for AUH. Make these following | 100 | directory you just created for AUH. Make these following |
101 | configurations: | 101 | configurations: |
@@ -128,13 +128,13 @@ The following steps describe how to set up the AUH utility: | |||
128 | DISTRO_FEATURES:append = " ptest" | 128 | DISTRO_FEATURES:append = " ptest" |
129 | 129 | ||
130 | 130 | ||
131 | 6. *Optionally Start a vncserver:* If you are running in a server | 131 | #. *Optionally Start a vncserver:* If you are running in a server |
132 | without an X11 session, you need to start a vncserver:: | 132 | without an X11 session, you need to start a vncserver:: |
133 | 133 | ||
134 | $ vncserver :1 | 134 | $ vncserver :1 |
135 | $ export DISPLAY=:1 | 135 | $ export DISPLAY=:1 |
136 | 136 | ||
137 | 7. *Create and Edit an AUH Configuration File:* You need to have the | 137 | #. *Create and Edit an AUH Configuration File:* You need to have the |
138 | ``upgrade-helper/upgrade-helper.conf`` configuration file in your | 138 | ``upgrade-helper/upgrade-helper.conf`` configuration file in your |
139 | :term:`Build Directory`. You can find a sample configuration file in the | 139 | :term:`Build Directory`. You can find a sample configuration file in the |
140 | :yocto_git:`AUH source repository </auto-upgrade-helper/tree/>`. | 140 | :yocto_git:`AUH source repository </auto-upgrade-helper/tree/>`. |
@@ -346,17 +346,17 @@ you can manually edit the recipe files to upgrade the versions. | |||
346 | 346 | ||
347 | To manually upgrade recipe versions, follow these general steps: | 347 | To manually upgrade recipe versions, follow these general steps: |
348 | 348 | ||
349 | 1. *Change the Version:* Rename the recipe such that the version (i.e. | 349 | #. *Change the Version:* Rename the recipe such that the version (i.e. |
350 | the :term:`PV` part of the recipe name) | 350 | the :term:`PV` part of the recipe name) |
351 | changes appropriately. If the version is not part of the recipe name, | 351 | changes appropriately. If the version is not part of the recipe name, |
352 | change the value as it is set for :term:`PV` within the recipe itself. | 352 | change the value as it is set for :term:`PV` within the recipe itself. |
353 | 353 | ||
354 | 2. *Update* :term:`SRCREV` *if Needed*: If the source code your recipe builds | 354 | #. *Update* :term:`SRCREV` *if Needed*: If the source code your recipe builds |
355 | is fetched from Git or some other version control system, update | 355 | is fetched from Git or some other version control system, update |
356 | :term:`SRCREV` to point to the | 356 | :term:`SRCREV` to point to the |
357 | commit hash that matches the new version. | 357 | commit hash that matches the new version. |
358 | 358 | ||
359 | 3. *Build the Software:* Try to build the recipe using BitBake. Typical | 359 | #. *Build the Software:* Try to build the recipe using BitBake. Typical |
360 | build failures include the following: | 360 | build failures include the following: |
361 | 361 | ||
362 | - License statements were updated for the new version. For this | 362 | - License statements were updated for the new version. For this |
@@ -377,22 +377,22 @@ To manually upgrade recipe versions, follow these general steps: | |||
377 | issues. If a patch is necessary and failing, you need to rebase it | 377 | issues. If a patch is necessary and failing, you need to rebase it |
378 | into the new version. | 378 | into the new version. |
379 | 379 | ||
380 | 4. *Optionally Attempt to Build for Several Architectures:* Once you | 380 | #. *Optionally Attempt to Build for Several Architectures:* Once you |
381 | successfully build the new software for a given architecture, you | 381 | successfully build the new software for a given architecture, you |
382 | could test the build for other architectures by changing the | 382 | could test the build for other architectures by changing the |
383 | :term:`MACHINE` variable and | 383 | :term:`MACHINE` variable and |
384 | rebuilding the software. This optional step is especially important | 384 | rebuilding the software. This optional step is especially important |
385 | if the recipe is to be released publicly. | 385 | if the recipe is to be released publicly. |
386 | 386 | ||
387 | 5. *Check the Upstream Change Log or Release Notes:* Checking both these | 387 | #. *Check the Upstream Change Log or Release Notes:* Checking both these |
388 | reveals if there are new features that could break | 388 | reveals if there are new features that could break |
389 | backwards-compatibility. If so, you need to take steps to mitigate or | 389 | backwards-compatibility. If so, you need to take steps to mitigate or |
390 | eliminate that situation. | 390 | eliminate that situation. |
391 | 391 | ||
392 | 6. *Optionally Create a Bootable Image and Test:* If you want, you can | 392 | #. *Optionally Create a Bootable Image and Test:* If you want, you can |
393 | test the new software by booting it onto actual hardware. | 393 | test the new software by booting it onto actual hardware. |
394 | 394 | ||
395 | 7. *Create a Commit with the Change in the Layer Repository:* After all | 395 | #. *Create a Commit with the Change in the Layer Repository:* After all |
396 | builds work and any testing is successful, you can create commits for | 396 | builds work and any testing is successful, you can create commits for |
397 | any changes in the layer holding your upgraded recipe. | 397 | any changes in the layer holding your upgraded recipe. |
398 | 398 | ||
diff --git a/documentation/dev-manual/wayland.rst b/documentation/dev-manual/wayland.rst index bcbf40acc5..097be9cbde 100644 --- a/documentation/dev-manual/wayland.rst +++ b/documentation/dev-manual/wayland.rst | |||
@@ -78,13 +78,13 @@ Alternatively, you can run Weston through the command-line interpretor | |||
78 | (CLI), which is better suited for development work. To run Weston under | 78 | (CLI), which is better suited for development work. To run Weston under |
79 | the CLI, you need to do the following after your image is built: | 79 | the CLI, you need to do the following after your image is built: |
80 | 80 | ||
81 | 1. Run these commands to export ``XDG_RUNTIME_DIR``:: | 81 | #. Run these commands to export ``XDG_RUNTIME_DIR``:: |
82 | 82 | ||
83 | mkdir -p /tmp/$USER-weston | 83 | mkdir -p /tmp/$USER-weston |
84 | chmod 0700 /tmp/$USER-weston | 84 | chmod 0700 /tmp/$USER-weston |
85 | export XDG_RUNTIME_DIR=/tmp/$USER-weston | 85 | export XDG_RUNTIME_DIR=/tmp/$USER-weston |
86 | 86 | ||
87 | 2. Launch Weston in the shell:: | 87 | #. Launch Weston in the shell:: |
88 | 88 | ||
89 | weston | 89 | weston |
90 | 90 | ||
diff --git a/documentation/dev-manual/wic.rst b/documentation/dev-manual/wic.rst index 7ed887b270..d698cec77c 100644 --- a/documentation/dev-manual/wic.rst +++ b/documentation/dev-manual/wic.rst | |||
@@ -641,7 +641,7 @@ modify the kernel. | |||
641 | The following example examines the contents of the Wic image, deletes | 641 | The following example examines the contents of the Wic image, deletes |
642 | the existing kernel, and then inserts a new kernel: | 642 | the existing kernel, and then inserts a new kernel: |
643 | 643 | ||
644 | 1. *List the Partitions:* Use the ``wic ls`` command to list all the | 644 | #. *List the Partitions:* Use the ``wic ls`` command to list all the |
645 | partitions in the Wic image:: | 645 | partitions in the Wic image:: |
646 | 646 | ||
647 | $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic | 647 | $ wic ls tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic |
@@ -652,7 +652,7 @@ the existing kernel, and then inserts a new kernel: | |||
652 | The previous output shows two partitions in the | 652 | The previous output shows two partitions in the |
653 | ``core-image-minimal-qemux86.wic`` image. | 653 | ``core-image-minimal-qemux86.wic`` image. |
654 | 654 | ||
655 | 2. *Examine a Particular Partition:* Use the ``wic ls`` command again | 655 | #. *Examine a Particular Partition:* Use the ``wic ls`` command again |
656 | but in a different form to examine a particular partition. | 656 | but in a different form to examine a particular partition. |
657 | 657 | ||
658 | .. note:: | 658 | .. note:: |
@@ -700,12 +700,12 @@ the existing kernel, and then inserts a new kernel: | |||
700 | Add mtools_skip_check=1 to your .mtoolsrc file to skip this test | 700 | Add mtools_skip_check=1 to your .mtoolsrc file to skip this test |
701 | 701 | ||
702 | 702 | ||
703 | 3. *Remove the Old Kernel:* Use the ``wic rm`` command to remove the | 703 | #. *Remove the Old Kernel:* Use the ``wic rm`` command to remove the |
704 | ``vmlinuz`` file (kernel):: | 704 | ``vmlinuz`` file (kernel):: |
705 | 705 | ||
706 | $ wic rm tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz | 706 | $ wic rm tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic:1/vmlinuz |
707 | 707 | ||
708 | 4. *Add In the New Kernel:* Use the ``wic cp`` command to add the | 708 | #. *Add In the New Kernel:* Use the ``wic cp`` command to add the |
709 | updated kernel to the Wic image. Depending on how you built your | 709 | updated kernel to the Wic image. Depending on how you built your |
710 | kernel, it could be in different places. If you used ``devtool`` and | 710 | kernel, it could be in different places. If you used ``devtool`` and |
711 | an SDK to build your kernel, it resides in the ``tmp/work`` directory | 711 | an SDK to build your kernel, it resides in the ``tmp/work`` directory |
diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst index c4c1f629a6..fd00a9d1dc 100644 --- a/documentation/kernel-dev/common.rst +++ b/documentation/kernel-dev/common.rst | |||
@@ -52,7 +52,7 @@ image and ready to make modifications as described in the | |||
52 | ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`" | 52 | ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`" |
53 | section: | 53 | section: |
54 | 54 | ||
55 | 1. *Initialize the BitBake Environment:* | 55 | #. *Initialize the BitBake Environment:* |
56 | you need to initialize the BitBake build environment by sourcing | 56 | you need to initialize the BitBake build environment by sourcing |
57 | the build environment script (i.e. :ref:`structure-core-script`):: | 57 | the build environment script (i.e. :ref:`structure-core-script`):: |
58 | 58 | ||
@@ -66,7 +66,7 @@ section: | |||
66 | (i.e. ``poky``) have been cloned using Git and the local repository is named | 66 | (i.e. ``poky``) have been cloned using Git and the local repository is named |
67 | "poky". | 67 | "poky". |
68 | 68 | ||
69 | 2. *Prepare Your local.conf File:* By default, the :term:`MACHINE` variable | 69 | #. *Prepare Your local.conf File:* By default, the :term:`MACHINE` variable |
70 | is set to "qemux86-64", which is fine if you are building for the QEMU | 70 | is set to "qemux86-64", which is fine if you are building for the QEMU |
71 | emulator in 64-bit mode. However, if you are not, you need to set the | 71 | emulator in 64-bit mode. However, if you are not, you need to set the |
72 | :term:`MACHINE` variable appropriately in your ``conf/local.conf`` file | 72 | :term:`MACHINE` variable appropriately in your ``conf/local.conf`` file |
@@ -83,7 +83,7 @@ section: | |||
83 | MACHINE = "qemux86" | 83 | MACHINE = "qemux86" |
84 | MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" | 84 | MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" |
85 | 85 | ||
86 | 3. *Create a Layer for Patches:* You need to create a layer to hold | 86 | #. *Create a Layer for Patches:* You need to create a layer to hold |
87 | patches created for the kernel image. You can use the | 87 | patches created for the kernel image. You can use the |
88 | ``bitbake-layers create-layer`` command as follows:: | 88 | ``bitbake-layers create-layer`` command as follows:: |
89 | 89 | ||
@@ -106,7 +106,7 @@ section: | |||
106 | ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`" | 106 | ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`" |
107 | section in the Yocto Project Development Tasks Manual. | 107 | section in the Yocto Project Development Tasks Manual. |
108 | 108 | ||
109 | 4. *Inform the BitBake Build Environment About Your Layer:* As directed | 109 | #. *Inform the BitBake Build Environment About Your Layer:* As directed |
110 | when you created your layer, you need to add the layer to the | 110 | when you created your layer, you need to add the layer to the |
111 | :term:`BBLAYERS` variable in the | 111 | :term:`BBLAYERS` variable in the |
112 | ``bblayers.conf`` file as follows:: | 112 | ``bblayers.conf`` file as follows:: |
@@ -116,7 +116,7 @@ section: | |||
116 | NOTE: Starting bitbake server... | 116 | NOTE: Starting bitbake server... |
117 | $ | 117 | $ |
118 | 118 | ||
119 | 5. *Build the Clean Image:* The final step in preparing to work on the | 119 | #. *Build the Clean Image:* The final step in preparing to work on the |
120 | kernel is to build an initial image using ``bitbake``:: | 120 | kernel is to build an initial image using ``bitbake``:: |
121 | 121 | ||
122 | $ bitbake core-image-minimal | 122 | $ bitbake core-image-minimal |
@@ -158,7 +158,7 @@ this procedure leaves you ready to make modifications to the kernel | |||
158 | source as described in the ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`" | 158 | source as described in the ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`" |
159 | section: | 159 | section: |
160 | 160 | ||
161 | 1. *Initialize the BitBake Environment:* Before you can do anything | 161 | #. *Initialize the BitBake Environment:* Before you can do anything |
162 | using BitBake, you need to initialize the BitBake build environment | 162 | using BitBake, you need to initialize the BitBake build environment |
163 | by sourcing the build environment script (i.e. | 163 | by sourcing the build environment script (i.e. |
164 | :ref:`structure-core-script`). | 164 | :ref:`structure-core-script`). |
@@ -181,7 +181,7 @@ section: | |||
181 | (i.e. ``poky``) have been cloned using Git and the local repository is named | 181 | (i.e. ``poky``) have been cloned using Git and the local repository is named |
182 | "poky". | 182 | "poky". |
183 | 183 | ||
184 | 2. *Prepare Your local.conf File:* By default, the :term:`MACHINE` variable is | 184 | #. *Prepare Your local.conf File:* By default, the :term:`MACHINE` variable is |
185 | set to "qemux86-64", which is fine if you are building for the QEMU emulator | 185 | set to "qemux86-64", which is fine if you are building for the QEMU emulator |
186 | in 64-bit mode. However, if you are not, you need to set the :term:`MACHINE` | 186 | in 64-bit mode. However, if you are not, you need to set the :term:`MACHINE` |
187 | variable appropriately in your ``conf/local.conf`` file found in the | 187 | variable appropriately in your ``conf/local.conf`` file found in the |
@@ -199,7 +199,7 @@ section: | |||
199 | MACHINE = "qemux86" | 199 | MACHINE = "qemux86" |
200 | MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" | 200 | MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules" |
201 | 201 | ||
202 | 3. *Create a Layer for Patches:* You need to create a layer to hold | 202 | #. *Create a Layer for Patches:* You need to create a layer to hold |
203 | patches created for the kernel image. You can use the | 203 | patches created for the kernel image. You can use the |
204 | ``bitbake-layers create-layer`` command as follows:: | 204 | ``bitbake-layers create-layer`` command as follows:: |
205 | 205 | ||
@@ -221,7 +221,7 @@ section: | |||
221 | ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`" | 221 | ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`" |
222 | section in the Yocto Project Development Tasks Manual. | 222 | section in the Yocto Project Development Tasks Manual. |
223 | 223 | ||
224 | 4. *Inform the BitBake Build Environment About Your Layer:* As directed | 224 | #. *Inform the BitBake Build Environment About Your Layer:* As directed |
225 | when you created your layer, you need to add the layer to the | 225 | when you created your layer, you need to add the layer to the |
226 | :term:`BBLAYERS` variable in the | 226 | :term:`BBLAYERS` variable in the |
227 | ``bblayers.conf`` file as follows:: | 227 | ``bblayers.conf`` file as follows:: |
@@ -231,7 +231,7 @@ section: | |||
231 | NOTE: Starting bitbake server ... | 231 | NOTE: Starting bitbake server ... |
232 | $ | 232 | $ |
233 | 233 | ||
234 | 5. *Create a Local Copy of the Kernel Git Repository:* You can find Git | 234 | #. *Create a Local Copy of the Kernel Git Repository:* You can find Git |
235 | repositories of supported Yocto Project kernels organized under | 235 | repositories of supported Yocto Project kernels organized under |
236 | "Yocto Linux Kernel" in the Yocto Project Source Repositories at | 236 | "Yocto Linux Kernel" in the Yocto Project Source Repositories at |
237 | :yocto_git:`/`. | 237 | :yocto_git:`/`. |
@@ -262,7 +262,7 @@ section: | |||
262 | You cannot use the ``linux-yocto-4.12`` kernel with releases prior to | 262 | You cannot use the ``linux-yocto-4.12`` kernel with releases prior to |
263 | Yocto Project 2.4. | 263 | Yocto Project 2.4. |
264 | 264 | ||
265 | 6. *Create a Local Copy of the Kernel Cache Git Repository:* For | 265 | #. *Create a Local Copy of the Kernel Cache Git Repository:* For |
266 | simplicity, it is recommended that you create your copy of the kernel | 266 | simplicity, it is recommended that you create your copy of the kernel |
267 | cache Git repository outside of the | 267 | cache Git repository outside of the |
268 | :term:`Source Directory`, which is | 268 | :term:`Source Directory`, which is |
@@ -313,7 +313,7 @@ following section describes how to create a layer without the aid of | |||
313 | tools. These steps assume creation of a layer named ``mylayer`` in your | 313 | tools. These steps assume creation of a layer named ``mylayer`` in your |
314 | home directory: | 314 | home directory: |
315 | 315 | ||
316 | 1. *Create Structure*: Create the layer's structure:: | 316 | #. *Create Structure*: Create the layer's structure:: |
317 | 317 | ||
318 | $ mkdir meta-mylayer | 318 | $ mkdir meta-mylayer |
319 | $ mkdir meta-mylayer/conf | 319 | $ mkdir meta-mylayer/conf |
@@ -325,7 +325,7 @@ home directory: | |||
325 | ``recipes-kernel`` directory holds your append file and eventual | 325 | ``recipes-kernel`` directory holds your append file and eventual |
326 | patch files. | 326 | patch files. |
327 | 327 | ||
328 | 2. *Create the Layer Configuration File*: Move to the | 328 | #. *Create the Layer Configuration File*: Move to the |
329 | ``meta-mylayer/conf`` directory and create the ``layer.conf`` file as | 329 | ``meta-mylayer/conf`` directory and create the ``layer.conf`` file as |
330 | follows:: | 330 | follows:: |
331 | 331 | ||
@@ -342,7 +342,7 @@ home directory: | |||
342 | 342 | ||
343 | Notice ``mylayer`` as part of the last three statements. | 343 | Notice ``mylayer`` as part of the last three statements. |
344 | 344 | ||
345 | 3. *Create the Kernel Recipe Append File*: Move to the | 345 | #. *Create the Kernel Recipe Append File*: Move to the |
346 | ``meta-mylayer/recipes-kernel/linux`` directory and create the | 346 | ``meta-mylayer/recipes-kernel/linux`` directory and create the |
347 | kernel's append file. This example uses the ``linux-yocto-4.12`` | 347 | kernel's append file. This example uses the ``linux-yocto-4.12`` |
348 | kernel. Thus, the name of the append file is | 348 | kernel. Thus, the name of the append file is |
@@ -695,7 +695,7 @@ modified image causes the added messages to appear on the emulator's | |||
695 | console. The example is a continuation of the setup procedure found in | 695 | console. The example is a continuation of the setup procedure found in |
696 | the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Section. | 696 | the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Section. |
697 | 697 | ||
698 | 1. *Check Out the Kernel Source Files:* First you must use ``devtool`` | 698 | #. *Check Out the Kernel Source Files:* First you must use ``devtool`` |
699 | to checkout the kernel source code in its workspace. | 699 | to checkout the kernel source code in its workspace. |
700 | 700 | ||
701 | .. note:: | 701 | .. note:: |
@@ -723,10 +723,10 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se | |||
723 | You can safely ignore these messages. The source code is correctly | 723 | You can safely ignore these messages. The source code is correctly |
724 | checked out. | 724 | checked out. |
725 | 725 | ||
726 | 2. *Edit the Source Files* Follow these steps to make some simple | 726 | #. *Edit the Source Files* Follow these steps to make some simple |
727 | changes to the source files: | 727 | changes to the source files: |
728 | 728 | ||
729 | 1. *Change the working directory*: In the previous step, the output | 729 | #. *Change the working directory*: In the previous step, the output |
730 | noted where you can find the source files (e.g. | 730 | noted where you can find the source files (e.g. |
731 | ``poky_sdk/workspace/sources/linux-yocto``). Change to where the | 731 | ``poky_sdk/workspace/sources/linux-yocto``). Change to where the |
732 | kernel source code is before making your edits to the | 732 | kernel source code is before making your edits to the |
@@ -734,7 +734,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se | |||
734 | 734 | ||
735 | $ cd poky_sdk/workspace/sources/linux-yocto | 735 | $ cd poky_sdk/workspace/sources/linux-yocto |
736 | 736 | ||
737 | 2. *Edit the source file*: Edit the ``init/calibrate.c`` file to have | 737 | #. *Edit the source file*: Edit the ``init/calibrate.c`` file to have |
738 | the following changes:: | 738 | the following changes:: |
739 | 739 | ||
740 | void calibrate_delay(void) | 740 | void calibrate_delay(void) |
@@ -754,12 +754,12 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se | |||
754 | . | 754 | . |
755 | . | 755 | . |
756 | 756 | ||
757 | 3. *Build the Updated Kernel Source:* To build the updated kernel | 757 | #. *Build the Updated Kernel Source:* To build the updated kernel |
758 | source, use ``devtool``:: | 758 | source, use ``devtool``:: |
759 | 759 | ||
760 | $ devtool build linux-yocto | 760 | $ devtool build linux-yocto |
761 | 761 | ||
762 | 4. *Create the Image With the New Kernel:* Use the | 762 | #. *Create the Image With the New Kernel:* Use the |
763 | ``devtool build-image`` command to create a new image that has the | 763 | ``devtool build-image`` command to create a new image that has the |
764 | new kernel:: | 764 | new kernel:: |
765 | 765 | ||
@@ -774,15 +774,15 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se | |||
774 | :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </TipsAndTricks/KernelDevelopmentWithEsdk>` | 774 | :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </TipsAndTricks/KernelDevelopmentWithEsdk>` |
775 | Wiki Page. | 775 | Wiki Page. |
776 | 776 | ||
777 | 5. *Test the New Image:* For this example, you can run the new image | 777 | #. *Test the New Image:* For this example, you can run the new image |
778 | using QEMU to verify your changes: | 778 | using QEMU to verify your changes: |
779 | 779 | ||
780 | 1. *Boot the image*: Boot the modified image in the QEMU emulator | 780 | #. *Boot the image*: Boot the modified image in the QEMU emulator |
781 | using this command:: | 781 | using this command:: |
782 | 782 | ||
783 | $ runqemu qemux86 | 783 | $ runqemu qemux86 |
784 | 784 | ||
785 | 2. *Verify the changes*: Log into the machine using ``root`` with no | 785 | #. *Verify the changes*: Log into the machine using ``root`` with no |
786 | password and then use the following shell command to scroll | 786 | password and then use the following shell command to scroll |
787 | through the console's boot output. | 787 | through the console's boot output. |
788 | 788 | ||
@@ -794,7 +794,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se | |||
794 | the results of your ``printk`` statements as part of the output | 794 | the results of your ``printk`` statements as part of the output |
795 | when you scroll down the console window. | 795 | when you scroll down the console window. |
796 | 796 | ||
797 | 6. *Stage and commit your changes*: Change | 797 | #. *Stage and commit your changes*: Change |
798 | your working directory to where you modified the ``calibrate.c`` file | 798 | your working directory to where you modified the ``calibrate.c`` file |
799 | and use these Git commands to stage and commit your changes:: | 799 | and use these Git commands to stage and commit your changes:: |
800 | 800 | ||
@@ -803,7 +803,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se | |||
803 | $ git add init/calibrate.c | 803 | $ git add init/calibrate.c |
804 | $ git commit -m "calibrate: Add printk example" | 804 | $ git commit -m "calibrate: Add printk example" |
805 | 805 | ||
806 | 7. *Export the Patches and Create an Append File:* To export your | 806 | #. *Export the Patches and Create an Append File:* To export your |
807 | commits as patches and create a ``.bbappend`` file, use the following | 807 | commits as patches and create a ``.bbappend`` file, use the following |
808 | command. This example uses the previously established layer named ``meta-mylayer``:: | 808 | command. This example uses the previously established layer named ``meta-mylayer``:: |
809 | 809 | ||
@@ -819,7 +819,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se | |||
819 | finishes, the patches and the ``.bbappend`` file are located in the | 819 | finishes, the patches and the ``.bbappend`` file are located in the |
820 | ``~/meta-mylayer/recipes-kernel/linux`` directory. | 820 | ``~/meta-mylayer/recipes-kernel/linux`` directory. |
821 | 821 | ||
822 | 8. *Build the Image With Your Modified Kernel:* You can now build an | 822 | #. *Build the Image With Your Modified Kernel:* You can now build an |
823 | image that includes your kernel patches. Execute the following | 823 | image that includes your kernel patches. Execute the following |
824 | command from your :term:`Build Directory` in the terminal | 824 | command from your :term:`Build Directory` in the terminal |
825 | set up to run BitBake:: | 825 | set up to run BitBake:: |
@@ -857,20 +857,20 @@ found in the | |||
857 | ":ref:`kernel-dev/common:getting ready for traditional kernel development`" | 857 | ":ref:`kernel-dev/common:getting ready for traditional kernel development`" |
858 | Section. | 858 | Section. |
859 | 859 | ||
860 | 1. *Edit the Source Files* Prior to this step, you should have used Git | 860 | #. *Edit the Source Files* Prior to this step, you should have used Git |
861 | to create a local copy of the repository for your kernel. Assuming | 861 | to create a local copy of the repository for your kernel. Assuming |
862 | you created the repository as directed in the | 862 | you created the repository as directed in the |
863 | ":ref:`kernel-dev/common:getting ready for traditional kernel development`" | 863 | ":ref:`kernel-dev/common:getting ready for traditional kernel development`" |
864 | section, use the following commands to edit the ``calibrate.c`` file: | 864 | section, use the following commands to edit the ``calibrate.c`` file: |
865 | 865 | ||
866 | 1. *Change the working directory*: You need to locate the source | 866 | #. *Change the working directory*: You need to locate the source |
867 | files in the local copy of the kernel Git repository. Change to | 867 | files in the local copy of the kernel Git repository. Change to |
868 | where the kernel source code is before making your edits to the | 868 | where the kernel source code is before making your edits to the |
869 | ``calibrate.c`` file:: | 869 | ``calibrate.c`` file:: |
870 | 870 | ||
871 | $ cd ~/linux-yocto-4.12/init | 871 | $ cd ~/linux-yocto-4.12/init |
872 | 872 | ||
873 | 2. *Edit the source file*: Edit the ``calibrate.c`` file to have the | 873 | #. *Edit the source file*: Edit the ``calibrate.c`` file to have the |
874 | following changes:: | 874 | following changes:: |
875 | 875 | ||
876 | void calibrate_delay(void) | 876 | void calibrate_delay(void) |
@@ -890,7 +890,7 @@ Section. | |||
890 | . | 890 | . |
891 | . | 891 | . |
892 | 892 | ||
893 | 2. *Stage and Commit Your Changes:* Use standard Git commands to stage | 893 | #. *Stage and Commit Your Changes:* Use standard Git commands to stage |
894 | and commit the changes you just made:: | 894 | and commit the changes you just made:: |
895 | 895 | ||
896 | $ git add calibrate.c | 896 | $ git add calibrate.c |
@@ -900,7 +900,7 @@ Section. | |||
900 | stage and commit your changes, the OpenEmbedded Build System will not | 900 | stage and commit your changes, the OpenEmbedded Build System will not |
901 | pick up the changes. | 901 | pick up the changes. |
902 | 902 | ||
903 | 3. *Update Your local.conf File to Point to Your Source Files:* In | 903 | #. *Update Your local.conf File to Point to Your Source Files:* In |
904 | addition to your ``local.conf`` file specifying to use | 904 | addition to your ``local.conf`` file specifying to use |
905 | "kernel-modules" and the "qemux86" machine, it must also point to the | 905 | "kernel-modules" and the "qemux86" machine, it must also point to the |
906 | updated kernel source files. Add | 906 | updated kernel source files. Add |
@@ -924,21 +924,21 @@ Section. | |||
924 | be sure to specify the correct branch and machine types. For this | 924 | be sure to specify the correct branch and machine types. For this |
925 | example, the branch is ``standard/base`` and the machine is ``qemux86``. | 925 | example, the branch is ``standard/base`` and the machine is ``qemux86``. |
926 | 926 | ||
927 | 4. *Build the Image:* With the source modified, your changes staged and | 927 | #. *Build the Image:* With the source modified, your changes staged and |
928 | committed, and the ``local.conf`` file pointing to the kernel files, | 928 | committed, and the ``local.conf`` file pointing to the kernel files, |
929 | you can now use BitBake to build the image:: | 929 | you can now use BitBake to build the image:: |
930 | 930 | ||
931 | $ cd poky/build | 931 | $ cd poky/build |
932 | $ bitbake core-image-minimal | 932 | $ bitbake core-image-minimal |
933 | 933 | ||
934 | 5. *Boot the image*: Boot the modified image in the QEMU emulator using | 934 | #. *Boot the image*: Boot the modified image in the QEMU emulator using |
935 | this command. When prompted to login to the QEMU console, use "root" | 935 | this command. When prompted to login to the QEMU console, use "root" |
936 | with no password:: | 936 | with no password:: |
937 | 937 | ||
938 | $ cd poky/build | 938 | $ cd poky/build |
939 | $ runqemu qemux86 | 939 | $ runqemu qemux86 |
940 | 940 | ||
941 | 6. *Look for Your Changes:* As QEMU booted, you might have seen your | 941 | #. *Look for Your Changes:* As QEMU booted, you might have seen your |
942 | changes rapidly scroll by. If not, use these commands to see your | 942 | changes rapidly scroll by. If not, use these commands to see your |
943 | changes: | 943 | changes: |
944 | 944 | ||
@@ -950,7 +950,7 @@ Section. | |||
950 | ``printk`` statements as part of the output when you scroll down the | 950 | ``printk`` statements as part of the output when you scroll down the |
951 | console window. | 951 | console window. |
952 | 952 | ||
953 | 7. *Generate the Patch File:* Once you are sure that your patch works | 953 | #. *Generate the Patch File:* Once you are sure that your patch works |
954 | correctly, you can generate a ``*.patch`` file in the kernel source | 954 | correctly, you can generate a ``*.patch`` file in the kernel source |
955 | repository:: | 955 | repository:: |
956 | 956 | ||
@@ -958,7 +958,7 @@ Section. | |||
958 | $ git format-patch -1 | 958 | $ git format-patch -1 |
959 | 0001-calibrate.c-Added-some-printk-statements.patch | 959 | 0001-calibrate.c-Added-some-printk-statements.patch |
960 | 960 | ||
961 | 8. *Move the Patch File to Your Layer:* In order for subsequent builds | 961 | #. *Move the Patch File to Your Layer:* In order for subsequent builds |
962 | to pick up patches, you need to move the patch file you created in | 962 | to pick up patches, you need to move the patch file you created in |
963 | the previous step to your layer ``meta-mylayer``. For this example, | 963 | the previous step to your layer ``meta-mylayer``. For this example, |
964 | the layer created earlier is located in your home directory as | 964 | the layer created earlier is located in your home directory as |
@@ -978,7 +978,7 @@ Section. | |||
978 | 978 | ||
979 | $ mv ~/linux-yocto-4.12/init/0001-calibrate.c-Added-some-printk-statements.patch ~/meta-mylayer/recipes-kernel/linux/linux-yocto | 979 | $ mv ~/linux-yocto-4.12/init/0001-calibrate.c-Added-some-printk-statements.patch ~/meta-mylayer/recipes-kernel/linux/linux-yocto |
980 | 980 | ||
981 | 9. *Create the Append File:* Finally, you need to create the | 981 | #. *Create the Append File:* Finally, you need to create the |
982 | ``linux-yocto_4.12.bbappend`` file and insert statements that allow | 982 | ``linux-yocto_4.12.bbappend`` file and insert statements that allow |
983 | the OpenEmbedded build system to find the patch. The append file | 983 | the OpenEmbedded build system to find the patch. The append file |
984 | needs to be in your layer's ``recipes-kernel/linux`` directory and it | 984 | needs to be in your layer's ``recipes-kernel/linux`` directory and it |
@@ -1223,7 +1223,7 @@ saved, and one freshly created using the ``menuconfig`` tool. | |||
1223 | To create a configuration fragment using this method, follow these | 1223 | To create a configuration fragment using this method, follow these |
1224 | steps: | 1224 | steps: |
1225 | 1225 | ||
1226 | 1. *Complete a Build Through Kernel Configuration:* Complete a build at | 1226 | #. *Complete a Build Through Kernel Configuration:* Complete a build at |
1227 | least through the kernel configuration task as follows:: | 1227 | least through the kernel configuration task as follows:: |
1228 | 1228 | ||
1229 | $ bitbake linux-yocto -c kernel_configme -f | 1229 | $ bitbake linux-yocto -c kernel_configme -f |
@@ -1233,11 +1233,11 @@ steps: | |||
1233 | your build state might become unknown, it is best to run this task | 1233 | your build state might become unknown, it is best to run this task |
1234 | prior to starting ``menuconfig``. | 1234 | prior to starting ``menuconfig``. |
1235 | 1235 | ||
1236 | 2. *Launch menuconfig:* Run the ``menuconfig`` command:: | 1236 | #. *Launch menuconfig:* Run the ``menuconfig`` command:: |
1237 | 1237 | ||
1238 | $ bitbake linux-yocto -c menuconfig | 1238 | $ bitbake linux-yocto -c menuconfig |
1239 | 1239 | ||
1240 | 3. *Create the Configuration Fragment:* Run the ``diffconfig`` command | 1240 | #. *Create the Configuration Fragment:* Run the ``diffconfig`` command |
1241 | to prepare a configuration fragment. The resulting file | 1241 | to prepare a configuration fragment. The resulting file |
1242 | ``fragment.cfg`` is placed in the | 1242 | ``fragment.cfg`` is placed in the |
1243 | ``${``\ :term:`WORKDIR`\ ``}`` | 1243 | ``${``\ :term:`WORKDIR`\ ``}`` |
@@ -1408,17 +1408,17 @@ configuration. | |||
1408 | 1408 | ||
1409 | To streamline the configuration, do the following: | 1409 | To streamline the configuration, do the following: |
1410 | 1410 | ||
1411 | 1. *Use a Working Configuration:* Start with a full configuration that | 1411 | #. *Use a Working Configuration:* Start with a full configuration that |
1412 | you know works. Be sure the configuration builds and boots | 1412 | you know works. Be sure the configuration builds and boots |
1413 | successfully. Use this configuration file as your baseline. | 1413 | successfully. Use this configuration file as your baseline. |
1414 | 1414 | ||
1415 | 2. *Run Configure and Check Tasks:* Separately run the | 1415 | #. *Run Configure and Check Tasks:* Separately run the |
1416 | :ref:`ref-tasks-kernel_configme` and :ref:`ref-tasks-kernel_configcheck` tasks:: | 1416 | :ref:`ref-tasks-kernel_configme` and :ref:`ref-tasks-kernel_configcheck` tasks:: |
1417 | 1417 | ||
1418 | $ bitbake linux-yocto -c kernel_configme -f | 1418 | $ bitbake linux-yocto -c kernel_configme -f |
1419 | $ bitbake linux-yocto -c kernel_configcheck -f | 1419 | $ bitbake linux-yocto -c kernel_configcheck -f |
1420 | 1420 | ||
1421 | 3. *Process the Results:* Take the resulting list of files from the | 1421 | #. *Process the Results:* Take the resulting list of files from the |
1422 | :ref:`ref-tasks-kernel_configcheck` task warnings and do the following: | 1422 | :ref:`ref-tasks-kernel_configcheck` task warnings and do the following: |
1423 | 1423 | ||
1424 | - Drop values that are redefined in the fragment but do not change | 1424 | - Drop values that are redefined in the fragment but do not change |
@@ -1431,7 +1431,7 @@ To streamline the configuration, do the following: | |||
1431 | 1431 | ||
1432 | - Remove repeated and invalid options. | 1432 | - Remove repeated and invalid options. |
1433 | 1433 | ||
1434 | 4. *Re-Run Configure and Check Tasks:* After you have worked through the | 1434 | #. *Re-Run Configure and Check Tasks:* After you have worked through the |
1435 | output of the kernel configuration audit, you can re-run the | 1435 | output of the kernel configuration audit, you can re-run the |
1436 | :ref:`ref-tasks-kernel_configme` and :ref:`ref-tasks-kernel_configcheck` tasks to see the | 1436 | :ref:`ref-tasks-kernel_configme` and :ref:`ref-tasks-kernel_configcheck` tasks to see the |
1437 | results of your changes. If you have more issues, you can deal with | 1437 | results of your changes. If you have more issues, you can deal with |
@@ -1462,20 +1462,20 @@ If you build a kernel image and the version string has a "+" or a | |||
1462 | "-dirty" at the end, it means there are uncommitted modifications in the kernel's | 1462 | "-dirty" at the end, it means there are uncommitted modifications in the kernel's |
1463 | source directory. Follow these steps to clean up the version string: | 1463 | source directory. Follow these steps to clean up the version string: |
1464 | 1464 | ||
1465 | 1. *Discover the Uncommitted Changes:* Go to the kernel's locally cloned | 1465 | #. *Discover the Uncommitted Changes:* Go to the kernel's locally cloned |
1466 | Git repository (source directory) and use the following Git command | 1466 | Git repository (source directory) and use the following Git command |
1467 | to list the files that have been changed, added, or removed:: | 1467 | to list the files that have been changed, added, or removed:: |
1468 | 1468 | ||
1469 | $ git status | 1469 | $ git status |
1470 | 1470 | ||
1471 | 2. *Commit the Changes:* You should commit those changes to the kernel | 1471 | #. *Commit the Changes:* You should commit those changes to the kernel |
1472 | source tree regardless of whether or not you will save, export, or | 1472 | source tree regardless of whether or not you will save, export, or |
1473 | use the changes:: | 1473 | use the changes:: |
1474 | 1474 | ||
1475 | $ git add | 1475 | $ git add |
1476 | $ git commit -s -a -m "getting rid of -dirty" | 1476 | $ git commit -s -a -m "getting rid of -dirty" |
1477 | 1477 | ||
1478 | 3. *Rebuild the Kernel Image:* Once you commit the changes, rebuild the | 1478 | #. *Rebuild the Kernel Image:* Once you commit the changes, rebuild the |
1479 | kernel. | 1479 | kernel. |
1480 | 1480 | ||
1481 | Depending on your particular kernel development workflow, the | 1481 | Depending on your particular kernel development workflow, the |
@@ -1509,18 +1509,18 @@ You can find this recipe in the ``poky`` Git repository: | |||
1509 | 1509 | ||
1510 | Here are some basic steps you can use to work with your own sources: | 1510 | Here are some basic steps you can use to work with your own sources: |
1511 | 1511 | ||
1512 | 1. *Create a Copy of the Kernel Recipe:* Copy the | 1512 | #. *Create a Copy of the Kernel Recipe:* Copy the |
1513 | ``linux-yocto-custom.bb`` recipe to your layer and give it a | 1513 | ``linux-yocto-custom.bb`` recipe to your layer and give it a |
1514 | meaningful name. The name should include the version of the Yocto | 1514 | meaningful name. The name should include the version of the Yocto |
1515 | Linux kernel you are using (e.g. ``linux-yocto-myproject_4.12.bb``, | 1515 | Linux kernel you are using (e.g. ``linux-yocto-myproject_4.12.bb``, |
1516 | where "4.12" is the base version of the Linux kernel with which you | 1516 | where "4.12" is the base version of the Linux kernel with which you |
1517 | would be working). | 1517 | would be working). |
1518 | 1518 | ||
1519 | 2. *Create a Directory for Your Patches:* In the same directory inside | 1519 | #. *Create a Directory for Your Patches:* In the same directory inside |
1520 | your layer, create a matching directory to store your patches and | 1520 | your layer, create a matching directory to store your patches and |
1521 | configuration files (e.g. ``linux-yocto-myproject``). | 1521 | configuration files (e.g. ``linux-yocto-myproject``). |
1522 | 1522 | ||
1523 | 3. *Ensure You Have Configurations:* Make sure you have either a | 1523 | #. *Ensure You Have Configurations:* Make sure you have either a |
1524 | ``defconfig`` file or configuration fragment files in your layer. | 1524 | ``defconfig`` file or configuration fragment files in your layer. |
1525 | When you use the ``linux-yocto-custom.bb`` recipe, you must specify a | 1525 | When you use the ``linux-yocto-custom.bb`` recipe, you must specify a |
1526 | configuration. If you do not have a ``defconfig`` file, you can run | 1526 | configuration. If you do not have a ``defconfig`` file, you can run |
@@ -1545,7 +1545,7 @@ Here are some basic steps you can use to work with your own sources: | |||
1545 | ``arch/arm/configs`` and use the one that is the best starting point | 1545 | ``arch/arm/configs`` and use the one that is the best starting point |
1546 | for your board). | 1546 | for your board). |
1547 | 1547 | ||
1548 | 4. *Edit the Recipe:* Edit the following variables in your recipe as | 1548 | #. *Edit the Recipe:* Edit the following variables in your recipe as |
1549 | appropriate for your project: | 1549 | appropriate for your project: |
1550 | 1550 | ||
1551 | - :term:`SRC_URI`: The | 1551 | - :term:`SRC_URI`: The |
@@ -1594,7 +1594,7 @@ Here are some basic steps you can use to work with your own sources: | |||
1594 | 1594 | ||
1595 | COMPATIBLE_MACHINE = "qemux86|qemux86-64" | 1595 | COMPATIBLE_MACHINE = "qemux86|qemux86-64" |
1596 | 1596 | ||
1597 | 5. *Customize Your Recipe as Needed:* Provide further customizations to | 1597 | #. *Customize Your Recipe as Needed:* Provide further customizations to |
1598 | your recipe as needed just as you would customize an existing | 1598 | your recipe as needed just as you would customize an existing |
1599 | linux-yocto recipe. See the | 1599 | linux-yocto recipe. See the |
1600 | ":ref:`ref-manual/devtool-reference:modifying an existing recipe`" section | 1600 | ":ref:`ref-manual/devtool-reference:modifying an existing recipe`" section |
@@ -1826,7 +1826,7 @@ kernel features. | |||
1826 | Consider the following example that adds the "test.scc" feature to the | 1826 | Consider the following example that adds the "test.scc" feature to the |
1827 | build. | 1827 | build. |
1828 | 1828 | ||
1829 | 1. *Create the Feature File:* Create a ``.scc`` file and locate it just | 1829 | #. *Create the Feature File:* Create a ``.scc`` file and locate it just |
1830 | as you would any other patch file, ``.cfg`` file, or fetcher item you | 1830 | as you would any other patch file, ``.cfg`` file, or fetcher item you |
1831 | specify in the :term:`SRC_URI` statement. | 1831 | specify in the :term:`SRC_URI` statement. |
1832 | 1832 | ||
@@ -1854,7 +1854,7 @@ build. | |||
1854 | ``linux-yocto`` directory has both the feature ``test.scc`` file and | 1854 | ``linux-yocto`` directory has both the feature ``test.scc`` file and |
1855 | a similarly named configuration fragment file ``test.cfg``. | 1855 | a similarly named configuration fragment file ``test.cfg``. |
1856 | 1856 | ||
1857 | 2. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the | 1857 | #. *Add the Feature File to SRC_URI:* Add the ``.scc`` file to the |
1858 | recipe's :term:`SRC_URI` statement:: | 1858 | recipe's :term:`SRC_URI` statement:: |
1859 | 1859 | ||
1860 | SRC_URI += "file://test.scc" | 1860 | SRC_URI += "file://test.scc" |
@@ -1862,7 +1862,7 @@ build. | |||
1862 | The leading space before the path is important as the path is | 1862 | The leading space before the path is important as the path is |
1863 | appended to the existing path. | 1863 | appended to the existing path. |
1864 | 1864 | ||
1865 | 3. *Specify the Feature as a Kernel Feature:* Use the | 1865 | #. *Specify the Feature as a Kernel Feature:* Use the |
1866 | :term:`KERNEL_FEATURES` statement to specify the feature as a kernel | 1866 | :term:`KERNEL_FEATURES` statement to specify the feature as a kernel |
1867 | feature:: | 1867 | feature:: |
1868 | 1868 | ||
diff --git a/documentation/kernel-dev/intro.rst b/documentation/kernel-dev/intro.rst index 06cc884386..a663733a1d 100644 --- a/documentation/kernel-dev/intro.rst +++ b/documentation/kernel-dev/intro.rst | |||
@@ -108,12 +108,12 @@ general information and references for further information. | |||
108 | .. image:: figures/kernel-dev-flow.png | 108 | .. image:: figures/kernel-dev-flow.png |
109 | :width: 100% | 109 | :width: 100% |
110 | 110 | ||
111 | 1. *Set up Your Host Development System to Support Development Using the | 111 | #. *Set up Your Host Development System to Support Development Using the |
112 | Yocto Project*: See the ":doc:`/dev-manual/start`" section in | 112 | Yocto Project*: See the ":doc:`/dev-manual/start`" section in |
113 | the Yocto Project Development Tasks Manual for options on how to get | 113 | the Yocto Project Development Tasks Manual for options on how to get |
114 | a build host ready to use the Yocto Project. | 114 | a build host ready to use the Yocto Project. |
115 | 115 | ||
116 | 2. *Set Up Your Host Development System for Kernel Development:* It is | 116 | #. *Set Up Your Host Development System for Kernel Development:* It is |
117 | recommended that you use ``devtool`` for kernel | 117 | recommended that you use ``devtool`` for kernel |
118 | development. Alternatively, you can use traditional kernel | 118 | development. Alternatively, you can use traditional kernel |
119 | development methods with the Yocto Project. Either way, there are | 119 | development methods with the Yocto Project. Either way, there are |
@@ -131,7 +131,7 @@ general information and references for further information. | |||
131 | ":ref:`kernel-dev/common:getting ready for traditional kernel development`" | 131 | ":ref:`kernel-dev/common:getting ready for traditional kernel development`" |
132 | section. | 132 | section. |
133 | 133 | ||
134 | 3. *Make Changes to the Kernel Source Code if applicable:* Modifying the | 134 | #. *Make Changes to the Kernel Source Code if applicable:* Modifying the |
135 | kernel does not always mean directly changing source files. However, | 135 | kernel does not always mean directly changing source files. However, |
136 | if you have to do this, you make the changes to the files in the | 136 | if you have to do this, you make the changes to the files in the |
137 | Yocto's :term:`Build Directory` if you are using ``devtool``. For more | 137 | Yocto's :term:`Build Directory` if you are using ``devtool``. For more |
@@ -144,7 +144,7 @@ general information and references for further information. | |||
144 | ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`" | 144 | ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`" |
145 | section. | 145 | section. |
146 | 146 | ||
147 | 4. *Make Kernel Configuration Changes if Applicable:* If your situation | 147 | #. *Make Kernel Configuration Changes if Applicable:* If your situation |
148 | calls for changing the kernel's configuration, you can use | 148 | calls for changing the kernel's configuration, you can use |
149 | :ref:`menuconfig <kernel-dev/common:using \`\`menuconfig\`\`>`, | 149 | :ref:`menuconfig <kernel-dev/common:using \`\`menuconfig\`\`>`, |
150 | which allows you to | 150 | which allows you to |
@@ -169,7 +169,7 @@ general information and references for further information. | |||
169 | Additionally, if you are working in a BSP layer and need to modify | 169 | Additionally, if you are working in a BSP layer and need to modify |
170 | the BSP's kernel's configuration, you can use ``menuconfig``. | 170 | the BSP's kernel's configuration, you can use ``menuconfig``. |
171 | 171 | ||
172 | 5. *Rebuild the Kernel Image With Your Changes:* Rebuilding the kernel | 172 | #. *Rebuild the Kernel Image With Your Changes:* Rebuilding the kernel |
173 | image applies your changes. Depending on your target hardware, you | 173 | image applies your changes. Depending on your target hardware, you |
174 | can verify your changes on actual hardware or perhaps QEMU. | 174 | can verify your changes on actual hardware or perhaps QEMU. |
175 | 175 | ||
diff --git a/documentation/kernel-dev/maint-appx.rst b/documentation/kernel-dev/maint-appx.rst index 6aa2fb7cf1..53b7376089 100644 --- a/documentation/kernel-dev/maint-appx.rst +++ b/documentation/kernel-dev/maint-appx.rst | |||
@@ -92,11 +92,11 @@ top-level kernel feature or BSP. The following actions effectively | |||
92 | provide the Metadata and create the tree that includes the new feature, | 92 | provide the Metadata and create the tree that includes the new feature, |
93 | patch, or BSP: | 93 | patch, or BSP: |
94 | 94 | ||
95 | 1. *Pass Feature to the OpenEmbedded Build System:* A top-level kernel | 95 | #. *Pass Feature to the OpenEmbedded Build System:* A top-level kernel |
96 | feature is passed to the kernel build subsystem. Normally, this | 96 | feature is passed to the kernel build subsystem. Normally, this |
97 | feature is a BSP for a particular kernel type. | 97 | feature is a BSP for a particular kernel type. |
98 | 98 | ||
99 | 2. *Locate Feature:* The file that describes the top-level feature is | 99 | #. *Locate Feature:* The file that describes the top-level feature is |
100 | located by searching these system directories: | 100 | located by searching these system directories: |
101 | 101 | ||
102 | - The in-tree kernel-cache directories, which are located in the | 102 | - The in-tree kernel-cache directories, which are located in the |
@@ -112,31 +112,31 @@ patch, or BSP: | |||
112 | 112 | ||
113 | bsp_root_name-kernel_type.scc | 113 | bsp_root_name-kernel_type.scc |
114 | 114 | ||
115 | 3. *Expand Feature:* Once located, the feature description is either | 115 | #. *Expand Feature:* Once located, the feature description is either |
116 | expanded into a simple script of actions, or into an existing | 116 | expanded into a simple script of actions, or into an existing |
117 | equivalent script that is already part of the shipped kernel. | 117 | equivalent script that is already part of the shipped kernel. |
118 | 118 | ||
119 | 4. *Append Extra Features:* Extra features are appended to the top-level | 119 | #. *Append Extra Features:* Extra features are appended to the top-level |
120 | feature description. These features can come from the | 120 | feature description. These features can come from the |
121 | :term:`KERNEL_FEATURES` | 121 | :term:`KERNEL_FEATURES` |
122 | variable in recipes. | 122 | variable in recipes. |
123 | 123 | ||
124 | 5. *Locate, Expand, and Append Each Feature:* Each extra feature is | 124 | #. *Locate, Expand, and Append Each Feature:* Each extra feature is |
125 | located, expanded and appended to the script as described in step | 125 | located, expanded and appended to the script as described in step |
126 | three. | 126 | three. |
127 | 127 | ||
128 | 6. *Execute the Script:* The script is executed to produce files | 128 | #. *Execute the Script:* The script is executed to produce files |
129 | ``.scc`` and ``.cfg`` files in appropriate directories of the | 129 | ``.scc`` and ``.cfg`` files in appropriate directories of the |
130 | ``yocto-kernel-cache`` repository. These files are descriptions of | 130 | ``yocto-kernel-cache`` repository. These files are descriptions of |
131 | all the branches, tags, patches and configurations that need to be | 131 | all the branches, tags, patches and configurations that need to be |
132 | applied to the base Git repository to completely create the source | 132 | applied to the base Git repository to completely create the source |
133 | (build) branch for the new BSP or feature. | 133 | (build) branch for the new BSP or feature. |
134 | 134 | ||
135 | 7. *Clone Base Repository:* The base repository is cloned, and the | 135 | #. *Clone Base Repository:* The base repository is cloned, and the |
136 | actions listed in the ``yocto-kernel-cache`` directories are applied | 136 | actions listed in the ``yocto-kernel-cache`` directories are applied |
137 | to the tree. | 137 | to the tree. |
138 | 138 | ||
139 | 8. *Perform Cleanup:* The Git repositories are left with the desired | 139 | #. *Perform Cleanup:* The Git repositories are left with the desired |
140 | branches checked out and any required branching, patching and tagging | 140 | branches checked out and any required branching, patching and tagging |
141 | has been performed. | 141 | has been performed. |
142 | 142 | ||
diff --git a/documentation/migration-guides/migration-general.rst b/documentation/migration-guides/migration-general.rst index c350a4df97..c3b8a785db 100644 --- a/documentation/migration-guides/migration-general.rst +++ b/documentation/migration-guides/migration-general.rst | |||
@@ -81,11 +81,11 @@ any new Yocto Project release. | |||
81 | the migration (e.g. added/removed packages, added/removed files, size | 81 | the migration (e.g. added/removed packages, added/removed files, size |
82 | changes etc.). To do this, follow these steps: | 82 | changes etc.). To do this, follow these steps: |
83 | 83 | ||
84 | 1. Enable :ref:`buildhistory <ref-classes-buildhistory>` before the migration | 84 | #. Enable :ref:`buildhistory <ref-classes-buildhistory>` before the migration |
85 | 85 | ||
86 | 2. Run a pre-migration build | 86 | #. Run a pre-migration build |
87 | 87 | ||
88 | 3. Capture the :ref:`buildhistory <ref-classes-buildhistory>` output (as | 88 | #. Capture the :ref:`buildhistory <ref-classes-buildhistory>` output (as |
89 | specified by :term:`BUILDHISTORY_DIR`) and ensure it is preserved for | 89 | specified by :term:`BUILDHISTORY_DIR`) and ensure it is preserved for |
90 | subsequent builds. How you would do this depends on how you are running | 90 | subsequent builds. How you would do this depends on how you are running |
91 | your builds - if you are doing this all on one workstation in the same | 91 | your builds - if you are doing this all on one workstation in the same |
@@ -93,15 +93,15 @@ any new Yocto Project release. | |||
93 | deleting the :ref:`buildhistory <ref-classes-buildhistory>` output | 93 | deleting the :ref:`buildhistory <ref-classes-buildhistory>` output |
94 | directory. For builds in a pipeline it may be more complicated. | 94 | directory. For builds in a pipeline it may be more complicated. |
95 | 95 | ||
96 | 4. Set a tag in the :ref:`buildhistory <ref-classes-buildhistory>` output (which is a git repository) before | 96 | #. Set a tag in the :ref:`buildhistory <ref-classes-buildhistory>` output (which is a git repository) before |
97 | migration, to make the commit from the pre-migration build easy to find | 97 | migration, to make the commit from the pre-migration build easy to find |
98 | as you may end up running multiple builds during the migration. | 98 | as you may end up running multiple builds during the migration. |
99 | 99 | ||
100 | 5. Perform the migration | 100 | #. Perform the migration |
101 | 101 | ||
102 | 6. Run a build | 102 | #. Run a build |
103 | 103 | ||
104 | 7. Check the output changes between the previously set tag and HEAD in the | 104 | #. Check the output changes between the previously set tag and HEAD in the |
105 | :ref:`buildhistory <ref-classes-buildhistory>` output using ``git diff`` or ``buildhistory-diff``. | 105 | :ref:`buildhistory <ref-classes-buildhistory>` output using ``git diff`` or ``buildhistory-diff``. |
106 | 106 | ||
107 | For more information on using :ref:`buildhistory <ref-classes-buildhistory>`, see | 107 | For more information on using :ref:`buildhistory <ref-classes-buildhistory>`, see |
diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst index 600b46910e..4c847a09de 100644 --- a/documentation/overview-manual/yp-intro.rst +++ b/documentation/overview-manual/yp-intro.rst | |||
@@ -517,18 +517,18 @@ Historically, the Build Appliance was the second of three methods by | |||
517 | which you could use the Yocto Project on a system that was not native to | 517 | which you could use the Yocto Project on a system that was not native to |
518 | Linux. | 518 | Linux. |
519 | 519 | ||
520 | 1. *Hob:* Hob, which is now deprecated and is no longer available since | 520 | #. *Hob:* Hob, which is now deprecated and is no longer available since |
521 | the 2.1 release of the Yocto Project provided a rudimentary, | 521 | the 2.1 release of the Yocto Project provided a rudimentary, |
522 | GUI-based interface to the Yocto Project. Toaster has fully replaced | 522 | GUI-based interface to the Yocto Project. Toaster has fully replaced |
523 | Hob. | 523 | Hob. |
524 | 524 | ||
525 | 2. *Build Appliance:* Post Hob, the Build Appliance became available. It | 525 | #. *Build Appliance:* Post Hob, the Build Appliance became available. It |
526 | was never recommended that you use the Build Appliance as a | 526 | was never recommended that you use the Build Appliance as a |
527 | day-to-day production development environment with the Yocto Project. | 527 | day-to-day production development environment with the Yocto Project. |
528 | Build Appliance was useful as a way to try out development in the | 528 | Build Appliance was useful as a way to try out development in the |
529 | Yocto Project environment. | 529 | Yocto Project environment. |
530 | 530 | ||
531 | 3. *CROPS:* The final and best solution available now for developing | 531 | #. *CROPS:* The final and best solution available now for developing |
532 | using the Yocto Project on a system not native to Linux is with | 532 | using the Yocto Project on a system not native to Linux is with |
533 | :ref:`CROPS <overview-manual/yp-intro:development tools>`. | 533 | :ref:`CROPS <overview-manual/yp-intro:development tools>`. |
534 | 534 | ||
@@ -719,27 +719,27 @@ workflow: | |||
719 | 719 | ||
720 | Following is a brief summary of the "workflow": | 720 | Following is a brief summary of the "workflow": |
721 | 721 | ||
722 | 1. Developers specify architecture, policies, patches and configuration | 722 | #. Developers specify architecture, policies, patches and configuration |
723 | details. | 723 | details. |
724 | 724 | ||
725 | 2. The build system fetches and downloads the source code from the | 725 | #. The build system fetches and downloads the source code from the |
726 | specified location. The build system supports standard methods such | 726 | specified location. The build system supports standard methods such |
727 | as tarballs or source code repositories systems such as Git. | 727 | as tarballs or source code repositories systems such as Git. |
728 | 728 | ||
729 | 3. Once source code is downloaded, the build system extracts the sources | 729 | #. Once source code is downloaded, the build system extracts the sources |
730 | into a local work area where patches are applied and common steps for | 730 | into a local work area where patches are applied and common steps for |
731 | configuring and compiling the software are run. | 731 | configuring and compiling the software are run. |
732 | 732 | ||
733 | 4. The build system then installs the software into a temporary staging | 733 | #. The build system then installs the software into a temporary staging |
734 | area where the binary package format you select (DEB, RPM, or IPK) is | 734 | area where the binary package format you select (DEB, RPM, or IPK) is |
735 | used to roll up the software. | 735 | used to roll up the software. |
736 | 736 | ||
737 | 5. Different QA and sanity checks run throughout entire build process. | 737 | #. Different QA and sanity checks run throughout entire build process. |
738 | 738 | ||
739 | 6. After the binaries are created, the build system generates a binary | 739 | #. After the binaries are created, the build system generates a binary |
740 | package feed that is used to create the final root file image. | 740 | package feed that is used to create the final root file image. |
741 | 741 | ||
742 | 7. The build system generates the file system image and a customized | 742 | #. The build system generates the file system image and a customized |
743 | Extensible SDK (eSDK) for application development in parallel. | 743 | Extensible SDK (eSDK) for application development in parallel. |
744 | 744 | ||
745 | For a very detailed look at this workflow, see the | 745 | For a very detailed look at this workflow, see the |
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst index de5f108fb1..7f760c5ba4 100644 --- a/documentation/ref-manual/classes.rst +++ b/documentation/ref-manual/classes.rst | |||
@@ -979,11 +979,11 @@ by default (as specified by :term:`IMAGE_BUILDINFO_FILE`). | |||
979 | This can be useful for manually determining the origin of any given | 979 | This can be useful for manually determining the origin of any given |
980 | image. It writes out two sections: | 980 | image. It writes out two sections: |
981 | 981 | ||
982 | 1. `Build Configuration`: a list of variables and their values (specified | 982 | #. `Build Configuration`: a list of variables and their values (specified |
983 | by :term:`IMAGE_BUILDINFO_VARS`, which defaults to :term:`DISTRO` and | 983 | by :term:`IMAGE_BUILDINFO_VARS`, which defaults to :term:`DISTRO` and |
984 | :term:`DISTRO_VERSION`) | 984 | :term:`DISTRO_VERSION`) |
985 | 985 | ||
986 | 2. `Layer Revisions`: the revisions of all of the layers used in the | 986 | #. `Layer Revisions`: the revisions of all of the layers used in the |
987 | build. | 987 | build. |
988 | 988 | ||
989 | Additionally, when building an SDK it will write the same contents | 989 | Additionally, when building an SDK it will write the same contents |
diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst index 8dab359b69..3f27c03e44 100644 --- a/documentation/ref-manual/system-requirements.rst +++ b/documentation/ref-manual/system-requirements.rst | |||
@@ -235,7 +235,7 @@ The ``install-buildtools`` script is the easiest of the three methods by | |||
235 | which you can get these tools. It downloads a pre-built buildtools | 235 | which you can get these tools. It downloads a pre-built buildtools |
236 | installer and automatically installs the tools for you: | 236 | installer and automatically installs the tools for you: |
237 | 237 | ||
238 | 1. Execute the ``install-buildtools`` script. Here is an example:: | 238 | #. Execute the ``install-buildtools`` script. Here is an example:: |
239 | 239 | ||
240 | $ cd poky | 240 | $ cd poky |
241 | $ scripts/install-buildtools \ | 241 | $ scripts/install-buildtools \ |
@@ -268,7 +268,7 @@ installer and automatically installs the tools for you: | |||
268 | $ cd poky | 268 | $ cd poky |
269 | $ scripts/install-buildtools --make-only | 269 | $ scripts/install-buildtools --make-only |
270 | 270 | ||
271 | 2. Source the tools environment setup script by using a command like the | 271 | #. Source the tools environment setup script by using a command like the |
272 | following:: | 272 | following:: |
273 | 273 | ||
274 | $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux | 274 | $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux |
@@ -291,9 +291,9 @@ If you would prefer not to use the ``install-buildtools`` script, you can instea | |||
291 | download and run a pre-built buildtools installer yourself with the following | 291 | download and run a pre-built buildtools installer yourself with the following |
292 | steps: | 292 | steps: |
293 | 293 | ||
294 | 1. Locate and download the ``*.sh`` at :yocto_dl:`/releases/yocto/yocto-&DISTRO;/buildtools/` | 294 | #. Locate and download the ``*.sh`` at :yocto_dl:`/releases/yocto/yocto-&DISTRO;/buildtools/` |
295 | 295 | ||
296 | 2. Execute the installation script. Here is an example for the | 296 | #. Execute the installation script. Here is an example for the |
297 | traditional installer:: | 297 | traditional installer:: |
298 | 298 | ||
299 | $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh | 299 | $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh |
@@ -310,7 +310,7 @@ steps: | |||
310 | installation directory. For example, you could choose the following: | 310 | installation directory. For example, you could choose the following: |
311 | ``/home/your-username/buildtools`` | 311 | ``/home/your-username/buildtools`` |
312 | 312 | ||
313 | 3. Source the tools environment setup script by using a command like the | 313 | #. Source the tools environment setup script by using a command like the |
314 | following:: | 314 | following:: |
315 | 315 | ||
316 | $ source /home/your_username/buildtools/environment-setup-i586-poky-linux | 316 | $ source /home/your_username/buildtools/environment-setup-i586-poky-linux |
@@ -339,11 +339,11 @@ Python (or gcc) requirements. | |||
339 | Here are the steps to take to build and run your own buildtools | 339 | Here are the steps to take to build and run your own buildtools |
340 | installer: | 340 | installer: |
341 | 341 | ||
342 | 1. On the machine that is able to run BitBake, be sure you have set up | 342 | #. On the machine that is able to run BitBake, be sure you have set up |
343 | your build environment with the setup script | 343 | your build environment with the setup script |
344 | (:ref:`structure-core-script`). | 344 | (:ref:`structure-core-script`). |
345 | 345 | ||
346 | 2. Run the BitBake command to build the tarball:: | 346 | #. Run the BitBake command to build the tarball:: |
347 | 347 | ||
348 | $ bitbake buildtools-tarball | 348 | $ bitbake buildtools-tarball |
349 | 349 | ||
@@ -365,10 +365,10 @@ installer: | |||
365 | :term:`Build Directory`. The installer file has the string | 365 | :term:`Build Directory`. The installer file has the string |
366 | "buildtools" (or "buildtools-extended") in the name. | 366 | "buildtools" (or "buildtools-extended") in the name. |
367 | 367 | ||
368 | 3. Transfer the ``.sh`` file from the build host to the machine that | 368 | #. Transfer the ``.sh`` file from the build host to the machine that |
369 | does not meet the Git, tar, or Python (or gcc) requirements. | 369 | does not meet the Git, tar, or Python (or gcc) requirements. |
370 | 370 | ||
371 | 4. On the machine that does not meet the requirements, run the ``.sh`` | 371 | #. On the machine that does not meet the requirements, run the ``.sh`` |
372 | file to install the tools. Here is an example for the traditional | 372 | file to install the tools. Here is an example for the traditional |
373 | installer:: | 373 | installer:: |
374 | 374 | ||
@@ -386,7 +386,7 @@ installer: | |||
386 | installation directory. For example, you could choose the following: | 386 | installation directory. For example, you could choose the following: |
387 | ``/home/your_username/buildtools`` | 387 | ``/home/your_username/buildtools`` |
388 | 388 | ||
389 | 5. Source the tools environment setup script by using a command like the | 389 | #. Source the tools environment setup script by using a command like the |
390 | following:: | 390 | following:: |
391 | 391 | ||
392 | $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux | 392 | $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux |
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index 499a26f50b..8ed55ad7b3 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst | |||
@@ -5868,25 +5868,25 @@ system and gives an overview of their function and contents. | |||
5868 | omit any argument you like but must retain the separating commas. The | 5868 | omit any argument you like but must retain the separating commas. The |
5869 | order is important and specifies the following: | 5869 | order is important and specifies the following: |
5870 | 5870 | ||
5871 | 1. Extra arguments that should be added to the configure script | 5871 | #. Extra arguments that should be added to the configure script |
5872 | argument list (:term:`EXTRA_OECONF` or | 5872 | argument list (:term:`EXTRA_OECONF` or |
5873 | :term:`PACKAGECONFIG_CONFARGS`) if | 5873 | :term:`PACKAGECONFIG_CONFARGS`) if |
5874 | the feature is enabled. | 5874 | the feature is enabled. |
5875 | 5875 | ||
5876 | 2. Extra arguments that should be added to :term:`EXTRA_OECONF` or | 5876 | #. Extra arguments that should be added to :term:`EXTRA_OECONF` or |
5877 | :term:`PACKAGECONFIG_CONFARGS` if the feature is disabled. | 5877 | :term:`PACKAGECONFIG_CONFARGS` if the feature is disabled. |
5878 | 5878 | ||
5879 | 3. Additional build dependencies (:term:`DEPENDS`) | 5879 | #. Additional build dependencies (:term:`DEPENDS`) |
5880 | that should be added if the feature is enabled. | 5880 | that should be added if the feature is enabled. |
5881 | 5881 | ||
5882 | 4. Additional runtime dependencies (:term:`RDEPENDS`) | 5882 | #. Additional runtime dependencies (:term:`RDEPENDS`) |
5883 | that should be added if the feature is enabled. | 5883 | that should be added if the feature is enabled. |
5884 | 5884 | ||
5885 | 5. Additional runtime recommendations | 5885 | #. Additional runtime recommendations |
5886 | (:term:`RRECOMMENDS`) that should be added if | 5886 | (:term:`RRECOMMENDS`) that should be added if |
5887 | the feature is enabled. | 5887 | the feature is enabled. |
5888 | 5888 | ||
5889 | 6. Any conflicting (that is, mutually exclusive) :term:`PACKAGECONFIG` | 5889 | #. Any conflicting (that is, mutually exclusive) :term:`PACKAGECONFIG` |
5890 | settings for this feature. | 5890 | settings for this feature. |
5891 | 5891 | ||
5892 | Consider the following :term:`PACKAGECONFIG` block taken from the | 5892 | Consider the following :term:`PACKAGECONFIG` block taken from the |
diff --git a/documentation/sdk-manual/appendix-customizing.rst b/documentation/sdk-manual/appendix-customizing.rst index 45ad54fd76..c1a36c471d 100644 --- a/documentation/sdk-manual/appendix-customizing.rst +++ b/documentation/sdk-manual/appendix-customizing.rst | |||
@@ -173,12 +173,12 @@ perform additional steps. These steps make it possible for anyone using | |||
173 | the installed SDKs to update the installed SDKs by using the | 173 | the installed SDKs to update the installed SDKs by using the |
174 | ``devtool sdk-update`` command: | 174 | ``devtool sdk-update`` command: |
175 | 175 | ||
176 | 1. Create a directory that can be shared over HTTP or HTTPS. You can do | 176 | #. Create a directory that can be shared over HTTP or HTTPS. You can do |
177 | this by setting up a web server such as an :wikipedia:`Apache HTTP Server | 177 | this by setting up a web server such as an :wikipedia:`Apache HTTP Server |
178 | <Apache_HTTP_Server>` or :wikipedia:`Nginx <Nginx>` server in the cloud | 178 | <Apache_HTTP_Server>` or :wikipedia:`Nginx <Nginx>` server in the cloud |
179 | to host the directory. This directory must contain the published SDK. | 179 | to host the directory. This directory must contain the published SDK. |
180 | 180 | ||
181 | 2. Set the | 181 | #. Set the |
182 | :term:`SDK_UPDATE_URL` | 182 | :term:`SDK_UPDATE_URL` |
183 | variable to point to the corresponding HTTP or HTTPS URL. Setting | 183 | variable to point to the corresponding HTTP or HTTPS URL. Setting |
184 | this variable causes any SDK built to default to that URL and thus, | 184 | this variable causes any SDK built to default to that URL and thus, |
@@ -187,10 +187,10 @@ the installed SDKs to update the installed SDKs by using the | |||
187 | ":ref:`sdk-manual/extensible:applying updates to an installed extensible sdk`" | 187 | ":ref:`sdk-manual/extensible:applying updates to an installed extensible sdk`" |
188 | section. | 188 | section. |
189 | 189 | ||
190 | 3. Build the extensible SDK normally (i.e., use the | 190 | #. Build the extensible SDK normally (i.e., use the |
191 | ``bitbake -c populate_sdk_ext`` imagename command). | 191 | ``bitbake -c populate_sdk_ext`` imagename command). |
192 | 192 | ||
193 | 4. Publish the SDK using the following command:: | 193 | #. Publish the SDK using the following command:: |
194 | 194 | ||
195 | $ oe-publish-sdk some_path/sdk-installer.sh path_to_shared_http_directory | 195 | $ oe-publish-sdk some_path/sdk-installer.sh path_to_shared_http_directory |
196 | 196 | ||
@@ -245,7 +245,7 @@ If you want the users of an extensible SDK you build to be able to add | |||
245 | items to the SDK without requiring the users to build the items from | 245 | items to the SDK without requiring the users to build the items from |
246 | source, you need to do a number of things: | 246 | source, you need to do a number of things: |
247 | 247 | ||
248 | 1. Ensure the additional items you want the user to be able to install | 248 | #. Ensure the additional items you want the user to be able to install |
249 | are already built: | 249 | are already built: |
250 | 250 | ||
251 | - Build the items explicitly. You could use one or more "meta" | 251 | - Build the items explicitly. You could use one or more "meta" |
@@ -257,12 +257,12 @@ source, you need to do a number of things: | |||
257 | :term:`EXCLUDE_FROM_WORLD` | 257 | :term:`EXCLUDE_FROM_WORLD` |
258 | variable for additional information. | 258 | variable for additional information. |
259 | 259 | ||
260 | 2. Expose the ``sstate-cache`` directory produced by the build. | 260 | #. Expose the ``sstate-cache`` directory produced by the build. |
261 | Typically, you expose this directory by making it available through | 261 | Typically, you expose this directory by making it available through |
262 | an :wikipedia:`Apache HTTP Server <Apache_HTTP_Server>` or | 262 | an :wikipedia:`Apache HTTP Server <Apache_HTTP_Server>` or |
263 | :wikipedia:`Nginx <Nginx>` server. | 263 | :wikipedia:`Nginx <Nginx>` server. |
264 | 264 | ||
265 | 3. Set the appropriate configuration so that the produced SDK knows how | 265 | #. Set the appropriate configuration so that the produced SDK knows how |
266 | to find the configuration. The variable you need to set is | 266 | to find the configuration. The variable you need to set is |
267 | :term:`SSTATE_MIRRORS`:: | 267 | :term:`SSTATE_MIRRORS`:: |
268 | 268 | ||
diff --git a/documentation/sdk-manual/appendix-obtain.rst b/documentation/sdk-manual/appendix-obtain.rst index fa82af5c22..ba844507d3 100644 --- a/documentation/sdk-manual/appendix-obtain.rst +++ b/documentation/sdk-manual/appendix-obtain.rst | |||
@@ -28,14 +28,14 @@ and then run the script to hand-install the toolchain. | |||
28 | 28 | ||
29 | Follow these steps to locate and hand-install the toolchain: | 29 | Follow these steps to locate and hand-install the toolchain: |
30 | 30 | ||
31 | 1. *Go to the Installers Directory:* Go to | 31 | #. *Go to the Installers Directory:* Go to |
32 | :yocto_dl:`/releases/yocto/yocto-&DISTRO;/toolchain/` | 32 | :yocto_dl:`/releases/yocto/yocto-&DISTRO;/toolchain/` |
33 | 33 | ||
34 | 2. *Open the Folder for Your Build Host:* Open the folder that matches | 34 | #. *Open the Folder for Your Build Host:* Open the folder that matches |
35 | your :term:`Build Host` (i.e. | 35 | your :term:`Build Host` (i.e. |
36 | ``i686`` for 32-bit machines or ``x86_64`` for 64-bit machines). | 36 | ``i686`` for 32-bit machines or ``x86_64`` for 64-bit machines). |
37 | 37 | ||
38 | 3. *Locate and Download the SDK Installer:* You need to find and | 38 | #. *Locate and Download the SDK Installer:* You need to find and |
39 | download the installer appropriate for your build host, target | 39 | download the installer appropriate for your build host, target |
40 | hardware, and image type. | 40 | hardware, and image type. |
41 | 41 | ||
@@ -72,7 +72,7 @@ Follow these steps to locate and hand-install the toolchain: | |||
72 | 72 | ||
73 | poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh | 73 | poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh |
74 | 74 | ||
75 | 4. *Run the Installer:* Be sure you have execution privileges and run | 75 | #. *Run the Installer:* Be sure you have execution privileges and run |
76 | the installer. Following is an example from the ``Downloads`` | 76 | the installer. Following is an example from the ``Downloads`` |
77 | directory:: | 77 | directory:: |
78 | 78 | ||
@@ -91,13 +91,13 @@ Building an SDK Installer | |||
91 | As an alternative to locating and downloading an SDK installer, you can | 91 | As an alternative to locating and downloading an SDK installer, you can |
92 | build the SDK installer. Follow these steps: | 92 | build the SDK installer. Follow these steps: |
93 | 93 | ||
94 | 1. *Set Up the Build Environment:* Be sure you are set up to use BitBake | 94 | #. *Set Up the Build Environment:* Be sure you are set up to use BitBake |
95 | in a shell. See the ":ref:`dev-manual/start:preparing the build host`" section | 95 | in a shell. See the ":ref:`dev-manual/start:preparing the build host`" section |
96 | in the Yocto Project Development Tasks Manual for information on how | 96 | in the Yocto Project Development Tasks Manual for information on how |
97 | to get a build host ready that is either a native Linux machine or a | 97 | to get a build host ready that is either a native Linux machine or a |
98 | machine that uses CROPS. | 98 | machine that uses CROPS. |
99 | 99 | ||
100 | 2. *Clone the ``poky`` Repository:* You need to have a local copy of the | 100 | #. *Clone the ``poky`` Repository:* You need to have a local copy of the |
101 | Yocto Project :term:`Source Directory` | 101 | Yocto Project :term:`Source Directory` |
102 | (i.e. a local | 102 | (i.e. a local |
103 | ``poky`` repository). See the ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and | 103 | ``poky`` repository). See the ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and |
@@ -107,7 +107,7 @@ build the SDK installer. Follow these steps: | |||
107 | how to clone the ``poky`` repository and check out the appropriate | 107 | how to clone the ``poky`` repository and check out the appropriate |
108 | branch for your work. | 108 | branch for your work. |
109 | 109 | ||
110 | 3. *Initialize the Build Environment:* While in the root directory of | 110 | #. *Initialize the Build Environment:* While in the root directory of |
111 | the Source Directory (i.e. ``poky``), run the | 111 | the Source Directory (i.e. ``poky``), run the |
112 | :ref:`structure-core-script` environment | 112 | :ref:`structure-core-script` environment |
113 | setup script to define the OpenEmbedded build environment on your | 113 | setup script to define the OpenEmbedded build environment on your |
@@ -120,12 +120,12 @@ build the SDK installer. Follow these steps: | |||
120 | the script runs, your current working directory is set to the ``build`` | 120 | the script runs, your current working directory is set to the ``build`` |
121 | directory. | 121 | directory. |
122 | 122 | ||
123 | 4. *Make Sure You Are Building an Installer for the Correct Machine:* | 123 | #. *Make Sure You Are Building an Installer for the Correct Machine:* |
124 | Check to be sure that your :term:`MACHINE` variable in the ``local.conf`` | 124 | Check to be sure that your :term:`MACHINE` variable in the ``local.conf`` |
125 | file in your :term:`Build Directory` matches the architecture | 125 | file in your :term:`Build Directory` matches the architecture |
126 | for which you are building. | 126 | for which you are building. |
127 | 127 | ||
128 | 5. *Make Sure Your SDK Machine is Correctly Set:* If you are building a | 128 | #. *Make Sure Your SDK Machine is Correctly Set:* If you are building a |
129 | toolchain designed to run on an architecture that differs from your | 129 | toolchain designed to run on an architecture that differs from your |
130 | current development host machine (i.e. the build host), be sure that | 130 | current development host machine (i.e. the build host), be sure that |
131 | the :term:`SDKMACHINE` variable in the ``local.conf`` file in your | 131 | the :term:`SDKMACHINE` variable in the ``local.conf`` file in your |
@@ -145,7 +145,7 @@ build the SDK installer. Follow these steps: | |||
145 | different from the architecture of the build machine (``x86_64``). | 145 | different from the architecture of the build machine (``x86_64``). |
146 | 146 | ||
147 | 147 | ||
148 | 6. *Build the SDK Installer:* To build the SDK installer for a standard | 148 | #. *Build the SDK Installer:* To build the SDK installer for a standard |
149 | SDK and populate the SDK image, use the following command form. Be | 149 | SDK and populate the SDK image, use the following command form. Be |
150 | sure to replace ``image`` with an image (e.g. "core-image-sato"):: | 150 | sure to replace ``image`` with an image (e.g. "core-image-sato"):: |
151 | 151 | ||
@@ -175,7 +175,7 @@ build the SDK installer. Follow these steps: | |||
175 | static development libraries: TOOLCHAIN_TARGET_TASK:append = " | 175 | static development libraries: TOOLCHAIN_TARGET_TASK:append = " |
176 | libc-staticdev" | 176 | libc-staticdev" |
177 | 177 | ||
178 | 7. *Run the Installer:* You can now run the SDK installer from | 178 | #. *Run the Installer:* You can now run the SDK installer from |
179 | ``tmp/deploy/sdk`` in the :term:`Build Directory`. Following is an example:: | 179 | ``tmp/deploy/sdk`` in the :term:`Build Directory`. Following is an example:: |
180 | 180 | ||
181 | $ cd poky/build/tmp/deploy/sdk | 181 | $ cd poky/build/tmp/deploy/sdk |
@@ -203,7 +203,7 @@ separately extract a root filesystem: | |||
203 | 203 | ||
204 | Follow these steps to extract the root filesystem: | 204 | Follow these steps to extract the root filesystem: |
205 | 205 | ||
206 | 1. *Locate and Download the Tarball for the Pre-Built Root Filesystem | 206 | #. *Locate and Download the Tarball for the Pre-Built Root Filesystem |
207 | Image File:* You need to find and download the root filesystem image | 207 | Image File:* You need to find and download the root filesystem image |
208 | file that is appropriate for your target system. These files are kept | 208 | file that is appropriate for your target system. These files are kept |
209 | in machine-specific folders in the | 209 | in machine-specific folders in the |
@@ -241,7 +241,7 @@ Follow these steps to extract the root filesystem: | |||
241 | 241 | ||
242 | core-image-sato-sdk-beaglebone-yocto.tar.bz2 | 242 | core-image-sato-sdk-beaglebone-yocto.tar.bz2 |
243 | 243 | ||
244 | 2. *Initialize the Cross-Development Environment:* You must ``source`` | 244 | #. *Initialize the Cross-Development Environment:* You must ``source`` |
245 | the cross-development environment setup script to establish necessary | 245 | the cross-development environment setup script to establish necessary |
246 | environment variables. | 246 | environment variables. |
247 | 247 | ||
@@ -253,7 +253,7 @@ Follow these steps to extract the root filesystem: | |||
253 | 253 | ||
254 | $ source poky_sdk/environment-setup-core2-64-poky-linux | 254 | $ source poky_sdk/environment-setup-core2-64-poky-linux |
255 | 255 | ||
256 | 3. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk`` | 256 | #. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk`` |
257 | command and provide the root filesystem image. | 257 | command and provide the root filesystem image. |
258 | 258 | ||
259 | Following is an example command that extracts the root filesystem | 259 | Following is an example command that extracts the root filesystem |
diff --git a/documentation/sdk-manual/extensible.rst b/documentation/sdk-manual/extensible.rst index 7ab43e0a9d..e8a0a5b3ce 100644 --- a/documentation/sdk-manual/extensible.rst +++ b/documentation/sdk-manual/extensible.rst | |||
@@ -47,7 +47,7 @@ Two ways to install the Extensible SDK | |||
47 | Extensible SDK can be installed in two different ways, and both have | 47 | 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 | 1. *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 installer |
52 | archives, which can get very large. There is only one environment for the regular | 52 | archives, which can get very large. There is only one environment for the regular |
53 | Yocto build and the SDK and less code paths where things can go not according to plan. | 53 | Yocto build and the SDK and less code paths where things can go not according to plan. |
@@ -56,7 +56,7 @@ git fetch or layer management tooling. The SDK extensibility is better than in t | |||
56 | second option: just run ``bitbake`` again to add more things to the sysroot, or add layers | 56 | second option: just run ``bitbake`` again to add more things to the sysroot, or add layers |
57 | if even more things are required. | 57 | if even more things are required. |
58 | 58 | ||
59 | 2. *Setting up the Extensible SDK from a standalone installer*. This has the benefit of | 59 | #. *Setting up the Extensible SDK from a standalone installer*. This has the benefit of |
60 | having a single, self-contained archive that includes all the needed binary artifacts. | 60 | having a single, self-contained archive that includes all the needed binary artifacts. |
61 | So nothing needs to be rebuilt, and there is no need to provide a well-functioning | 61 | So nothing needs to be rebuilt, and there is no need to provide a well-functioning |
62 | binary artefact cache over the network for developers with underpowered laptops. | 62 | binary artefact cache over the network for developers with underpowered laptops. |
@@ -64,10 +64,10 @@ binary artefact cache over the network for developers with underpowered laptops. | |||
64 | Setting up the Extensible SDK environment directly in a Yocto build | 64 | Setting up the Extensible SDK environment directly in a Yocto build |
65 | ------------------------------------------------------------------- | 65 | ------------------------------------------------------------------- |
66 | 66 | ||
67 | 1. Set up all the needed layers and a Yocto :term:`Build Directory`, e.g. a regular Yocto | 67 | #. Set up all the needed layers and a Yocto :term:`Build Directory`, e.g. a regular Yocto |
68 | build where ``bitbake`` can be executed. | 68 | build where ``bitbake`` can be executed. |
69 | 69 | ||
70 | 2. Run: | 70 | #. Run: |
71 | $ bitbake meta-ide-support | 71 | $ bitbake meta-ide-support |
72 | $ bitbake -c populate_sysroot gtk+3 | 72 | $ bitbake -c populate_sysroot gtk+3 |
73 | (or any other target or native item that the application developer would need) | 73 | (or any other target or native item that the application developer would need) |
@@ -279,7 +279,7 @@ command: | |||
279 | .. image:: figures/sdk-devtool-add-flow.png | 279 | .. image:: figures/sdk-devtool-add-flow.png |
280 | :width: 100% | 280 | :width: 100% |
281 | 281 | ||
282 | 1. *Generating the New Recipe*: The top part of the flow shows three | 282 | #. *Generating the New Recipe*: The top part of the flow shows three |
283 | scenarios by which you could use ``devtool add`` to generate a recipe | 283 | scenarios by which you could use ``devtool add`` to generate a recipe |
284 | based on existing source code. | 284 | based on existing source code. |
285 | 285 | ||
@@ -352,7 +352,7 @@ command: | |||
352 | Aside from a recipe folder, the command also creates an associated | 352 | Aside from a recipe folder, the command also creates an associated |
353 | append folder and places an initial ``*.bbappend`` file within. | 353 | append folder and places an initial ``*.bbappend`` file within. |
354 | 354 | ||
355 | 2. *Edit the Recipe*: You can use ``devtool edit-recipe`` to open up the | 355 | #. *Edit the Recipe*: You can use ``devtool edit-recipe`` to open up the |
356 | editor as defined by the ``$EDITOR`` environment variable and modify | 356 | editor as defined by the ``$EDITOR`` environment variable and modify |
357 | the file:: | 357 | the file:: |
358 | 358 | ||
@@ -362,7 +362,7 @@ command: | |||
362 | can make modifications to the recipe that take effect when you build | 362 | can make modifications to the recipe that take effect when you build |
363 | it later. | 363 | it later. |
364 | 364 | ||
365 | 3. *Build the Recipe or Rebuild the Image*: The next step you take | 365 | #. *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. | 366 | depends on what you are going to do with the new code. |
367 | 367 | ||
368 | If you need to eventually move the build output to the target | 368 | If you need to eventually move the build output to the target |
@@ -378,7 +378,7 @@ command: | |||
378 | 378 | ||
379 | $ devtool build-image image | 379 | $ devtool build-image image |
380 | 380 | ||
381 | 4. *Deploy the Build Output*: When you use the ``devtool build`` command | 381 | #. *Deploy the Build Output*: When you use the ``devtool build`` command |
382 | to build out your recipe, you probably want to see if the resulting | 382 | to build out your recipe, you probably want to see if the resulting |
383 | build output works as expected on the target hardware. | 383 | build output works as expected on the target hardware. |
384 | 384 | ||
@@ -400,7 +400,7 @@ command: | |||
400 | ``devtool`` does not provide a specific command that allows you to | 400 | ``devtool`` does not provide a specific command that allows you to |
401 | deploy the image to actual hardware. | 401 | deploy the image to actual hardware. |
402 | 402 | ||
403 | 5. *Finish Your Work With the Recipe*: The ``devtool finish`` command | 403 | #. *Finish Your Work With the Recipe*: The ``devtool finish`` command |
404 | creates any patches corresponding to commits in the local Git | 404 | creates any patches corresponding to commits in the local Git |
405 | repository, moves the new recipe to a more permanent layer, and then | 405 | repository, moves the new recipe to a more permanent layer, and then |
406 | resets the recipe so that the recipe is built normally rather than | 406 | resets the recipe so that the recipe is built normally rather than |
@@ -446,7 +446,7 @@ command: | |||
446 | .. image:: figures/sdk-devtool-modify-flow.png | 446 | .. image:: figures/sdk-devtool-modify-flow.png |
447 | :width: 100% | 447 | :width: 100% |
448 | 448 | ||
449 | 1. *Preparing to Modify the Code*: The top part of the flow shows three | 449 | #. *Preparing to Modify the Code*: The top part of the flow shows three |
450 | scenarios by which you could use ``devtool modify`` to prepare to | 450 | scenarios by which you could use ``devtool modify`` to prepare to |
451 | work on source files. Each scenario assumes the following: | 451 | work on source files. Each scenario assumes the following: |
452 | 452 | ||
@@ -555,11 +555,11 @@ command: | |||
555 | append file for the recipe in the ``devtool`` workspace. The | 555 | append file for the recipe in the ``devtool`` workspace. The |
556 | recipe and the source code remain in their original locations. | 556 | recipe and the source code remain in their original locations. |
557 | 557 | ||
558 | 2. *Edit the Source*: Once you have used the ``devtool modify`` command, | 558 | #. *Edit the Source*: Once you have used the ``devtool modify`` command, |
559 | you are free to make changes to the source files. You can use any | 559 | you are free to make changes to the source files. You can use any |
560 | editor you like to make and save your source code modifications. | 560 | editor you like to make and save your source code modifications. |
561 | 561 | ||
562 | 3. *Build the Recipe or Rebuild the Image*: The next step you take | 562 | #. *Build the Recipe or Rebuild the Image*: The next step you take |
563 | depends on what you are going to do with the new code. | 563 | depends on what you are going to do with the new code. |
564 | 564 | ||
565 | If you need to eventually move the build output to the target | 565 | If you need to eventually move the build output to the target |
@@ -572,7 +572,7 @@ command: | |||
572 | (e.g. for testing purposes), you can use the ``devtool build-image`` | 572 | (e.g. for testing purposes), you can use the ``devtool build-image`` |
573 | command: $ devtool build-image image | 573 | command: $ devtool build-image image |
574 | 574 | ||
575 | 4. *Deploy the Build Output*: When you use the ``devtool build`` command | 575 | #. *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 | 576 | to build out your recipe, you probably want to see if the resulting |
577 | build output works as expected on target hardware. | 577 | build output works as expected on target hardware. |
578 | 578 | ||
@@ -597,7 +597,7 @@ command: | |||
597 | ``devtool`` does not provide a specific command to deploy the image | 597 | ``devtool`` does not provide a specific command to deploy the image |
598 | to actual hardware. | 598 | to actual hardware. |
599 | 599 | ||
600 | 5. *Finish Your Work With the Recipe*: The ``devtool finish`` command | 600 | #. *Finish Your Work With the Recipe*: The ``devtool finish`` command |
601 | creates any patches corresponding to commits in the local Git | 601 | creates any patches corresponding to commits in the local Git |
602 | repository, updates the recipe to point to them (or creates a | 602 | repository, updates the recipe to point to them (or creates a |
603 | ``.bbappend`` file to do so, depending on the specified destination | 603 | ``.bbappend`` file to do so, depending on the specified destination |
@@ -664,7 +664,7 @@ The following diagram shows the common development flow used with the | |||
664 | .. image:: figures/sdk-devtool-upgrade-flow.png | 664 | .. image:: figures/sdk-devtool-upgrade-flow.png |
665 | :width: 100% | 665 | :width: 100% |
666 | 666 | ||
667 | 1. *Initiate the Upgrade*: The top part of the flow shows the typical | 667 | #. *Initiate the Upgrade*: The top part of the flow shows the typical |
668 | scenario by which you use the ``devtool upgrade`` command. The | 668 | scenario by which you use the ``devtool upgrade`` command. The |
669 | following conditions exist: | 669 | following conditions exist: |
670 | 670 | ||
@@ -716,7 +716,7 @@ The following diagram shows the common development flow used with the | |||
716 | are incorporated into the build the next time you build the software | 716 | are incorporated into the build the next time you build the software |
717 | just as are other changes you might have made to the source. | 717 | just as are other changes you might have made to the source. |
718 | 718 | ||
719 | 2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen | 719 | #. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen |
720 | after upgrading the software to a new version. Conflicts occur | 720 | after upgrading the software to a new version. Conflicts occur |
721 | if your recipe specifies some patch files in :term:`SRC_URI` that | 721 | if your recipe specifies some patch files in :term:`SRC_URI` that |
722 | conflict with changes made in the new version of the software. For | 722 | conflict with changes made in the new version of the software. For |
@@ -727,7 +727,7 @@ The following diagram shows the common development flow used with the | |||
727 | conflicts created through use of a newer or different version of the | 727 | conflicts created through use of a newer or different version of the |
728 | software. | 728 | software. |
729 | 729 | ||
730 | 3. *Build the Recipe or Rebuild the Image*: The next step you take | 730 | #. *Build the Recipe or Rebuild the Image*: The next step you take |
731 | depends on what you are going to do with the new code. | 731 | depends on what you are going to do with the new code. |
732 | 732 | ||
733 | If you need to eventually move the build output to the target | 733 | If you need to eventually move the build output to the target |
@@ -742,7 +742,7 @@ The following diagram shows the common development flow used with the | |||
742 | 742 | ||
743 | $ devtool build-image image | 743 | $ devtool build-image image |
744 | 744 | ||
745 | 4. *Deploy the Build Output*: When you use the ``devtool build`` command | 745 | #. *Deploy the Build Output*: When you use the ``devtool build`` command |
746 | or ``bitbake`` to build your recipe, you probably want to see if the | 746 | or ``bitbake`` to build your recipe, you probably want to see if the |
747 | resulting build output works as expected on target hardware. | 747 | resulting build output works as expected on target hardware. |
748 | 748 | ||
@@ -764,7 +764,7 @@ The following diagram shows the common development flow used with the | |||
764 | ``devtool`` does not provide a specific command that allows you to do | 764 | ``devtool`` does not provide a specific command that allows you to do |
765 | this. | 765 | this. |
766 | 766 | ||
767 | 5. *Finish Your Work With the Recipe*: The ``devtool finish`` command | 767 | #. *Finish Your Work With the Recipe*: The ``devtool finish`` command |
768 | creates any patches corresponding to commits in the local Git | 768 | creates any patches corresponding to commits in the local Git |
769 | repository, moves the new recipe to a more permanent layer, and then | 769 | repository, moves the new recipe to a more permanent layer, and then |
770 | resets the recipe so that the recipe is built normally rather than | 770 | resets the recipe so that the recipe is built normally rather than |
@@ -1054,17 +1054,17 @@ Working With Recipes | |||
1054 | When building a recipe using the ``devtool build`` command, the typical | 1054 | When building a recipe using the ``devtool build`` command, the typical |
1055 | build progresses as follows: | 1055 | build progresses as follows: |
1056 | 1056 | ||
1057 | 1. Fetch the source | 1057 | #. Fetch the source |
1058 | 1058 | ||
1059 | 2. Unpack the source | 1059 | #. Unpack the source |
1060 | 1060 | ||
1061 | 3. Configure the source | 1061 | #. Configure the source |
1062 | 1062 | ||
1063 | 4. Compile the source | 1063 | #. Compile the source |
1064 | 1064 | ||
1065 | 5. Install the build output | 1065 | #. Install the build output |
1066 | 1066 | ||
1067 | 6. Package the installed output | 1067 | #. Package the installed output |
1068 | 1068 | ||
1069 | For recipes in the workspace, fetching and unpacking is disabled as the | 1069 | For recipes in the workspace, fetching and unpacking is disabled as the |
1070 | source tree has already been prepared and is persistent. Each of these | 1070 | source tree has already been prepared and is persistent. Each of these |
@@ -1322,15 +1322,15 @@ those customers need an SDK that has custom libraries. In such a case, | |||
1322 | you can produce a derivative SDK based on the currently installed SDK | 1322 | you can produce a derivative SDK based on the currently installed SDK |
1323 | fairly easily by following these steps: | 1323 | fairly easily by following these steps: |
1324 | 1324 | ||
1325 | 1. If necessary, install an extensible SDK that you want to use as a | 1325 | #. If necessary, install an extensible SDK that you want to use as a |
1326 | base for your derivative SDK. | 1326 | base for your derivative SDK. |
1327 | 1327 | ||
1328 | 2. Source the environment script for the SDK. | 1328 | #. Source the environment script for the SDK. |
1329 | 1329 | ||
1330 | 3. Add the extra libraries or other components you want by using the | 1330 | #. Add the extra libraries or other components you want by using the |
1331 | ``devtool add`` command. | 1331 | ``devtool add`` command. |
1332 | 1332 | ||
1333 | 4. Run the ``devtool build-sdk`` command. | 1333 | #. Run the ``devtool build-sdk`` command. |
1334 | 1334 | ||
1335 | The previous steps take the recipes added to the workspace and construct | 1335 | The previous steps take the recipes added to the workspace and construct |
1336 | a new SDK installer that contains those recipes and the resulting binary | 1336 | a new SDK installer that contains those recipes and the resulting binary |
diff --git a/documentation/sdk-manual/intro.rst b/documentation/sdk-manual/intro.rst index ce00538b2a..49aa921e70 100644 --- a/documentation/sdk-manual/intro.rst +++ b/documentation/sdk-manual/intro.rst | |||
@@ -164,11 +164,11 @@ image. | |||
164 | 164 | ||
165 | You just need to follow these general steps: | 165 | You just need to follow these general steps: |
166 | 166 | ||
167 | 1. *Install the SDK for your target hardware:* For information on how to | 167 | #. *Install the SDK for your target hardware:* For information on how to |
168 | install the SDK, see the ":ref:`sdk-manual/using:installing the sdk`" | 168 | install the SDK, see the ":ref:`sdk-manual/using:installing the sdk`" |
169 | section. | 169 | section. |
170 | 170 | ||
171 | 2. *Download or Build the Target Image:* The Yocto Project supports | 171 | #. *Download or Build the Target Image:* The Yocto Project supports |
172 | several target architectures and has many pre-built kernel images and | 172 | several target architectures and has many pre-built kernel images and |
173 | root filesystem images. | 173 | root filesystem images. |
174 | 174 | ||
@@ -195,7 +195,7 @@ You just need to follow these general steps: | |||
195 | ":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`" | 195 | ":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`" |
196 | section for information on how to do this extraction. | 196 | section for information on how to do this extraction. |
197 | 197 | ||
198 | 3. *Develop and Test your Application:* At this point, you have the | 198 | #. *Develop and Test your Application:* At this point, you have the |
199 | tools to develop your application. If you need to separately install | 199 | tools to develop your application. If you need to separately install |
200 | and use the QEMU emulator, you can go to `QEMU Home | 200 | and use the QEMU emulator, you can go to `QEMU Home |
201 | Page <https://wiki.qemu.org/Main_Page>`__ to download and learn about | 201 | Page <https://wiki.qemu.org/Main_Page>`__ to download and learn about |
diff --git a/documentation/sdk-manual/working-projects.rst b/documentation/sdk-manual/working-projects.rst index beec1dd09a..9a0db0099d 100644 --- a/documentation/sdk-manual/working-projects.rst +++ b/documentation/sdk-manual/working-projects.rst | |||
@@ -31,7 +31,7 @@ project: | |||
31 | GNOME Developer | 31 | GNOME Developer |
32 | site. | 32 | site. |
33 | 33 | ||
34 | 1. *Create a Working Directory and Populate It:* Create a clean | 34 | #. *Create a Working Directory and Populate It:* Create a clean |
35 | directory for your project and then make that directory your working | 35 | directory for your project and then make that directory your working |
36 | location:: | 36 | location:: |
37 | 37 | ||
@@ -74,7 +74,7 @@ project: | |||
74 | bin_PROGRAMS = hello | 74 | bin_PROGRAMS = hello |
75 | hello_SOURCES = hello.c | 75 | hello_SOURCES = hello.c |
76 | 76 | ||
77 | 2. *Source the Cross-Toolchain Environment Setup File:* As described | 77 | #. *Source the Cross-Toolchain Environment Setup File:* As described |
78 | earlier in the manual, installing the cross-toolchain creates a | 78 | earlier in the manual, installing the cross-toolchain creates a |
79 | cross-toolchain environment setup script in the directory that the | 79 | cross-toolchain environment setup script in the directory that the |
80 | SDK was installed. Before you can use the tools to develop your | 80 | SDK was installed. Before you can use the tools to develop your |
@@ -92,7 +92,7 @@ project: | |||
92 | 92 | ||
93 | $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux | 93 | $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux |
94 | 94 | ||
95 | 3. *Create the configure Script:* Use the ``autoreconf`` command to | 95 | #. *Create the configure Script:* Use the ``autoreconf`` command to |
96 | generate the ``configure`` script:: | 96 | generate the ``configure`` script:: |
97 | 97 | ||
98 | $ autoreconf | 98 | $ autoreconf |
@@ -108,7 +108,7 @@ project: | |||
108 | which ensures missing auxiliary files are copied to the build | 108 | which ensures missing auxiliary files are copied to the build |
109 | host. | 109 | host. |
110 | 110 | ||
111 | 4. *Cross-Compile the Project:* This command compiles the project using | 111 | #. *Cross-Compile the Project:* This command compiles the project using |
112 | the cross-compiler. The | 112 | the cross-compiler. The |
113 | :term:`CONFIGURE_FLAGS` | 113 | :term:`CONFIGURE_FLAGS` |
114 | environment variable provides the minimal arguments for GNU | 114 | environment variable provides the minimal arguments for GNU |
@@ -129,7 +129,7 @@ project: | |||
129 | 129 | ||
130 | $ ./configure --host=armv5te-poky-linux-gnueabi --with-libtool-sysroot=sysroot_dir | 130 | $ ./configure --host=armv5te-poky-linux-gnueabi --with-libtool-sysroot=sysroot_dir |
131 | 131 | ||
132 | 5. *Make and Install the Project:* These two commands generate and | 132 | #. *Make and Install the Project:* These two commands generate and |
133 | install the project into the destination directory:: | 133 | install the project into the destination directory:: |
134 | 134 | ||
135 | $ make | 135 | $ make |
@@ -149,7 +149,7 @@ project: | |||
149 | 149 | ||
150 | $ file ./tmp/usr/local/bin/hello | 150 | $ file ./tmp/usr/local/bin/hello |
151 | 151 | ||
152 | 6. *Execute Your Project:* To execute the project, you would need to run | 152 | #. *Execute Your Project:* To execute the project, you would need to run |
153 | it on your target hardware. If your target hardware happens to be | 153 | it on your target hardware. If your target hardware happens to be |
154 | your build host, you could run the project as follows:: | 154 | your build host, you could run the project as follows:: |
155 | 155 | ||
@@ -227,7 +227,7 @@ established through the script:: | |||
227 | To illustrate variable use, work through this simple "Hello World!" | 227 | To illustrate variable use, work through this simple "Hello World!" |
228 | example: | 228 | example: |
229 | 229 | ||
230 | 1. *Create a Working Directory and Populate It:* Create a clean | 230 | #. *Create a Working Directory and Populate It:* Create a clean |
231 | directory for your project and then make that directory your working | 231 | directory for your project and then make that directory your working |
232 | location:: | 232 | location:: |
233 | 233 | ||
@@ -266,7 +266,7 @@ example: | |||
266 | printf("\n"); | 266 | printf("\n"); |
267 | } | 267 | } |
268 | 268 | ||
269 | 2. *Source the Cross-Toolchain Environment Setup File:* As described | 269 | #. *Source the Cross-Toolchain Environment Setup File:* As described |
270 | earlier in the manual, installing the cross-toolchain creates a | 270 | earlier in the manual, installing the cross-toolchain creates a |
271 | cross-toolchain environment setup script in the directory that the | 271 | cross-toolchain environment setup script in the directory that the |
272 | SDK was installed. Before you can use the tools to develop your | 272 | SDK was installed. Before you can use the tools to develop your |
@@ -284,7 +284,7 @@ example: | |||
284 | 284 | ||
285 | $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux | 285 | $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux |
286 | 286 | ||
287 | 3. *Create the Makefile:* For this example, the Makefile contains | 287 | #. *Create the Makefile:* For this example, the Makefile contains |
288 | two lines that can be used to set the :term:`CC` variable. One line is | 288 | two lines that can be used to set the :term:`CC` variable. One line is |
289 | identical to the value that is set when you run the SDK environment | 289 | identical to the value that is set when you run the SDK environment |
290 | setup script, and the other line sets :term:`CC` to "gcc", the default | 290 | setup script, and the other line sets :term:`CC` to "gcc", the default |
@@ -302,7 +302,7 @@ example: | |||
302 | rm -rf *.o | 302 | rm -rf *.o |
303 | rm target_bin | 303 | rm target_bin |
304 | 304 | ||
305 | 4. *Make the Project:* Use the ``make`` command to create the binary | 305 | #. *Make the Project:* Use the ``make`` command to create the binary |
306 | output file. Because variables are commented out in the Makefile, the | 306 | output file. Because variables are commented out in the Makefile, the |
307 | value used for :term:`CC` is the value set when the SDK environment setup | 307 | value used for :term:`CC` is the value set when the SDK environment setup |
308 | file was run:: | 308 | file was run:: |
@@ -387,7 +387,7 @@ example: | |||
387 | use the SDK environment variables regardless of the values in the | 387 | use the SDK environment variables regardless of the values in the |
388 | Makefile. | 388 | Makefile. |
389 | 389 | ||
390 | 5. *Execute Your Project:* To execute the project (i.e. ``target_bin``), | 390 | #. *Execute Your Project:* To execute the project (i.e. ``target_bin``), |
391 | use the following command:: | 391 | use the following command:: |
392 | 392 | ||
393 | $ ./target_bin | 393 | $ ./target_bin |
diff --git a/documentation/toaster-manual/reference.rst b/documentation/toaster-manual/reference.rst index e014d2f090..755b895cee 100644 --- a/documentation/toaster-manual/reference.rst +++ b/documentation/toaster-manual/reference.rst | |||
@@ -188,17 +188,17 @@ The ``bldcontrol/management/commands/checksettings.py`` file controls | |||
188 | workflow configuration. Here is the process to | 188 | workflow configuration. Here is the process to |
189 | initially populate this database. | 189 | initially populate this database. |
190 | 190 | ||
191 | 1. The default project settings are set from | 191 | #. The default project settings are set from |
192 | ``orm/fixtures/settings.xml``. | 192 | ``orm/fixtures/settings.xml``. |
193 | 193 | ||
194 | 2. The default project distro and layers are added from | 194 | #. The default project distro and layers are added from |
195 | ``orm/fixtures/poky.xml`` if poky is installed. If poky is not | 195 | ``orm/fixtures/poky.xml`` if poky is installed. If poky is not |
196 | installed, they are added from ``orm/fixtures/oe-core.xml``. | 196 | installed, they are added from ``orm/fixtures/oe-core.xml``. |
197 | 197 | ||
198 | 3. If the ``orm/fixtures/custom.xml`` file exists, then its values are | 198 | #. If the ``orm/fixtures/custom.xml`` file exists, then its values are |
199 | added. | 199 | added. |
200 | 200 | ||
201 | 4. The layer index is then scanned and added to the database. | 201 | #. The layer index is then scanned and added to the database. |
202 | 202 | ||
203 | Once these steps complete, Toaster is set up and ready to use. | 203 | Once these steps complete, Toaster is set up and ready to use. |
204 | 204 | ||