diff options
author | Nicolas Dechesne <nicolas.dechesne@linaro.org> | 2020-11-20 09:52:41 +0100 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2020-12-03 12:04:20 +0000 |
commit | e59787249e90b017d970818643cb1bd1d08f28a7 (patch) | |
tree | a758c11747674523bdac4f6389b2982937ea09ac | |
parent | cf15351619327ffc932981e4c470cd2407590941 (diff) | |
download | poky-e59787249e90b017d970818643cb1bd1d08f28a7.tar.gz |
dev-manual: replace labels with references to section title
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
-rw-r--r-- | documentation/dev-manual/dev-manual-common-tasks.rst | 21 |
1 files changed, 11 insertions, 10 deletions
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst index 1640a884d3..23c2be4f44 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.rst +++ b/documentation/dev-manual/dev-manual-common-tasks.rst | |||
@@ -1364,7 +1364,7 @@ files. Fetching is controlled mainly through the | |||
1364 | :term:`SRC_URI` variable. Your recipe | 1364 | :term:`SRC_URI` variable. Your recipe |
1365 | must have a ``SRC_URI`` variable that points to where the source is | 1365 | must have a ``SRC_URI`` variable that points to where the source is |
1366 | located. For a graphical representation of source locations, see the | 1366 | located. For a graphical representation of source locations, see the |
1367 | ":ref:`sources-dev-environment`" section in | 1367 | ":ref:`overview-manual/overview-manual-concepts:sources`" section in |
1368 | the Yocto Project Overview and Concepts Manual. | 1368 | the Yocto Project Overview and Concepts Manual. |
1369 | 1369 | ||
1370 | The :ref:`ref-tasks-fetch` task uses | 1370 | The :ref:`ref-tasks-fetch` task uses |
@@ -3759,7 +3759,7 @@ build host running Linux. | |||
3759 | The build process creates an entire Linux distribution from source and | 3759 | The build process creates an entire Linux distribution from source and |
3760 | places it in your :term:`Build Directory` under | 3760 | places it in your :term:`Build Directory` under |
3761 | ``tmp/deploy/images``. For detailed information on the build process | 3761 | ``tmp/deploy/images``. For detailed information on the build process |
3762 | using BitBake, see the ":ref:`images-dev-environment`" section in the | 3762 | using BitBake, see the ":ref:`overview-manual/overview-manual-concepts:images`" section in the |
3763 | Yocto Project Overview and Concepts Manual. | 3763 | Yocto Project Overview and Concepts Manual. |
3764 | 3764 | ||
3765 | The following figure and list overviews the build process: | 3765 | The following figure and list overviews the build process: |
@@ -6663,7 +6663,7 @@ revision, respectively). The values are highly dependent on the policies | |||
6663 | and procedures of a given distribution and package feed. | 6663 | and procedures of a given distribution and package feed. |
6664 | 6664 | ||
6665 | Because the OpenEmbedded build system uses | 6665 | Because the OpenEmbedded build system uses |
6666 | ":ref:`signatures <overview-checksums>`", which are | 6666 | ":ref:`signatures <overview-manual/overview-manual-concepts:checksums (signatures)>`", which are |
6667 | unique to a given build, the build system knows when to rebuild | 6667 | unique to a given build, the build system knows when to rebuild |
6668 | packages. All the inputs into a given task are represented by a | 6668 | packages. All the inputs into a given task are represented by a |
6669 | signature, which can trigger a rebuild when different. Thus, the build | 6669 | signature, which can trigger a rebuild when different. Thus, the build |
@@ -6906,7 +6906,7 @@ multiple times if you have more than one set of modules to package. | |||
6906 | 6906 | ||
6907 | For more examples that show how to use ``do_split_packages``, see the | 6907 | For more examples that show how to use ``do_split_packages``, see the |
6908 | ``connman.inc`` file in the ``meta/recipes-connectivity/connman/`` | 6908 | ``connman.inc`` file in the ``meta/recipes-connectivity/connman/`` |
6909 | directory of the ``poky`` :ref:`source repository <yocto-project-repositories>`. You can | 6909 | directory of the ``poky`` :ref:`source repository <overview-manual/overview-manual-development-environment:yocto project source repositories>`. You can |
6910 | also find examples in ``meta/classes/kernel.bbclass``. | 6910 | also find examples in ``meta/classes/kernel.bbclass``. |
6911 | 6911 | ||
6912 | Following is a reference that shows ``do_split_packages`` mandatory and | 6912 | Following is a reference that shows ``do_split_packages`` mandatory and |
@@ -9661,7 +9661,7 @@ Invalidating Shared State to Force a Task to Run | |||
9661 | ------------------------------------------------ | 9661 | ------------------------------------------------ |
9662 | 9662 | ||
9663 | The OpenEmbedded build system uses | 9663 | The OpenEmbedded build system uses |
9664 | :ref:`checksums <overview-checksums>` and | 9664 | :ref:`checksums <overview-manual/overview-manual-concepts:checksums (signatures)>` and |
9665 | :ref:`overview-manual/overview-manual-concepts:shared state` cache to avoid unnecessarily | 9665 | :ref:`overview-manual/overview-manual-concepts:shared state` cache to avoid unnecessarily |
9666 | rebuilding tasks. Collectively, this scheme is known as "shared state | 9666 | rebuilding tasks. Collectively, this scheme is known as "shared state |
9667 | code". | 9667 | code". |
@@ -10662,7 +10662,8 @@ Yocto general mailing list or on the openembedded-devel mailing list. | |||
10662 | 10662 | ||
10663 | You can also push a change upstream and request a maintainer to pull the | 10663 | You can also push a change upstream and request a maintainer to pull the |
10664 | change into the component's upstream repository. You do this by pushing | 10664 | change into the component's upstream repository. You do this by pushing |
10665 | to a contribution repository that is upstream. See the ":ref:`gs-git-workflows-and-the-yocto-project`" | 10665 | to a contribution repository that is upstream. See the |
10666 | ":ref:`overview-manual/overview-manual-development-environment:git workflows and the yocto project`" | ||
10666 | section in the Yocto Project Overview and Concepts Manual for additional | 10667 | section in the Yocto Project Overview and Concepts Manual for additional |
10667 | concepts on working in the Yocto Project development environment. | 10668 | concepts on working in the Yocto Project development environment. |
10668 | 10669 | ||
@@ -10789,7 +10790,7 @@ Yocto Project Reference Manual. | |||
10789 | 10790 | ||
10790 | Here is the general procedure on how to submit a patch through email | 10791 | Here is the general procedure on how to submit a patch through email |
10791 | without using the scripts once the steps in | 10792 | without using the scripts once the steps in |
10792 | :ref:`preparing-changes-for-submissions` have been followed: | 10793 | :ref:`dev-manual/dev-manual-common-tasks:preparing changes for submission` have been followed: |
10793 | 10794 | ||
10794 | 1. *Format the Commit:* Format the commit into an email message. To | 10795 | 1. *Format the Commit:* Format the commit into an email message. To |
10795 | format commits, use the ``git format-patch`` command. When you | 10796 | format commits, use the ``git format-patch`` command. When you |
@@ -10880,7 +10881,7 @@ and ``send-pull-request`` scripts from openembedded-core to create and send a | |||
10880 | patch series with a link to the branch for review. | 10881 | patch series with a link to the branch for review. |
10881 | 10882 | ||
10882 | Follow this procedure to push a change to an upstream "contrib" Git | 10883 | Follow this procedure to push a change to an upstream "contrib" Git |
10883 | repository once the steps in :ref:`preparing-changes-for-submissions` have | 10884 | repository once the steps in :ref:`dev-manual/dev-manual-common-tasks:preparing changes for submission` have |
10884 | been followed: | 10885 | been followed: |
10885 | 10886 | ||
10886 | .. note:: | 10887 | .. note:: |
@@ -11055,8 +11056,8 @@ follows: | |||
11055 | a newer version of the software which includes an upstream fix for the | 11056 | a newer version of the software which includes an upstream fix for the |
11056 | issue or when the issue has been fixed on the master branch in a way | 11057 | issue or when the issue has been fixed on the master branch in a way |
11057 | that introduces backwards incompatible changes. In this case follow the | 11058 | that introduces backwards incompatible changes. In this case follow the |
11058 | steps in :ref:`preparing-changes-for-submissions` and | 11059 | steps in :ref:`dev-manual/dev-manual-common-tasks:preparing changes for submission` and |
11059 | :ref:`submitting-a-patch` but modify the subject header of your patch | 11060 | :ref:`dev-manual/dev-manual-common-tasks:using email to submit a patch` but modify the subject header of your patch |
11060 | email to include the name of the stable branch which you are | 11061 | email to include the name of the stable branch which you are |
11061 | targetting. This can be done using the ``--subject-prefix`` argument to | 11062 | targetting. This can be done using the ``--subject-prefix`` argument to |
11062 | ``git format-patch``, for example to submit a patch to the dunfell | 11063 | ``git format-patch``, for example to submit a patch to the dunfell |