* [PATCH 00/10] Simplify file names
@ 2020-12-03 21:38 Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 01/10] sphinx: rename top level document in each manual Nicolas Dechesne
` (9 more replies)
0 siblings, 10 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
In this series, I am proposing to simplify the filenames we use across
the whole documentation project. It wasn't so much of an issue up
until now, but with Sphinx we end using using filenames quite a bit,
in :doc: and :ref: references, so I am proposing simpler filenames.
The first patch is just about renaming each manual entry page
index.rst, to be consistent with most Sphinx uses I've seen.
In the second patch, I implemented something which was suggested on
the list by Robert. I had used relative links such as :doc:`../xxx`
when I made the initial conversion and I didn't realize I could have
use absolute paths instead. So I am doing that now.
Then it's one patch for each manual, where I rename all files to
shorten them. All files were <xxx-manual>/<xxx-manual-file.rst>, I
convert them all to <xxx-manual/file.rst>. That should make our
fingers and keyboards happier. In each patch the files are renamed,
and all references are fixed up throughout the doc tree.
The whole series is tested with:
$ git rebase -i origin/master --exec "make -C documentation clean html"
And I found no obvious error.
Nicolas Dechesne (10):
sphinx: rename top level document in each manual
sphinx: use absolute paths for :doc: references
test-manual: remove 'test-manual' from filenames
toaster-manual: remove 'toaster-manual' from filenames
dev-manual: remove 'dev-manual' from filenames
kernel-dev: remove 'kernel-dev' from filenames
profile-manual: remove 'profile-manual' from filenames
overview-manual: remove 'overview-manual' from filenames
sdk-manual: remove 'sdk' from filenames
ref-manual: remove 'ref' from filenames
.../{brief-yoctoprojectqs.rst => index.rst} | 28 +--
documentation/bsp-guide/bsp.rst | 56 ++---
.../bsp-guide/{bsp-guide.rst => index.rst} | 0
...nual-common-tasks.rst => common-tasks.rst} | 136 ++++++------
.../dev-manual/{dev-manual.rst => index.rst} | 8 +-
.../{dev-manual-intro.rst => intro.rst} | 6 +-
.../{dev-manual-qemu.rst => qemu.rst} | 4 +-
.../{dev-manual-start.rst => start.rst} | 56 ++---
documentation/index.rst | 20 +-
.../{kernel-dev-advanced.rst => advanced.rst} | 24 +--
.../{kernel-dev-common.rst => common.rst} | 82 +++----
...ev-concepts-appx.rst => concepts-appx.rst} | 20 +-
.../{kernel-dev-faq.rst => faq.rst} | 10 +-
.../kernel-dev/{kernel-dev.rst => index.rst} | 12 +-
.../{kernel-dev-intro.rst => intro.rst} | 26 +--
...rnel-dev-maint-appx.rst => maint-appx.rst} | 2 +-
...rview-manual-concepts.rst => concepts.rst} | 46 ++--
...onment.rst => development-environment.rst} | 34 +--
.../{overview-manual.rst => index.rst} | 8 +-
.../{overview-manual-intro.rst => intro.rst} | 12 +-
...rview-manual-yp-intro.rst => yp-intro.rst} | 42 ++--
.../{profile-manual-arch.rst => arch.rst} | 0
...ofile-manual-examples.rst => examples.rst} | 0
.../{profile-manual.rst => index.rst} | 8 +-
.../{profile-manual-intro.rst => intro.rst} | 0
.../{profile-manual-usage.rst => usage.rst} | 18 +-
.../{ref-classes.rst => classes.rst} | 56 ++---
...ol-reference.rst => devtool-reference.rst} | 14 +-
documentation/ref-manual/faq.rst | 12 +-
.../{ref-features.rst => features.rst} | 12 +-
.../ref-manual/{ref-images.rst => images.rst} | 4 +-
.../ref-manual/{ref-manual.rst => index.rst} | 26 +--
.../{ref-kickstart.rst => kickstart.rst} | 2 +-
documentation/ref-manual/migration-1.4.rst | 2 +-
documentation/ref-manual/migration-1.5.rst | 6 +-
documentation/ref-manual/migration-1.6.rst | 8 +-
documentation/ref-manual/migration-1.7.rst | 8 +-
documentation/ref-manual/migration-2.1.rst | 14 +-
documentation/ref-manual/migration-2.3.rst | 6 +-
documentation/ref-manual/migration-2.5.rst | 2 +-
documentation/ref-manual/migration-2.6.rst | 2 +-
.../{ref-qa-checks.rst => qa-checks.rst} | 0
...elease-process.rst => release-process.rst} | 10 +-
documentation/ref-manual/resources.rst | 22 +-
.../{ref-structure.rst => structure.rst} | 26 +--
...quirements.rst => system-requirements.rst} | 10 +-
.../ref-manual/{ref-tasks.rst => tasks.rst} | 56 ++---
.../ref-manual/{ref-terms.rst => terms.rst} | 30 ++-
.../{ref-variables.rst => variables.rst} | 202 +++++++++---------
.../{ref-varlocality.rst => varlocality.rst} | 0
....rst => appendix-customizing-standard.rst} | 0
...stomizing.rst => appendix-customizing.rst} | 2 +-
...ppendix-obtain.rst => appendix-obtain.rst} | 10 +-
.../{sdk-extensible.rst => extensible.rst} | 2 +-
.../sdk-manual/{sdk-manual.rst => index.rst} | 14 +-
.../sdk-manual/{sdk-intro.rst => intro.rst} | 2 +-
.../sdk-manual/{sdk-using.rst => using.rst} | 0
...king-projects.rst => working-projects.rst} | 2 +-
.../{test-manual.rst => index.rst} | 6 +-
.../{test-manual-intro.rst => intro.rst} | 10 +-
...nual-test-process.rst => test-process.rst} | 0
...builder.rst => understand-autobuilder.rst} | 12 +-
.../{toaster-manual.rst => index.rst} | 8 +-
.../{toaster-manual-intro.rst => intro.rst} | 2 +-
...ter-manual-reference.rst => reference.rst} | 12 +-
...al-setup-and-use.rst => setup-and-use.rst} | 10 +-
.../{toaster-manual-start.rst => start.rst} | 2 +-
.../transitioning-to-a-custom-environment.rst | 12 +-
documentation/what-i-wish-id-known.rst | 24 +--
69 files changed, 657 insertions(+), 661 deletions(-)
rename documentation/brief-yoctoprojectqs/{brief-yoctoprojectqs.rst => index.rst} (93%)
rename documentation/bsp-guide/{bsp-guide.rst => index.rst} (100%)
rename documentation/dev-manual/{dev-manual-common-tasks.rst => common-tasks.rst} (98%)
rename documentation/dev-manual/{dev-manual.rst => index.rst} (75%)
rename documentation/dev-manual/{dev-manual-intro.rst => intro.rst} (93%)
rename documentation/dev-manual/{dev-manual-qemu.rst => qemu.rst} (99%)
rename documentation/dev-manual/{dev-manual-start.rst => start.rst} (93%)
rename documentation/kernel-dev/{kernel-dev-advanced.rst => advanced.rst} (97%)
rename documentation/kernel-dev/{kernel-dev-common.rst => common.rst} (95%)
rename documentation/kernel-dev/{kernel-dev-concepts-appx.rst => concepts-appx.rst} (95%)
rename documentation/kernel-dev/{kernel-dev-faq.rst => faq.rst} (85%)
rename documentation/kernel-dev/{kernel-dev.rst => index.rst} (68%)
rename documentation/kernel-dev/{kernel-dev-intro.rst => intro.rst} (87%)
rename documentation/kernel-dev/{kernel-dev-maint-appx.rst => maint-appx.rst} (99%)
rename documentation/overview-manual/{overview-manual-concepts.rst => concepts.rst} (97%)
rename documentation/overview-manual/{overview-manual-development-environment.rst => development-environment.rst} (95%)
rename documentation/overview-manual/{overview-manual.rst => index.rst} (69%)
rename documentation/overview-manual/{overview-manual-intro.rst => intro.rst} (88%)
rename documentation/overview-manual/{overview-manual-yp-intro.rst => yp-intro.rst} (96%)
rename documentation/profile-manual/{profile-manual-arch.rst => arch.rst} (100%)
rename documentation/profile-manual/{profile-manual-examples.rst => examples.rst} (100%)
rename documentation/profile-manual/{profile-manual.rst => index.rst} (74%)
rename documentation/profile-manual/{profile-manual-intro.rst => intro.rst} (100%)
rename documentation/profile-manual/{profile-manual-usage.rst => usage.rst} (99%)
rename documentation/ref-manual/{ref-classes.rst => classes.rst} (97%)
rename documentation/ref-manual/{ref-devtool-reference.rst => devtool-reference.rst} (97%)
rename documentation/ref-manual/{ref-features.rst => features.rst} (96%)
rename documentation/ref-manual/{ref-images.rst => images.rst} (97%)
rename documentation/ref-manual/{ref-manual.rst => index.rst} (54%)
rename documentation/ref-manual/{ref-kickstart.rst => kickstart.rst} (98%)
rename documentation/ref-manual/{ref-qa-checks.rst => qa-checks.rst} (100%)
rename documentation/ref-manual/{ref-release-process.rst => release-process.rst} (94%)
rename documentation/ref-manual/{ref-structure.rst => structure.rst} (96%)
rename documentation/ref-manual/{ref-system-requirements.rst => system-requirements.rst} (96%)
rename documentation/ref-manual/{ref-tasks.rst => tasks.rst} (91%)
rename documentation/ref-manual/{ref-terms.rst => terms.rst} (93%)
rename documentation/ref-manual/{ref-variables.rst => variables.rst} (97%)
rename documentation/ref-manual/{ref-varlocality.rst => varlocality.rst} (100%)
rename documentation/sdk-manual/{sdk-appendix-customizing-standard.rst => appendix-customizing-standard.rst} (100%)
rename documentation/sdk-manual/{sdk-appendix-customizing.rst => appendix-customizing.rst} (99%)
rename documentation/sdk-manual/{sdk-appendix-obtain.rst => appendix-obtain.rst} (96%)
rename documentation/sdk-manual/{sdk-extensible.rst => extensible.rst} (99%)
rename documentation/sdk-manual/{sdk-manual.rst => index.rst} (72%)
rename documentation/sdk-manual/{sdk-intro.rst => intro.rst} (99%)
rename documentation/sdk-manual/{sdk-using.rst => using.rst} (100%)
rename documentation/sdk-manual/{sdk-working-projects.rst => working-projects.rst} (99%)
rename documentation/test-manual/{test-manual.rst => index.rst} (75%)
rename documentation/test-manual/{test-manual-intro.rst => intro.rst} (97%)
rename documentation/test-manual/{test-manual-test-process.rst => test-process.rst} (100%)
rename documentation/test-manual/{test-manual-understand-autobuilder.rst => understand-autobuilder.rst} (95%)
rename documentation/toaster-manual/{toaster-manual.rst => index.rst} (66%)
rename documentation/toaster-manual/{toaster-manual-intro.rst => intro.rst} (97%)
rename documentation/toaster-manual/{toaster-manual-reference.rst => reference.rst} (97%)
rename documentation/toaster-manual/{toaster-manual-setup-and-use.rst => setup-and-use.rst} (98%)
rename documentation/toaster-manual/{toaster-manual-start.rst => start.rst} (95%)
--
2.29.2
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 01/10] sphinx: rename top level document in each manual
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 02/10] sphinx: use absolute paths for :doc: references Nicolas Dechesne
` (8 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
It is more common to call the top level document index.rst. This is
what this patch is doing, along with all required references fixup.
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
.../{brief-yoctoprojectqs.rst => index.rst} | 4 ++--
.../bsp-guide/{bsp-guide.rst => index.rst} | 0
.../dev-manual/dev-manual-common-tasks.rst | 6 +++---
documentation/dev-manual/dev-manual-intro.rst | 6 +++---
documentation/dev-manual/dev-manual-start.rst | 2 +-
.../dev-manual/{dev-manual.rst => index.rst} | 0
documentation/index.rst | 20 +++++++++----------
.../kernel-dev/{kernel-dev.rst => index.rst} | 0
.../kernel-dev/kernel-dev-advanced.rst | 2 +-
.../kernel-dev/kernel-dev-common.rst | 2 +-
documentation/kernel-dev/kernel-dev-intro.rst | 4 ++--
.../{overview-manual.rst => index.rst} | 0
.../overview-manual-concepts.rst | 6 +++---
...verview-manual-development-environment.rst | 6 +++---
.../overview-manual/overview-manual-intro.rst | 10 +++++-----
.../overview-manual-yp-intro.rst | 10 +++++-----
.../{profile-manual.rst => index.rst} | 0
documentation/ref-manual/faq.rst | 2 +-
.../ref-manual/{ref-manual.rst => index.rst} | 0
documentation/ref-manual/migration-2.1.rst | 2 +-
documentation/ref-manual/ref-features.rst | 4 ++--
documentation/ref-manual/ref-structure.rst | 2 +-
.../ref-manual/ref-system-requirements.rst | 6 +++---
documentation/ref-manual/ref-terms.rst | 12 ++++-------
documentation/ref-manual/ref-variables.rst | 4 ++--
documentation/ref-manual/resources.rst | 16 +++++++--------
.../sdk-manual/{sdk-manual.rst => index.rst} | 0
.../{test-manual.rst => index.rst} | 0
.../{toaster-manual.rst => index.rst} | 0
.../transitioning-to-a-custom-environment.rst | 2 +-
documentation/what-i-wish-id-known.rst | 14 ++++++-------
31 files changed, 69 insertions(+), 73 deletions(-)
rename documentation/brief-yoctoprojectqs/{brief-yoctoprojectqs.rst => index.rst} (99%)
rename documentation/bsp-guide/{bsp-guide.rst => index.rst} (100%)
rename documentation/dev-manual/{dev-manual.rst => index.rst} (100%)
rename documentation/kernel-dev/{kernel-dev.rst => index.rst} (100%)
rename documentation/overview-manual/{overview-manual.rst => index.rst} (100%)
rename documentation/profile-manual/{profile-manual.rst => index.rst} (100%)
rename documentation/ref-manual/{ref-manual.rst => index.rst} (100%)
rename documentation/sdk-manual/{sdk-manual.rst => index.rst} (100%)
rename documentation/test-manual/{test-manual.rst => index.rst} (100%)
rename documentation/toaster-manual/{toaster-manual.rst => index.rst} (100%)
diff --git a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst b/documentation/brief-yoctoprojectqs/index.rst
similarity index 99%
rename from documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
rename to documentation/brief-yoctoprojectqs/index.rst
index 8772812eb..e8912f07c 100644
--- a/documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.rst
+++ b/documentation/brief-yoctoprojectqs/index.rst
@@ -39,7 +39,7 @@ build a reference embedded OS called Poky.
Tasks Manual for more information.
If you want more conceptual or background information on the Yocto
-Project, see the :doc:`../overview-manual/overview-manual`.
+Project, see the :doc:`../overview-manual/index`.
Compatible Linux Distribution
=============================
@@ -404,7 +404,7 @@ information including the website, wiki pages, and user manuals:
concepts are useful for the beginner.
- **Yocto Project Overview and Concepts Manual:** The
- :doc:`../overview-manual/overview-manual` is a great
+ :doc:`../overview-manual/index` is a great
place to start to learn about the Yocto Project. This manual
introduces you to the Yocto Project and its development environment.
The manual also provides conceptual information for various aspects
diff --git a/documentation/bsp-guide/bsp-guide.rst b/documentation/bsp-guide/index.rst
similarity index 100%
rename from documentation/bsp-guide/bsp-guide.rst
rename to documentation/bsp-guide/index.rst
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
index 891fd9b00..e22bcd50e 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -3644,7 +3644,7 @@ build host running Linux.
- For information on how to build an image using
:term:`Toaster`, see the
- :doc:`../toaster-manual/toaster-manual`.
+ :doc:`../toaster-manual/index`.
- For information on how to use ``devtool`` to build images, see the
":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
@@ -3653,7 +3653,7 @@ build host running Linux.
- For a quick example on how to build an image using the
OpenEmbedded build system, see the
- :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+ :doc:`../brief-yoctoprojectqs/index` document.
The build process creates an entire Linux distribution from source and
places it in your :term:`Build Directory` under
@@ -3728,7 +3728,7 @@ The following figure and list overviews the build process:
kernels built by the OpenEmbedded build system are placed in the
Build Directory in ``tmp/deploy/images``. For information on how to
run pre-built images such as ``qemux86`` and ``qemuarm``, see the
- :doc:`../sdk-manual/sdk-manual` manual. For
+ :doc:`../sdk-manual/index` manual. For
information about how to install these images, see the documentation
for your particular board or machine.
diff --git a/documentation/dev-manual/dev-manual-intro.rst b/documentation/dev-manual/dev-manual-intro.rst
index 9bbac9610..94c481b7d 100644
--- a/documentation/dev-manual/dev-manual-intro.rst
+++ b/documentation/dev-manual/dev-manual-intro.rst
@@ -31,13 +31,13 @@ This manual provides the following:
This manual does not provide the following:
- Redundant Step-by-step Instructions: For example, the
- :doc:`../sdk-manual/sdk-manual` manual contains detailed
+ :doc:`../sdk-manual/index` manual contains detailed
instructions on how to install an SDK, which is used to develop
applications for target hardware.
- Reference or Conceptual Material: This type of material resides in an
appropriate reference manual. For example, system variables are
- documented in the :doc:`../ref-manual/ref-manual`.
+ documented in the :doc:`../ref-manual/index`.
- Detailed Public Information Not Specific to the Yocto Project: For
example, exhaustive information on how to use the Source Control
@@ -52,7 +52,7 @@ supplemental information is recommended for full comprehension. For
introductory information on the Yocto Project, see the
:yocto_home:`Yocto Project Website <>`. If you want to build an image with no
knowledge of Yocto Project as a way of quickly testing it out, see the
-:doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+:doc:`../brief-yoctoprojectqs/index` document.
For a comprehensive list of links and other documentation, see the
":ref:`ref-manual/resources:links and related documentation`"
diff --git a/documentation/dev-manual/dev-manual-start.rst b/documentation/dev-manual/dev-manual-start.rst
index 1c2314c43..053f09cdc 100644
--- a/documentation/dev-manual/dev-manual-start.rst
+++ b/documentation/dev-manual/dev-manual-start.rst
@@ -344,7 +344,7 @@ going to use BitBake, see the
section. If you are going
to use the Extensible SDK, see the ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
-Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`../kernel-dev/kernel-dev`. If you are going to use
+Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`../kernel-dev/index`. If you are going to use
Toaster, see the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
section in the Toaster User Manual.
diff --git a/documentation/dev-manual/dev-manual.rst b/documentation/dev-manual/index.rst
similarity index 100%
rename from documentation/dev-manual/dev-manual.rst
rename to documentation/dev-manual/index.rst
diff --git a/documentation/index.rst b/documentation/index.rst
index 2891a9862..9f41daf4b 100644
--- a/documentation/index.rst
+++ b/documentation/index.rst
@@ -14,7 +14,7 @@ Welcome to the Yocto Project Documentation
:maxdepth: 1
:caption: Introduction and Overview
- Quick Build <brief-yoctoprojectqs/brief-yoctoprojectqs>
+ Quick Build <brief-yoctoprojectqs/index>
what-i-wish-id-known
transitioning-to-a-custom-environment
Yocto Project Software Overview <https://www.yoctoproject.org/software-overview/>
@@ -25,15 +25,15 @@ Welcome to the Yocto Project Documentation
:maxdepth: 1
:caption: Manuals
- Overview and Concepts Manual <overview-manual/overview-manual>
- Reference Manual <ref-manual/ref-manual>
- Board Support Package (BSP) Developer's guide <bsp-guide/bsp-guide>
- Development Tasks Manual <dev-manual/dev-manual>
- Linux Kernel Development Manual <kernel-dev/kernel-dev>
- Profile and Tracing Manual <profile-manual/profile-manual>
- Application Development and the Extensible SDK (eSDK) <sdk-manual/sdk-manual>
- Toaster Manual <toaster-manual/toaster-manual>
- Test Environment Manual <test-manual/test-manual>
+ Overview and Concepts Manual <overview-manual/index>
+ Reference Manual <ref-manual/index>
+ Board Support Package (BSP) Developer's guide <bsp-guide/index>
+ Development Tasks Manual <dev-manual/index>
+ Linux Kernel Development Manual <kernel-dev/index>
+ Profile and Tracing Manual <profile-manual/index>
+ Application Development and the Extensible SDK (eSDK) <sdk-manual/index>
+ Toaster Manual <toaster-manual/index>
+ Test Environment Manual <test-manual/index>
Bitbake User Manual <https://docs.yoctoproject.org/bitbake>
.. toctree::
diff --git a/documentation/kernel-dev/kernel-dev.rst b/documentation/kernel-dev/index.rst
similarity index 100%
rename from documentation/kernel-dev/kernel-dev.rst
rename to documentation/kernel-dev/index.rst
diff --git a/documentation/kernel-dev/kernel-dev-advanced.rst b/documentation/kernel-dev/kernel-dev-advanced.rst
index db0a1eb2e..cc4834325 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.rst
+++ b/documentation/kernel-dev/kernel-dev-advanced.rst
@@ -474,7 +474,7 @@ supported kernel type.
This section overviews the BSP description structure, the aggregation
concepts, and presents a detailed example using a BSP supported by the
Yocto Project (i.e. BeagleBone Board). For complete information on BSP
-layer file hierarchy, see the :doc:`../bsp-guide/bsp-guide`.
+layer file hierarchy, see the :doc:`../bsp-guide/index`.
Description Overview
~~~~~~~~~~~~~~~~~~~~
diff --git a/documentation/kernel-dev/kernel-dev-common.rst b/documentation/kernel-dev/kernel-dev-common.rst
index 5115f65f4..c57025c67 100644
--- a/documentation/kernel-dev/kernel-dev-common.rst
+++ b/documentation/kernel-dev/kernel-dev-common.rst
@@ -502,7 +502,7 @@ your layer in the following area:
.. note::
If you are working on a new machine Board Support Package (BSP), be
- sure to refer to the :doc:`../bsp-guide/bsp-guide`.
+ sure to refer to the :doc:`../bsp-guide/index`.
As an example, consider the following append file used by the BSPs in
``meta-yocto-bsp``:
diff --git a/documentation/kernel-dev/kernel-dev-intro.rst b/documentation/kernel-dev/kernel-dev-intro.rst
index 309c65b4d..a2961d864 100644
--- a/documentation/kernel-dev/kernel-dev-intro.rst
+++ b/documentation/kernel-dev/kernel-dev-intro.rst
@@ -79,9 +79,9 @@ facilitate the process of working with the kernel recipes. If you find
you need some additional background, please be sure to review and
understand the following documentation:
-- :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+- :doc:`../brief-yoctoprojectqs/index` document.
-- :doc:`../overview-manual/overview-manual`.
+- :doc:`../overview-manual/index`.
- :ref:`devtool
workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
diff --git a/documentation/overview-manual/overview-manual.rst b/documentation/overview-manual/index.rst
similarity index 100%
rename from documentation/overview-manual/overview-manual.rst
rename to documentation/overview-manual/index.rst
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst
index 1b522910d..d79dacbfb 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/overview-manual-concepts.rst
@@ -481,7 +481,7 @@ The BSP Layer provides machine configurations that target specific
hardware. Everything in this layer is specific to the machine for which
you are building the image or the SDK. A common structure or form is
defined for BSP layers. You can learn more about this structure in the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`../bsp-guide/index`.
.. note::
@@ -1366,7 +1366,7 @@ can initialize the environment before using the tools.
section.
- For information on setting up a cross-development environment, see
- the :doc:`../sdk-manual/sdk-manual` manual.
+ the :doc:`../sdk-manual/index` manual.
All the output files for an SDK are written to the ``deploy/sdk`` folder
inside the :term:`Build Directory` as
@@ -1446,7 +1446,7 @@ The Yocto Project does most of the work for you when it comes to
creating :ref:`sdk-manual/sdk-intro:the cross-development toolchain`. This
section provides some technical background on how cross-development
toolchains are created and used. For more information on toolchains, you
-can also see the :doc:`../sdk-manual/sdk-manual` manual.
+can also see the :doc:`../sdk-manual/index` manual.
In the Yocto Project development environment, cross-development
toolchains are used to build images and applications that run on the
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index 5baf08946..36a246213 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -103,7 +103,7 @@ methods exist for you to do work in the Yocto Project environment:
hardware. To development BSPs, you need to take some additional steps
beyond what was described in setting up a development host.
- The :doc:`../bsp-guide/bsp-guide` provides BSP-related development
+ The :doc:`../bsp-guide/index` provides BSP-related development
information. For specifics on development host preparation, see the
":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`"
section in the Yocto Project Board Support Package (BSP) Developer's
@@ -114,7 +114,7 @@ methods exist for you to do work in the Yocto Project environment:
using ``devtool`` makes kernel development quicker by reducing
iteration cycle times.
- The :doc:`../kernel-dev/kernel-dev` provides kernel-related
+ The :doc:`../kernel-dev/index` provides kernel-related
development information. For specifics on development host
preparation, see the
":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
@@ -130,7 +130,7 @@ methods exist for you to do work in the Yocto Project environment:
For steps that show you how to set up your development host to use
Toaster and on how to use Toaster in general, see the
- :doc:`../toaster-manual/toaster-manual`.
+ :doc:`../toaster-manual/index`.
Yocto Project Source Repositories
=================================
diff --git a/documentation/overview-manual/overview-manual-intro.rst b/documentation/overview-manual/overview-manual-intro.rst
index f69824da9..c6fb53ca2 100644
--- a/documentation/overview-manual/overview-manual-intro.rst
+++ b/documentation/overview-manual/overview-manual-intro.rst
@@ -37,17 +37,17 @@ This manual does not give you the following:
- *Step-by-step Instructions for Development Tasks:* Instructional
procedures reside in other manuals within the Yocto Project
- documentation set. For example, the :doc:`../dev-manual/dev-manual`
+ documentation set. For example, the :doc:`../dev-manual/index`
provides examples on how to perform
various development tasks. As another example, the
- :doc:`../sdk-manual/sdk-manual` manual contains detailed
+ :doc:`../sdk-manual/index` manual contains detailed
instructions on how to install an SDK, which is used to develop
applications for target hardware.
- *Reference Material:* This type of material resides in an appropriate
reference manual. For example, system variables are documented in the
- :doc:`../ref-manual/ref-manual`. As another
- example, the :doc:`../bsp-guide/bsp-guide` contains reference information on
+ :doc:`../ref-manual/index`. As another
+ example, the :doc:`../bsp-guide/index` contains reference information on
BSPs.
- *Detailed Public Information Not Specific to the Yocto Project:* For
@@ -63,7 +63,7 @@ supplemental information is recommended for full comprehension. For
additional introductory information on the Yocto Project, see the
:yocto_home:`Yocto Project Website <>`. If you want to build an image
with no knowledge of Yocto Project as a way of quickly testing it out,
-see the :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document.
+see the :doc:`../brief-yoctoprojectqs/index` document.
For a comprehensive list of links and other documentation, see the
":ref:`Links and Related
Documentation <resources-links-and-related-documentation>`"
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index 2b9ea9149..bf12a673b 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -251,7 +251,7 @@ accomplish this through a recipe that is a BitBake append
.. note::
For general information on BSP layer structure, see the
- :doc:`../bsp-guide/bsp-guide`
+ :doc:`../bsp-guide/index`
.
The :term:`Source Directory`
@@ -339,12 +339,12 @@ applications using the Yocto Project:
experience supplemented with the powerful set of ``devtool`` commands
tailored for the Yocto Project environment.
- For information on the eSDK, see the :doc:`../sdk-manual/sdk-manual` Manual.
+ For information on the eSDK, see the :doc:`../sdk-manual/index` Manual.
- *Toaster:* Toaster is a web interface to the Yocto Project
OpenEmbedded build system. Toaster allows you to configure, run, and
view information about builds. For information on Toaster, see the
- :doc:`../toaster-manual/toaster-manual`.
+ :doc:`../toaster-manual/index`.
Production Tools
----------------
@@ -650,7 +650,7 @@ Project.
configure and start builds on multiple remote build servers.
For information about and how to use Toaster, see the
- :doc:`../toaster-manual/toaster-manual`.
+ :doc:`../toaster-manual/index`.
Reference Embedded Distribution (Poky)
======================================
@@ -812,7 +812,7 @@ helpful for getting started:
application developers. This eSDK allows developers to incorporate
their library and programming changes back into the image to make
their code available to other application developers. For information
- on the eSDK, see the :doc:`../sdk-manual/sdk-manual` manual.
+ on the eSDK, see the :doc:`../sdk-manual/index` manual.
- *Layer:* A collection of related recipes. Layers allow you to
consolidate related metadata to customize your build. Layers also
diff --git a/documentation/profile-manual/profile-manual.rst b/documentation/profile-manual/index.rst
similarity index 100%
rename from documentation/profile-manual/profile-manual.rst
rename to documentation/profile-manual/index.rst
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index 3ffc1f2c4..747561e06 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -47,7 +47,7 @@ Support Package (BSP) layer for it. For more information on how to
create a BSP layer, see the
":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual and the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`../bsp-guide/index`.
Usually, if the board is not completely exotic, adding support in the
Yocto Project is fairly straightforward.
diff --git a/documentation/ref-manual/ref-manual.rst b/documentation/ref-manual/index.rst
similarity index 100%
rename from documentation/ref-manual/ref-manual.rst
rename to documentation/ref-manual/index.rst
diff --git a/documentation/ref-manual/migration-2.1.rst b/documentation/ref-manual/migration-2.1.rst
index 0220221e0..8ea1aa7f0 100644
--- a/documentation/ref-manual/migration-2.1.rst
+++ b/documentation/ref-manual/migration-2.1.rst
@@ -234,7 +234,7 @@ functionality almost completely overlapped with the :ref:`standard
SDK <sdk-manual/sdk-using:using the standard sdk>` and the
:ref:`extensible SDK <sdk-manual/sdk-extensible:using the extensible sdk>`. For
information on these SDKs and how to build and use them, see the
-:doc:`../sdk-manual/sdk-manual` manual.
+:doc:`../sdk-manual/index` manual.
.. note::
diff --git a/documentation/ref-manual/ref-features.rst b/documentation/ref-manual/ref-features.rst
index a16460e91..c9223e413 100644
--- a/documentation/ref-manual/ref-features.rst
+++ b/documentation/ref-manual/ref-features.rst
@@ -261,7 +261,7 @@ these valid features is as follows:
- *perf:* Installs profiling tools such as ``perf``, ``systemtap``, and
``LTTng``. For general information on user-space tools, see the
- :doc:`../sdk-manual/sdk-manual` manual.
+ :doc:`../sdk-manual/index` manual.
- *ssh-server-dropbear:* Installs the Dropbear minimal SSH server.
@@ -275,7 +275,7 @@ these valid features is as follows:
``gdb``. For information on GDB, see the
":ref:`dev-manual/dev-manual-common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
in the Yocto Project Development Tasks Manual. For information on
- tracing and profiling, see the :doc:`../profile-manual/profile-manual`.
+ tracing and profiling, see the :doc:`../profile-manual/index`.
- *tools-sdk:* Installs a full SDK that runs on the device.
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index 5d17f0e5c..a172a0b71 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -104,7 +104,7 @@ metadata to define the Poky reference distribution.
This directory contains the Yocto Project reference hardware Board
Support Packages (BSPs). For more information on BSPs, see the
-:doc:`../bsp-guide/bsp-guide`.
+:doc:`../bsp-guide/index`.
.. _structure-meta-selftest:
diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/ref-system-requirements.rst
index af8663a5b..937cd0c70 100644
--- a/documentation/ref-manual/ref-system-requirements.rst
+++ b/documentation/ref-manual/ref-system-requirements.rst
@@ -20,9 +20,9 @@ chapter in the Yocto Project Overview and Concepts Manual.
If you want to use the Yocto Project to quickly build an image without
having to understand concepts, work through the
-:doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document. You can find "how-to"
-information in the :doc:`../dev-manual/dev-manual`. You can find Yocto Project overview
-and conceptual information in the :doc:`../overview-manual/overview-manual`.
+:doc:`../brief-yoctoprojectqs/index` document. You can find "how-to"
+information in the :doc:`../dev-manual/index`. You can find Yocto Project overview
+and conceptual information in the :doc:`../overview-manual/index`.
.. note::
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index f59aaf278..3c12a2470 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -58,8 +58,7 @@ universal, the list includes them just in case:
:term:`Board Support Package (BSP)`
A group of drivers, definitions, and other components that provide support
for a specific hardware configuration. For more information on BSPs, see
- the :ref:`bsp-guide/bsp-guide:Yocto Project Board Support Package
- Developer's Guide`.
+ the :doc:`/bsp-guide/index`.
:term:`Build Directory`
This term refers to the area used by the OpenEmbedded build system for
@@ -164,17 +163,14 @@ universal, the list includes them just in case:
":ref:`overview-manual/overview-manual-concepts:Cross-Development
Toolchain Generation`" section in the Yocto Project Overview and Concepts
Manual. You can also find more information on using the relocatable
- toolchain in the :ref:`sdk-manual/sdk-manual:Yocto Project Application
- Development and the Extensible Software Development Kit (eSDK)` manual.
+ toolchain in the :doc:`/sdk-manual/index` manual.
:term:`Extensible Software Development Kit (eSDK)`
A custom SDK for application developers. This eSDK allows developers to
incorporate their library and programming changes back into the image to
make their code available to other application developers.
- For information on the eSDK, see the :ref:`sdk-manual/sdk-manual:Yocto
- Project Application Development and the Extensible Software Development
- Kit (eSDK)` manual.
+ For information on the eSDK, see the :doc:`/sdk-manual/index` manual.
:term:`Image`
An image is an artifact of the BitBake build process given a collection of
@@ -384,7 +380,7 @@ universal, the list includes them just in case:
The interface enables you to
configure and run your builds. Information about builds is collected
and stored in a database. For information on Toaster, see the
- :doc:`../toaster-manual/toaster-manual`.
+ :doc:`../toaster-manual/index`.
:term:`Upstream`
A reference to source code or repositories that are not
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index f8cd5416d..5a52833e8 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -8154,7 +8154,7 @@ system and gives an overview of their function and contents.
":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
section in the Yocto Project Overview and Concepts Manual. For
information on setting up a cross-development environment, see the
- :doc:`../sdk-manual/sdk-manual` manual.
+ :doc:`../sdk-manual/index` manual.
:term:`TOOLCHAIN_OUTPUTNAME`
This variable defines the name used for the toolchain output. The
@@ -8184,7 +8184,7 @@ system and gives an overview of their function and contents.
":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
section in the Yocto Project Overview and Concepts Manual. For
information on setting up a cross-development environment, see the
- :doc:`../sdk-manual/sdk-manual` manual.
+ :doc:`../sdk-manual/index` manual.
:term:`TOPDIR`
The top-level :term:`Build Directory`. BitBake
diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst
index 70ba8e7be..e41ce95cf 100644
--- a/documentation/ref-manual/resources.rst
+++ b/documentation/ref-manual/resources.rst
@@ -125,18 +125,18 @@ Here is a list of resources you might find helpful:
guide to the BitBake tool. If you want information on BitBake, see
this manual.
-- :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` *:* This
+- :doc:`../brief-yoctoprojectqs/index` *:* This
short document lets you experience building an image using the Yocto
Project without having to understand any concepts or details.
-- :doc:`../overview-manual/overview-manual` *:* This manual provides overview
+- :doc:`../overview-manual/index` *:* This manual provides overview
and conceptual information about the Yocto Project.
-- :doc:`../dev-manual/dev-manual` *:* This manual is a "how-to" guide
+- :doc:`../dev-manual/index` *:* This manual is a "how-to" guide
that presents procedures useful to both application and system
developers who use the Yocto Project.
-- :doc:`../sdk-manual/sdk-manual` *manual :* This
+- :doc:`../sdk-manual/index` *manual :* This
guide provides information that lets you get going with the standard
or extensible SDK. An SDK, with its cross-development toolchains,
allows you to develop projects inside or outside of the Yocto Project
@@ -146,12 +146,12 @@ Here is a list of resources you might find helpful:
for BSP components. Having a commonly understood structure encourages
standardization.
-- :doc:`../kernel-dev/kernel-dev` *:* This manual describes
+- :doc:`../kernel-dev/index` *:* This manual describes
how to work with Linux Yocto kernels as well as provides a bit of
conceptual information on the construction of the Yocto Linux kernel
tree.
-- :doc:`../ref-manual/ref-manual` *:* This
+- :doc:`../ref-manual/index` *:* This
manual provides reference material such as variable, task, and class
descriptions.
@@ -161,11 +161,11 @@ Here is a list of resources you might find helpful:
which you can easily search for phrases and terms used in the Yocto
Project documentation set.
-- :doc:`../profile-manual/profile-manual` *:* This manual presents a set of
+- :doc:`../profile-manual/index` *:* This manual presents a set of
common and generally useful tracing and profiling schemes along with
their applications (as appropriate) to each tool.
-- :doc:`../toaster-manual/toaster-manual` *:* This manual
+- :doc:`../toaster-manual/index` *:* This manual
introduces and describes how to set up and use Toaster. Toaster is an
Application Programming Interface (API) and web-based interface to
the :term:`OpenEmbedded Build System`, which uses
diff --git a/documentation/sdk-manual/sdk-manual.rst b/documentation/sdk-manual/index.rst
similarity index 100%
rename from documentation/sdk-manual/sdk-manual.rst
rename to documentation/sdk-manual/index.rst
diff --git a/documentation/test-manual/test-manual.rst b/documentation/test-manual/index.rst
similarity index 100%
rename from documentation/test-manual/test-manual.rst
rename to documentation/test-manual/index.rst
diff --git a/documentation/toaster-manual/toaster-manual.rst b/documentation/toaster-manual/index.rst
similarity index 100%
rename from documentation/toaster-manual/toaster-manual.rst
rename to documentation/toaster-manual/index.rst
diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst
index b87fec689..3663f5336 100644
--- a/documentation/transitioning-to-a-custom-environment.rst
+++ b/documentation/transitioning-to-a-custom-environment.rst
@@ -8,7 +8,7 @@ Transitioning to a custom environment for systems development
.. note::
- So you've finished the :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` and
+ So you've finished the :doc:`brief-yoctoprojectqs/index` and
glanced over the document :doc:`what-i-wish-id-known`, the latter contains
important information learned from other users. You're well prepared. But
now, as you are starting your own project, it isn't exactly straightforward what
diff --git a/documentation/what-i-wish-id-known.rst b/documentation/what-i-wish-id-known.rst
index afc126382..3f9fdea5f 100644
--- a/documentation/what-i-wish-id-known.rst
+++ b/documentation/what-i-wish-id-known.rst
@@ -49,7 +49,7 @@ contact us with other suggestions.
their silicon. These layers have names such as "meta-intel" or "meta-ti". Try
not to build layers from scratch. If you do have custom silicon, use one of
these layers as a guide or template and familiarize yourself with the
- :doc:`bsp-guide/bsp-guide`.
+ :doc:`bsp-guide/index`.
#. **Do not put everything into one layer:**
Use different layers to logically separate information in your build. As an
@@ -126,7 +126,7 @@ contact us with other suggestions.
You can build and run a specific task for a specific package (including
devshell) or even a single recipe. When developers first start using the
Yocto Project, the instructions found in the
- :doc:`brief-yoctoprojectqs/brief-yoctoprojectqs` show how to create an image
+ :doc:`brief-yoctoprojectqs/index` show how to create an image
and then run or flash that image. However, you can actually build just a
single recipe. Thus, if some dependency or recipe isn't working, you can just
say "bitbake foo" where "foo" is the name for a specific recipe. As you
@@ -190,7 +190,7 @@ contact us with other suggestions.
contains procedural information grouped to help you get set up, work with
layers, customize images, write new recipes, work with libraries, and use
QEMU. The information is task-based and spans the breadth of the Yocto
- Project. See the :doc:`../dev-manual/dev-manual`.
+ Project. See the :doc:`../dev-manual/index`.
* **Look Through the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual**: This manual describes how to use
@@ -201,17 +201,17 @@ contact us with other suggestions.
for more information.
* **Learn About Kernel Development**: If you want to see how to work with the
- kernel and understand Yocto Linux kernels, see the :doc:`../kernel-dev/kernel-dev`.
+ kernel and understand Yocto Linux kernels, see the :doc:`../kernel-dev/index`.
This manual provides information on how to patch the kernel, modify kernel
recipes, and configure the kernel.
* **Learn About Board Support Packages (BSPs)**: If you want to learn about
- BSPs, see the :doc:`../bsp-guide/bsp-guide`. This manual also provides an
+ BSPs, see the :doc:`../bsp-guide/index`. This manual also provides an
example BSP creation workflow. See the :doc:`../bsp-guide/bsp` section.
* **Learn About Toaster**: Toaster is a web interface to the Yocto Project's
OpenEmbedded build system. If you are interested in using this type of
- interface to create images, see the :doc:`../toaster-manual/toaster-manual`.
+ interface to create images, see the :doc:`../toaster-manual/index`.
* **Have Available the Yocto Project Reference Manual**: Unlike the rest of
the Yocto Project manual set, this manual is comprised of material suited
@@ -219,7 +219,7 @@ contact us with other suggestions.
look at how the pieces of the Yocto Project development environment work
together, information on various technical details, guidance on migrating
to a newer Yocto Project release, reference material on the directory
- structure, classes, and tasks. The :doc:`../ref-manual/ref-manual` also
+ structure, classes, and tasks. The :doc:`../ref-manual/index` also
contains a fairly comprehensive glossary of variables used within the Yocto
Project.
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 02/10] sphinx: use absolute paths for :doc: references
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 01/10] sphinx: rename top level document in each manual Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 03/10] test-manual: remove 'test-manual' from filenames Nicolas Dechesne
` (7 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne, Robert P . J . Day
:doc: references can be made with absolute path instead of relative
path. This patch was generated with this command:
sed -i 's!:doc:`\.\./!:doc:`/!g' */*.rst *.rst
And a few manual fixup we made for references such as:
:doc:"FOOBAR <../xxx>"
Suggested-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
documentation/brief-yoctoprojectqs/index.rst | 4 ++--
.../dev-manual/dev-manual-common-tasks.rst | 14 +++++++-------
documentation/dev-manual/dev-manual-intro.rst | 6 +++---
documentation/dev-manual/dev-manual-start.rst | 14 +++++++-------
.../kernel-dev/kernel-dev-advanced.rst | 2 +-
documentation/kernel-dev/kernel-dev-common.rst | 4 ++--
documentation/kernel-dev/kernel-dev-intro.rst | 6 +++---
.../overview-manual-concepts.rst | 8 ++++----
...overview-manual-development-environment.rst | 6 +++---
.../overview-manual/overview-manual-intro.rst | 10 +++++-----
.../overview-manual-yp-intro.rst | 18 +++++++++---------
documentation/ref-manual/faq.rst | 2 +-
documentation/ref-manual/migration-2.1.rst | 2 +-
.../ref-manual/ref-devtool-reference.rst | 2 +-
documentation/ref-manual/ref-features.rst | 4 ++--
.../ref-manual/ref-release-process.rst | 2 +-
documentation/ref-manual/ref-structure.rst | 2 +-
.../ref-manual/ref-system-requirements.rst | 6 +++---
documentation/ref-manual/ref-terms.rst | 2 +-
documentation/ref-manual/ref-variables.rst | 10 +++++-----
documentation/ref-manual/resources.rst | 18 +++++++++---------
documentation/sdk-manual/sdk-intro.rst | 2 +-
documentation/what-i-wish-id-known.rst | 14 +++++++-------
23 files changed, 79 insertions(+), 79 deletions(-)
diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst
index e8912f07c..c1b78d0f5 100644
--- a/documentation/brief-yoctoprojectqs/index.rst
+++ b/documentation/brief-yoctoprojectqs/index.rst
@@ -39,7 +39,7 @@ build a reference embedded OS called Poky.
Tasks Manual for more information.
If you want more conceptual or background information on the Yocto
-Project, see the :doc:`../overview-manual/index`.
+Project, see the :doc:`/overview-manual/index`.
Compatible Linux Distribution
=============================
@@ -404,7 +404,7 @@ information including the website, wiki pages, and user manuals:
concepts are useful for the beginner.
- **Yocto Project Overview and Concepts Manual:** The
- :doc:`../overview-manual/index` is a great
+ :doc:`/overview-manual/index` is a great
place to start to learn about the Yocto Project. This manual
introduces you to the Yocto Project and its development environment.
The manual also provides conceptual information for various aspects
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst
index e22bcd50e..0a2e6d9df 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/dev-manual-common-tasks.rst
@@ -1319,7 +1319,7 @@ to determine how well the build went.
``log.do_fetch``, and ``log.do_compile``).
You can find more information about the build process in
-":doc:`../overview-manual/overview-manual-development-environment`"
+":doc:`/overview-manual/overview-manual-development-environment`"
chapter of the Yocto Project Overview and Concepts Manual.
Fetching Code
@@ -3127,7 +3127,7 @@ Using ``devtool upgrade``
As mentioned earlier, an alternative method for upgrading recipes to
newer versions is to use
-:doc:`devtool upgrade <../ref-manual/ref-devtool-reference>`.
+:doc:`devtool upgrade </ref-manual/ref-devtool-reference>`.
You can read about ``devtool upgrade`` in general in the
":ref:`sdk-manual/sdk-extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
section in the Yocto Project Application Development and the Extensible
@@ -3644,7 +3644,7 @@ build host running Linux.
- For information on how to build an image using
:term:`Toaster`, see the
- :doc:`../toaster-manual/index`.
+ :doc:`/toaster-manual/index`.
- For information on how to use ``devtool`` to build images, see the
":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
@@ -3653,7 +3653,7 @@ build host running Linux.
- For a quick example on how to build an image using the
OpenEmbedded build system, see the
- :doc:`../brief-yoctoprojectqs/index` document.
+ :doc:`/brief-yoctoprojectqs/index` document.
The build process creates an entire Linux distribution from source and
places it in your :term:`Build Directory` under
@@ -3728,7 +3728,7 @@ The following figure and list overviews the build process:
kernels built by the OpenEmbedded build system are placed in the
Build Directory in ``tmp/deploy/images``. For information on how to
run pre-built images such as ``qemux86`` and ``qemuarm``, see the
- :doc:`../sdk-manual/index` manual. For
+ :doc:`/sdk-manual/index` manual. For
information about how to install these images, see the documentation
for your particular board or machine.
@@ -7418,7 +7418,7 @@ Creating Node Package Manager (NPM) Packages
manager for the JavaScript programming language. The Yocto Project
supports the NPM :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`. You can
use this fetcher in combination with
-:doc:`devtool <../ref-manual/ref-devtool-reference>` to create
+:doc:`devtool </ref-manual/ref-devtool-reference>` to create
recipes that produce NPM packages.
Two workflows exist that allow you to create NPM packages using
@@ -7446,7 +7446,7 @@ NPM packages:
is NPM's public registry.
- Be familiar with
- :doc:`devtool <../ref-manual/ref-devtool-reference>`.
+ :doc:`devtool </ref-manual/ref-devtool-reference>`.
- The NPM host tools need the native ``nodejs-npm`` package, which is
part of the OpenEmbedded environment. You need to get the package by
diff --git a/documentation/dev-manual/dev-manual-intro.rst b/documentation/dev-manual/dev-manual-intro.rst
index 94c481b7d..23c848e87 100644
--- a/documentation/dev-manual/dev-manual-intro.rst
+++ b/documentation/dev-manual/dev-manual-intro.rst
@@ -31,13 +31,13 @@ This manual provides the following:
This manual does not provide the following:
- Redundant Step-by-step Instructions: For example, the
- :doc:`../sdk-manual/index` manual contains detailed
+ :doc:`/sdk-manual/index` manual contains detailed
instructions on how to install an SDK, which is used to develop
applications for target hardware.
- Reference or Conceptual Material: This type of material resides in an
appropriate reference manual. For example, system variables are
- documented in the :doc:`../ref-manual/index`.
+ documented in the :doc:`/ref-manual/index`.
- Detailed Public Information Not Specific to the Yocto Project: For
example, exhaustive information on how to use the Source Control
@@ -52,7 +52,7 @@ supplemental information is recommended for full comprehension. For
introductory information on the Yocto Project, see the
:yocto_home:`Yocto Project Website <>`. If you want to build an image with no
knowledge of Yocto Project as a way of quickly testing it out, see the
-:doc:`../brief-yoctoprojectqs/index` document.
+:doc:`/brief-yoctoprojectqs/index` document.
For a comprehensive list of links and other documentation, see the
":ref:`ref-manual/resources:links and related documentation`"
diff --git a/documentation/dev-manual/dev-manual-start.rst b/documentation/dev-manual/dev-manual-start.rst
index 053f09cdc..d4727a6f6 100644
--- a/documentation/dev-manual/dev-manual-start.rst
+++ b/documentation/dev-manual/dev-manual-start.rst
@@ -342,10 +342,10 @@ using a given development path on your native Linux machine. If you are
going to use BitBake, see the
":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
section. If you are going
-to use the Extensible SDK, see the ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+to use the Extensible SDK, see the ":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
-Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`../kernel-dev/index`. If you are going to use
-Toaster, see the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`/kernel-dev/index`. If you are going to use
+Toaster, see the ":doc:`/toaster-manual/toaster-manual-setup-and-use`"
section in the Toaster User Manual.
Setting Up to Use CROss PlatformS (CROPS)
@@ -442,10 +442,10 @@ as if you were running on a native Linux machine. If you are going to
use the Poky container, see the
":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
section. If you are going to use the Extensible SDK container, see the
-":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/toaster-manual-setup-and-use`"
section in the Toaster User Manual.
Setting Up to Use Windows Subsystem For Linux (WSLv2)
@@ -557,10 +557,10 @@ your Yocto Project build host:
Once you have WSLv2 set up, everything is in place to develop just as if
you were running on a native Linux machine. If you are going to use the
-Extensible SDK container, see the ":doc:`../sdk-manual/sdk-extensible`" Chapter in the Yocto
+Extensible SDK container, see the ":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`../toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/toaster-manual-setup-and-use`"
section in the Toaster User Manual.
Locating Yocto Project Source Files
diff --git a/documentation/kernel-dev/kernel-dev-advanced.rst b/documentation/kernel-dev/kernel-dev-advanced.rst
index cc4834325..ddb31edca 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.rst
+++ b/documentation/kernel-dev/kernel-dev-advanced.rst
@@ -474,7 +474,7 @@ supported kernel type.
This section overviews the BSP description structure, the aggregation
concepts, and presents a detailed example using a BSP supported by the
Yocto Project (i.e. BeagleBone Board). For complete information on BSP
-layer file hierarchy, see the :doc:`../bsp-guide/index`.
+layer file hierarchy, see the :doc:`/bsp-guide/index`.
Description Overview
~~~~~~~~~~~~~~~~~~~~
diff --git a/documentation/kernel-dev/kernel-dev-common.rst b/documentation/kernel-dev/kernel-dev-common.rst
index c57025c67..8e9bc27bf 100644
--- a/documentation/kernel-dev/kernel-dev-common.rst
+++ b/documentation/kernel-dev/kernel-dev-common.rst
@@ -21,7 +21,7 @@ Preparing the Build Host to Work on the Kernel
Before you can do any kernel development, you need to be sure your build
host is set up to use the Yocto Project. For information on how to get
-set up, see the ":doc:`../dev-manual/dev-manual-start`" section in
+set up, see the ":doc:`/dev-manual/dev-manual-start`" section in
the Yocto Project Development Tasks Manual. Part of preparing the system
is creating a local Git repository of the
:term:`Source Directory` (``poky``) on your system. Follow the steps in the
@@ -502,7 +502,7 @@ your layer in the following area:
.. note::
If you are working on a new machine Board Support Package (BSP), be
- sure to refer to the :doc:`../bsp-guide/index`.
+ sure to refer to the :doc:`/bsp-guide/index`.
As an example, consider the following append file used by the BSPs in
``meta-yocto-bsp``:
diff --git a/documentation/kernel-dev/kernel-dev-intro.rst b/documentation/kernel-dev/kernel-dev-intro.rst
index a2961d864..29d4516c5 100644
--- a/documentation/kernel-dev/kernel-dev-intro.rst
+++ b/documentation/kernel-dev/kernel-dev-intro.rst
@@ -79,9 +79,9 @@ facilitate the process of working with the kernel recipes. If you find
you need some additional background, please be sure to review and
understand the following documentation:
-- :doc:`../brief-yoctoprojectqs/index` document.
+- :doc:`/brief-yoctoprojectqs/index` document.
-- :doc:`../overview-manual/index`.
+- :doc:`/overview-manual/index`.
- :ref:`devtool
workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
@@ -111,7 +111,7 @@ general information and references for further information.
:align: center
1. *Set up Your Host Development System to Support Development Using the
- Yocto Project*: See the ":doc:`../dev-manual/dev-manual-start`" section in
+ Yocto Project*: See the ":doc:`/dev-manual/dev-manual-start`" section in
the Yocto Project Development Tasks Manual for options on how to get
a build host ready to use the Yocto Project.
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst
index d79dacbfb..bbf2d0494 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/overview-manual-concepts.rst
@@ -481,7 +481,7 @@ The BSP Layer provides machine configurations that target specific
hardware. Everything in this layer is specific to the machine for which
you are building the image or the SDK. A common structure or form is
defined for BSP layers. You can learn more about this structure in the
-:doc:`../bsp-guide/index`.
+:doc:`/bsp-guide/index`.
.. note::
@@ -1285,7 +1285,7 @@ this output:
.. note::
For a list of example images that the Yocto Project provides, see the
- ":doc:`../ref-manual/ref-images`" chapter in the Yocto Project Reference
+ ":doc:`/ref-manual/ref-images`" chapter in the Yocto Project Reference
Manual.
The build process writes images out to the :term:`Build Directory`
@@ -1366,7 +1366,7 @@ can initialize the environment before using the tools.
section.
- For information on setting up a cross-development environment, see
- the :doc:`../sdk-manual/index` manual.
+ the :doc:`/sdk-manual/index` manual.
All the output files for an SDK are written to the ``deploy/sdk`` folder
inside the :term:`Build Directory` as
@@ -1446,7 +1446,7 @@ The Yocto Project does most of the work for you when it comes to
creating :ref:`sdk-manual/sdk-intro:the cross-development toolchain`. This
section provides some technical background on how cross-development
toolchains are created and used. For more information on toolchains, you
-can also see the :doc:`../sdk-manual/index` manual.
+can also see the :doc:`/sdk-manual/index` manual.
In the Yocto Project development environment, cross-development
toolchains are used to build images and applications that run on the
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index 36a246213..2421ec1a8 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -103,7 +103,7 @@ methods exist for you to do work in the Yocto Project environment:
hardware. To development BSPs, you need to take some additional steps
beyond what was described in setting up a development host.
- The :doc:`../bsp-guide/index` provides BSP-related development
+ The :doc:`/bsp-guide/index` provides BSP-related development
information. For specifics on development host preparation, see the
":ref:`bsp-guide/bsp:preparing your build host to work with bsp layers`"
section in the Yocto Project Board Support Package (BSP) Developer's
@@ -114,7 +114,7 @@ methods exist for you to do work in the Yocto Project environment:
using ``devtool`` makes kernel development quicker by reducing
iteration cycle times.
- The :doc:`../kernel-dev/index` provides kernel-related
+ The :doc:`/kernel-dev/index` provides kernel-related
development information. For specifics on development host
preparation, see the
":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
@@ -130,7 +130,7 @@ methods exist for you to do work in the Yocto Project environment:
For steps that show you how to set up your development host to use
Toaster and on how to use Toaster in general, see the
- :doc:`../toaster-manual/index`.
+ :doc:`/toaster-manual/index`.
Yocto Project Source Repositories
=================================
diff --git a/documentation/overview-manual/overview-manual-intro.rst b/documentation/overview-manual/overview-manual-intro.rst
index c6fb53ca2..50c623c3b 100644
--- a/documentation/overview-manual/overview-manual-intro.rst
+++ b/documentation/overview-manual/overview-manual-intro.rst
@@ -37,17 +37,17 @@ This manual does not give you the following:
- *Step-by-step Instructions for Development Tasks:* Instructional
procedures reside in other manuals within the Yocto Project
- documentation set. For example, the :doc:`../dev-manual/index`
+ documentation set. For example, the :doc:`/dev-manual/index`
provides examples on how to perform
various development tasks. As another example, the
- :doc:`../sdk-manual/index` manual contains detailed
+ :doc:`/sdk-manual/index` manual contains detailed
instructions on how to install an SDK, which is used to develop
applications for target hardware.
- *Reference Material:* This type of material resides in an appropriate
reference manual. For example, system variables are documented in the
- :doc:`../ref-manual/index`. As another
- example, the :doc:`../bsp-guide/index` contains reference information on
+ :doc:`/ref-manual/index`. As another
+ example, the :doc:`/bsp-guide/index` contains reference information on
BSPs.
- *Detailed Public Information Not Specific to the Yocto Project:* For
@@ -63,7 +63,7 @@ supplemental information is recommended for full comprehension. For
additional introductory information on the Yocto Project, see the
:yocto_home:`Yocto Project Website <>`. If you want to build an image
with no knowledge of Yocto Project as a way of quickly testing it out,
-see the :doc:`../brief-yoctoprojectqs/index` document.
+see the :doc:`/brief-yoctoprojectqs/index` document.
For a comprehensive list of links and other documentation, see the
":ref:`Links and Related
Documentation <resources-links-and-related-documentation>`"
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index bf12a673b..637d57abb 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -111,7 +111,7 @@ Project:
development.
- *Releases According to a Strict Schedule:* Major releases occur on a
- :doc:`six-month cycle <../ref-manual/ref-release-process>`
+ :doc:`six-month cycle </ref-manual/ref-release-process>`
predictably in October and April. The most recent two releases
support point releases to address common vulnerabilities and
exposures. This predictability is crucial for projects based on the
@@ -251,7 +251,7 @@ accomplish this through a recipe that is a BitBake append
.. note::
For general information on BSP layer structure, see the
- :doc:`../bsp-guide/index`
+ :doc:`/bsp-guide/index`
.
The :term:`Source Directory`
@@ -339,12 +339,12 @@ applications using the Yocto Project:
experience supplemented with the powerful set of ``devtool`` commands
tailored for the Yocto Project environment.
- For information on the eSDK, see the :doc:`../sdk-manual/index` Manual.
+ For information on the eSDK, see the :doc:`/sdk-manual/index` Manual.
- *Toaster:* Toaster is a web interface to the Yocto Project
OpenEmbedded build system. Toaster allows you to configure, run, and
view information about builds. For information on Toaster, see the
- :doc:`../toaster-manual/index`.
+ :doc:`/toaster-manual/index`.
Production Tools
----------------
@@ -392,7 +392,7 @@ activities using the Yocto Project:
benefit of the development community.
You can learn more about the AutoBuilder used by the Yocto Project
- Autobuilder :doc:`here <../test-manual/test-manual-understand-autobuilder>`.
+ Autobuilder :doc:`here </test-manual/test-manual-understand-autobuilder>`.
- *Cross-Prelink:* Prelinking is the process of pre-computing the load
addresses and link tables generated by the dynamic linker as compared
@@ -650,7 +650,7 @@ Project.
configure and start builds on multiple remote build servers.
For information about and how to use Toaster, see the
- :doc:`../toaster-manual/index`.
+ :doc:`/toaster-manual/index`.
Reference Embedded Distribution (Poky)
======================================
@@ -720,7 +720,7 @@ Poky has a regular, well established, six-month release cycle under its
own version. Major releases occur at the same time major releases (point
releases) occur for the Yocto Project, which are typically in the Spring
and Fall. For more information on the Yocto Project release schedule and
-cadence, see the ":doc:`../ref-manual/ref-release-process`" chapter in the
+cadence, see the ":doc:`/ref-manual/ref-release-process`" chapter in the
Yocto Project Reference Manual.
Much has been said about Poky being a "default configuration". A default
@@ -798,7 +798,7 @@ Some Basic Terms
It helps to understand some basic fundamental terms when learning the
Yocto Project. Although a list of terms exists in the ":doc:`Yocto Project
-Terms <../ref-manual/ref-terms>`" section of the Yocto Project
+Terms </ref-manual/ref-terms>`" section of the Yocto Project
Reference Manual, this section provides the definitions of some terms
helpful for getting started:
@@ -812,7 +812,7 @@ helpful for getting started:
application developers. This eSDK allows developers to incorporate
their library and programming changes back into the image to make
their code available to other application developers. For information
- on the eSDK, see the :doc:`../sdk-manual/index` manual.
+ on the eSDK, see the :doc:`/sdk-manual/index` manual.
- *Layer:* A collection of related recipes. Layers allow you to
consolidate related metadata to customize your build. Layers also
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index 747561e06..819b6857d 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -47,7 +47,7 @@ Support Package (BSP) layer for it. For more information on how to
create a BSP layer, see the
":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual and the
-:doc:`../bsp-guide/index`.
+:doc:`/bsp-guide/index`.
Usually, if the board is not completely exotic, adding support in the
Yocto Project is fairly straightforward.
diff --git a/documentation/ref-manual/migration-2.1.rst b/documentation/ref-manual/migration-2.1.rst
index 8ea1aa7f0..25ee21499 100644
--- a/documentation/ref-manual/migration-2.1.rst
+++ b/documentation/ref-manual/migration-2.1.rst
@@ -234,7 +234,7 @@ functionality almost completely overlapped with the :ref:`standard
SDK <sdk-manual/sdk-using:using the standard sdk>` and the
:ref:`extensible SDK <sdk-manual/sdk-extensible:using the extensible sdk>`. For
information on these SDKs and how to build and use them, see the
-:doc:`../sdk-manual/index` manual.
+:doc:`/sdk-manual/index` manual.
.. note::
diff --git a/documentation/ref-manual/ref-devtool-reference.rst b/documentation/ref-manual/ref-devtool-reference.rst
index a769b3bd4..83861d271 100644
--- a/documentation/ref-manual/ref-devtool-reference.rst
+++ b/documentation/ref-manual/ref-devtool-reference.rst
@@ -11,7 +11,7 @@ is a key part of the extensible SDK.
This chapter provides a Quick Reference for the ``devtool`` command. For
more information on how to apply the command when using the extensible
-SDK, see the ":doc:`../sdk-manual/sdk-extensible`" chapter in the Yocto
+SDK, see the ":doc:`/sdk-manual/sdk-extensible`" chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual.
diff --git a/documentation/ref-manual/ref-features.rst b/documentation/ref-manual/ref-features.rst
index c9223e413..6c85c2418 100644
--- a/documentation/ref-manual/ref-features.rst
+++ b/documentation/ref-manual/ref-features.rst
@@ -261,7 +261,7 @@ these valid features is as follows:
- *perf:* Installs profiling tools such as ``perf``, ``systemtap``, and
``LTTng``. For general information on user-space tools, see the
- :doc:`../sdk-manual/index` manual.
+ :doc:`/sdk-manual/index` manual.
- *ssh-server-dropbear:* Installs the Dropbear minimal SSH server.
@@ -275,7 +275,7 @@ these valid features is as follows:
``gdb``. For information on GDB, see the
":ref:`dev-manual/dev-manual-common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
in the Yocto Project Development Tasks Manual. For information on
- tracing and profiling, see the :doc:`../profile-manual/index`.
+ tracing and profiling, see the :doc:`/profile-manual/index`.
- *tools-sdk:* Installs a full SDK that runs on the device.
diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst
index c77a3bcb1..ec6d23387 100644
--- a/documentation/ref-manual/ref-release-process.rst
+++ b/documentation/ref-manual/ref-release-process.rst
@@ -128,7 +128,7 @@ consists of the following pieces:
- :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
performs runtime testing of images after they are built. The tests
- are usually used with :doc:`QEMU <../dev-manual/dev-manual-qemu>`
+ are usually used with :doc:`QEMU </dev-manual/dev-manual-qemu>`
to boot the images and check the combined runtime result boot
operation and functions. However, the test can also use the IP
address of a machine to test.
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index a172a0b71..d3a231554 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -104,7 +104,7 @@ metadata to define the Poky reference distribution.
This directory contains the Yocto Project reference hardware Board
Support Packages (BSPs). For more information on BSPs, see the
-:doc:`../bsp-guide/index`.
+:doc:`/bsp-guide/index`.
.. _structure-meta-selftest:
diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/ref-system-requirements.rst
index 937cd0c70..2c7c1e075 100644
--- a/documentation/ref-manual/ref-system-requirements.rst
+++ b/documentation/ref-manual/ref-system-requirements.rst
@@ -20,9 +20,9 @@ chapter in the Yocto Project Overview and Concepts Manual.
If you want to use the Yocto Project to quickly build an image without
having to understand concepts, work through the
-:doc:`../brief-yoctoprojectqs/index` document. You can find "how-to"
-information in the :doc:`../dev-manual/index`. You can find Yocto Project overview
-and conceptual information in the :doc:`../overview-manual/index`.
+:doc:`/brief-yoctoprojectqs/index` document. You can find "how-to"
+information in the :doc:`/dev-manual/index`. You can find Yocto Project overview
+and conceptual information in the :doc:`/overview-manual/index`.
.. note::
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index 3c12a2470..6f0facf72 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -380,7 +380,7 @@ universal, the list includes them just in case:
The interface enables you to
configure and run your builds. Information about builds is collected
and stored in a database. For information on Toaster, see the
- :doc:`../toaster-manual/index`.
+ :doc:`/toaster-manual/index`.
:term:`Upstream`
A reference to source code or repositories that are not
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index 5a52833e8..8411989b6 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -2907,7 +2907,7 @@ system and gives an overview of their function and contents.
":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
section of the Yocto Project Development Tasks Manual. Reference
material for Wic is located in the
- ":doc:`../ref-manual/ref-kickstart`" chapter.
+ ":doc:`/ref-manual/ref-kickstart`" chapter.
:term:`IMAGE_BOOT_FILES`
A space-separated list of files installed into the boot partition
@@ -2943,7 +2943,7 @@ system and gives an overview of their function and contents.
":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
section of the Yocto Project Development Tasks Manual. Reference
material for Wic is located in the
- ":doc:`../ref-manual/ref-kickstart`" chapter.
+ ":doc:`/ref-manual/ref-kickstart`" chapter.
:term:`IMAGE_CLASSES`
A list of classes that all images should inherit. You typically use
@@ -8154,7 +8154,7 @@ system and gives an overview of their function and contents.
":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
section in the Yocto Project Overview and Concepts Manual. For
information on setting up a cross-development environment, see the
- :doc:`../sdk-manual/index` manual.
+ :doc:`/sdk-manual/index` manual.
:term:`TOOLCHAIN_OUTPUTNAME`
This variable defines the name used for the toolchain output. The
@@ -8184,7 +8184,7 @@ system and gives an overview of their function and contents.
":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
section in the Yocto Project Overview and Concepts Manual. For
information on setting up a cross-development environment, see the
- :doc:`../sdk-manual/index` manual.
+ :doc:`/sdk-manual/index` manual.
:term:`TOPDIR`
The top-level :term:`Build Directory`. BitBake
@@ -8737,7 +8737,7 @@ system and gives an overview of their function and contents.
image, see the
":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
section in the Yocto Project Development Tasks Manual. For details on
- the kickstart file format, see the ":doc:`../ref-manual/ref-kickstart`" Chapter.
+ the kickstart file format, see the ":doc:`/ref-manual/ref-kickstart`" Chapter.
:term:`WKS_FILE_DEPENDS`
When placed in the recipe that builds your image, this variable lists
diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst
index e41ce95cf..fd04593d4 100644
--- a/documentation/ref-manual/resources.rst
+++ b/documentation/ref-manual/resources.rst
@@ -125,33 +125,33 @@ Here is a list of resources you might find helpful:
guide to the BitBake tool. If you want information on BitBake, see
this manual.
-- :doc:`../brief-yoctoprojectqs/index` *:* This
+- :doc:`/brief-yoctoprojectqs/index` *:* This
short document lets you experience building an image using the Yocto
Project without having to understand any concepts or details.
-- :doc:`../overview-manual/index` *:* This manual provides overview
+- :doc:`/overview-manual/index` *:* This manual provides overview
and conceptual information about the Yocto Project.
-- :doc:`../dev-manual/index` *:* This manual is a "how-to" guide
+- :doc:`/dev-manual/index` *:* This manual is a "how-to" guide
that presents procedures useful to both application and system
developers who use the Yocto Project.
-- :doc:`../sdk-manual/index` *manual :* This
+- :doc:`/sdk-manual/index` *manual :* This
guide provides information that lets you get going with the standard
or extensible SDK. An SDK, with its cross-development toolchains,
allows you to develop projects inside or outside of the Yocto Project
environment.
-- :doc:`../bsp-guide/bsp` *:* This guide defines the structure
+- :doc:`/bsp-guide/bsp` *:* This guide defines the structure
for BSP components. Having a commonly understood structure encourages
standardization.
-- :doc:`../kernel-dev/index` *:* This manual describes
+- :doc:`/kernel-dev/index` *:* This manual describes
how to work with Linux Yocto kernels as well as provides a bit of
conceptual information on the construction of the Yocto Linux kernel
tree.
-- :doc:`../ref-manual/index` *:* This
+- :doc:`/ref-manual/index` *:* This
manual provides reference material such as variable, task, and class
descriptions.
@@ -161,11 +161,11 @@ Here is a list of resources you might find helpful:
which you can easily search for phrases and terms used in the Yocto
Project documentation set.
-- :doc:`../profile-manual/index` *:* This manual presents a set of
+- :doc:`/profile-manual/index` *:* This manual presents a set of
common and generally useful tracing and profiling schemes along with
their applications (as appropriate) to each tool.
-- :doc:`../toaster-manual/index` *:* This manual
+- :doc:`/toaster-manual/index` *:* This manual
introduces and describes how to set up and use Toaster. Toaster is an
Application Programming Interface (API) and web-based interface to
the :term:`OpenEmbedded Build System`, which uses
diff --git a/documentation/sdk-manual/sdk-intro.rst b/documentation/sdk-manual/sdk-intro.rst
index bbd33b8a7..5514c6767 100644
--- a/documentation/sdk-manual/sdk-intro.rst
+++ b/documentation/sdk-manual/sdk-intro.rst
@@ -211,7 +211,7 @@ You just need to follow these general steps:
tools to develop your application. If you need to separately install
and use the QEMU emulator, you can go to `QEMU Home
Page <http://wiki.qemu.org/Main_Page>`__ to download and learn about
- the emulator. See the ":doc:`../dev-manual/dev-manual-qemu`" chapter in the
+ the emulator. See the ":doc:`/dev-manual/dev-manual-qemu`" chapter in the
Yocto Project Development Tasks Manual for information on using QEMU
within the Yocto Project.
diff --git a/documentation/what-i-wish-id-known.rst b/documentation/what-i-wish-id-known.rst
index 3f9fdea5f..563594b52 100644
--- a/documentation/what-i-wish-id-known.rst
+++ b/documentation/what-i-wish-id-known.rst
@@ -190,28 +190,28 @@ contact us with other suggestions.
contains procedural information grouped to help you get set up, work with
layers, customize images, write new recipes, work with libraries, and use
QEMU. The information is task-based and spans the breadth of the Yocto
- Project. See the :doc:`../dev-manual/index`.
+ Project. See the :doc:`/dev-manual/index`.
* **Look Through the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual**: This manual describes how to use
both the standard SDK and the extensible SDK, which are used primarily for
- application development. The :doc:`../sdk-manual/sdk-extensible` also provides
+ application development. The :doc:`/sdk-manual/sdk-extensible` also provides
example workflows that use devtool. See the section
:ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`
for more information.
* **Learn About Kernel Development**: If you want to see how to work with the
- kernel and understand Yocto Linux kernels, see the :doc:`../kernel-dev/index`.
+ kernel and understand Yocto Linux kernels, see the :doc:`/kernel-dev/index`.
This manual provides information on how to patch the kernel, modify kernel
recipes, and configure the kernel.
* **Learn About Board Support Packages (BSPs)**: If you want to learn about
- BSPs, see the :doc:`../bsp-guide/index`. This manual also provides an
- example BSP creation workflow. See the :doc:`../bsp-guide/bsp` section.
+ BSPs, see the :doc:`/bsp-guide/index`. This manual also provides an
+ example BSP creation workflow. See the :doc:`/bsp-guide/bsp` section.
* **Learn About Toaster**: Toaster is a web interface to the Yocto Project's
OpenEmbedded build system. If you are interested in using this type of
- interface to create images, see the :doc:`../toaster-manual/index`.
+ interface to create images, see the :doc:`/toaster-manual/index`.
* **Have Available the Yocto Project Reference Manual**: Unlike the rest of
the Yocto Project manual set, this manual is comprised of material suited
@@ -219,7 +219,7 @@ contact us with other suggestions.
look at how the pieces of the Yocto Project development environment work
together, information on various technical details, guidance on migrating
to a newer Yocto Project release, reference material on the directory
- structure, classes, and tasks. The :doc:`../ref-manual/index` also
+ structure, classes, and tasks. The :doc:`/ref-manual/index` also
contains a fairly comprehensive glossary of variables used within the Yocto
Project.
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 03/10] test-manual: remove 'test-manual' from filenames
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 01/10] sphinx: rename top level document in each manual Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 02/10] sphinx: use absolute paths for :doc: references Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 04/10] toaster-manual: remove 'toaster-manual' " Nicolas Dechesne
` (6 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
All filenames duplicate the 'manual name', which is not needed, and
make all references longer than they should. Rename all files to be as
consise as possible, and fix all references
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
.../overview-manual/overview-manual-yp-intro.rst | 2 +-
documentation/test-manual/index.rst | 6 +++---
.../test-manual/{test-manual-intro.rst => intro.rst} | 2 +-
...test-manual-test-process.rst => test-process.rst} | 0
...nd-autobuilder.rst => understand-autobuilder.rst} | 12 ++++++------
5 files changed, 11 insertions(+), 11 deletions(-)
rename documentation/test-manual/{test-manual-intro.rst => intro.rst} (99%)
rename documentation/test-manual/{test-manual-test-process.rst => test-process.rst} (100%)
rename documentation/test-manual/{test-manual-understand-autobuilder.rst => understand-autobuilder.rst} (95%)
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index 637d57abb..d6488c621 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -392,7 +392,7 @@ activities using the Yocto Project:
benefit of the development community.
You can learn more about the AutoBuilder used by the Yocto Project
- Autobuilder :doc:`here </test-manual/test-manual-understand-autobuilder>`.
+ Autobuilder :doc:`here </test-manual/understand-autobuilder>`.
- *Cross-Prelink:* Prelinking is the process of pre-computing the load
addresses and link tables generated by the dynamic linker as compared
diff --git a/documentation/test-manual/index.rst b/documentation/test-manual/index.rst
index 2891f06d8..e2198c4c3 100644
--- a/documentation/test-manual/index.rst
+++ b/documentation/test-manual/index.rst
@@ -10,9 +10,9 @@ Yocto Project Test Environment Manual
:caption: Table of Contents
:numbered:
- test-manual-intro
- test-manual-test-process
- test-manual-understand-autobuilder
+ intro
+ test-process
+ understand-autobuilder
history
.. include:: /boilerplate.rst
diff --git a/documentation/test-manual/test-manual-intro.rst b/documentation/test-manual/intro.rst
similarity index 99%
rename from documentation/test-manual/test-manual-intro.rst
rename to documentation/test-manual/intro.rst
index b41972084..6168ad770 100644
--- a/documentation/test-manual/test-manual-intro.rst
+++ b/documentation/test-manual/intro.rst
@@ -310,7 +310,7 @@ Test Examples
=============
This section provides example tests for each of the tests listed in the
-:ref:`test-manual/test-manual-intro:How Tests Map to Areas of Code` section.
+:ref:`test-manual/intro:How Tests Map to Areas of Code` section.
For oeqa tests, testcases for each area reside in the main test
directory at ``meta/lib/oeqa/selftest/cases`` directory.
diff --git a/documentation/test-manual/test-manual-test-process.rst b/documentation/test-manual/test-process.rst
similarity index 100%
rename from documentation/test-manual/test-manual-test-process.rst
rename to documentation/test-manual/test-process.rst
diff --git a/documentation/test-manual/test-manual-understand-autobuilder.rst b/documentation/test-manual/understand-autobuilder.rst
similarity index 95%
rename from documentation/test-manual/test-manual-understand-autobuilder.rst
rename to documentation/test-manual/understand-autobuilder.rst
index ca0c5fd2e..199cc97a8 100644
--- a/documentation/test-manual/test-manual-understand-autobuilder.rst
+++ b/documentation/test-manual/understand-autobuilder.rst
@@ -84,7 +84,7 @@ roughly consist of:
This cleans out any previous build. Old builds are left around to
allow easier debugging of failed builds. For additional information,
- see :ref:`test-manual/test-manual-understand-autobuilder:clobberdir`.
+ see :ref:`test-manual/understand-autobuilder:clobberdir`.
#. *Obtain yocto-autobuilder-helper*
@@ -108,7 +108,7 @@ roughly consist of:
from the ``layerinfo.json`` file to help understand the
configuration. It will also use a local cache of repositories to
speed up the clone checkouts. For additional information, see
- :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Clone Cache`.
+ :ref:`test-manual/understand-autobuilder:Autobuilder Clone Cache`.
This step has two possible modes of operation. If the build is part
of a parent build, its possible that all the repositories needed may
@@ -147,7 +147,7 @@ special script that moves files to a special location, rather than
deleting them. Files in this location are deleted by an ``rm`` command,
which is run under ``ionice -c 3``. For example, the deletion only
happens when there is idle IO capacity on the Worker. The Autobuilder
-Worker Janitor runs this deletion. See :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Worker Janitor`.
+Worker Janitor runs this deletion. See :ref:`test-manual/understand-autobuilder:Autobuilder Worker Janitor`.
Autobuilder Clone Cache
-----------------------
@@ -157,13 +157,13 @@ on the Autobuilder. We therefore have a stash of commonly used
repositories pre-cloned on the Workers. Data is fetched from these
during clones first, then "topped up" with later revisions from any
upstream when necessary. The cache is maintained by the Autobuilder
-Worker Janitor. See :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Worker Janitor`.
+Worker Janitor. See :ref:`test-manual/understand-autobuilder:Autobuilder Worker Janitor`.
Autobuilder Worker Janitor
--------------------------
This is a process running on each Worker that performs two basic
-operations, including background file deletion at IO idle (see :ref:`test-manual/test-manual-understand-autobuilder:Autobuilder Target Execution Overview`: Run clobberdir) and
+operations, including background file deletion at IO idle (see :ref:`test-manual/understand-autobuilder:Autobuilder Target Execution Overview`: Run clobberdir) and
maintainenance of a cache of cloned repositories to improve the speed
the system can checkout repositories.
@@ -243,7 +243,7 @@ of post-build steps, including:
generated to the remote server.
#. Cleanup the build directory using
- :ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful,
+ :ref:`test-manual/understand-autobuilder:clobberdir` if the build was successful,
else rename it to "build-renamed" for potential future debugging.
Deploying Yocto Autobuilder
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 04/10] toaster-manual: remove 'toaster-manual' from filenames
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
` (2 preceding siblings ...)
2020-12-03 21:38 ` [PATCH 03/10] test-manual: remove 'test-manual' from filenames Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 05/10] dev-manual: remove 'dev-manual' " Nicolas Dechesne
` (5 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
All filenames duplicate the 'manual name', which is not needed, and
make all references longer than they should. Rename all files to be as
consise as possible, and fix all references
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
documentation/dev-manual/dev-manual-start.rst | 6 +++---
documentation/ref-manual/migration-2.1.rst | 2 +-
documentation/toaster-manual/index.rst | 8 ++++----
.../{toaster-manual-intro.rst => intro.rst} | 2 +-
.../{toaster-manual-reference.rst => reference.rst} | 8 ++++----
...ster-manual-setup-and-use.rst => setup-and-use.rst} | 10 +++++-----
.../{toaster-manual-start.rst => start.rst} | 0
7 files changed, 18 insertions(+), 18 deletions(-)
rename documentation/toaster-manual/{toaster-manual-intro.rst => intro.rst} (97%)
rename documentation/toaster-manual/{toaster-manual-reference.rst => reference.rst} (98%)
rename documentation/toaster-manual/{toaster-manual-setup-and-use.rst => setup-and-use.rst} (98%)
rename documentation/toaster-manual/{toaster-manual-start.rst => start.rst} (100%)
diff --git a/documentation/dev-manual/dev-manual-start.rst b/documentation/dev-manual/dev-manual-start.rst
index d4727a6f6..75b5d7b5f 100644
--- a/documentation/dev-manual/dev-manual-start.rst
+++ b/documentation/dev-manual/dev-manual-start.rst
@@ -345,7 +345,7 @@ section. If you are going
to use the Extensible SDK, see the ":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`/kernel-dev/index`. If you are going to use
-Toaster, see the ":doc:`/toaster-manual/toaster-manual-setup-and-use`"
+Toaster, see the ":doc:`/toaster-manual/setup-and-use`"
section in the Toaster User Manual.
Setting Up to Use CROss PlatformS (CROPS)
@@ -445,7 +445,7 @@ section. If you are going to use the Extensible SDK container, see the
":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`/toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/setup-and-use`"
section in the Toaster User Manual.
Setting Up to Use Windows Subsystem For Linux (WSLv2)
@@ -560,7 +560,7 @@ you were running on a native Linux machine. If you are going to use the
Extensible SDK container, see the ":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you are going to use the Toaster container, see
-the ":doc:`/toaster-manual/toaster-manual-setup-and-use`"
+the ":doc:`/toaster-manual/setup-and-use`"
section in the Toaster User Manual.
Locating Yocto Project Source Files
diff --git a/documentation/ref-manual/migration-2.1.rst b/documentation/ref-manual/migration-2.1.rst
index 25ee21499..ada9d2986 100644
--- a/documentation/ref-manual/migration-2.1.rst
+++ b/documentation/ref-manual/migration-2.1.rst
@@ -217,7 +217,7 @@ The following changes have been made to the build system user interface:
- *Hob GTK+-based UI*: Removed because it is unmaintained and based on
the outdated GTK+ 2 library. The Toaster web-based UI is much more
capable and is actively maintained. See the
- ":ref:`toaster-manual/toaster-manual-setup-and-use:using the toaster web interface`"
+ ":ref:`toaster-manual/setup-and-use:using the toaster web interface`"
section in the Toaster User Manual for more information on this
interface.
diff --git a/documentation/toaster-manual/index.rst b/documentation/toaster-manual/index.rst
index b003f1cea..f13ba7b8a 100644
--- a/documentation/toaster-manual/index.rst
+++ b/documentation/toaster-manual/index.rst
@@ -10,10 +10,10 @@ Toaster User Manual
:caption: Table of Contents
:numbered:
- toaster-manual-intro
- toaster-manual-start
- toaster-manual-setup-and-use
- toaster-manual-reference
+ intro
+ start
+ setup-and-use
+ reference
history
.. include:: /boilerplate.rst
diff --git a/documentation/toaster-manual/toaster-manual-intro.rst b/documentation/toaster-manual/intro.rst
similarity index 97%
rename from documentation/toaster-manual/toaster-manual-intro.rst
rename to documentation/toaster-manual/intro.rst
index e34e7bac4..c78b3f53d 100644
--- a/documentation/toaster-manual/toaster-manual-intro.rst
+++ b/documentation/toaster-manual/intro.rst
@@ -25,7 +25,7 @@ extensive information about the build process.
interface, you can:
- Browse layers listed in the various
- :ref:`layer sources <toaster-manual/toaster-manual-reference:layer source>`
+ :ref:`layer sources <toaster-manual/reference:layer source>`
that are available in your project (e.g. the OpenEmbedded Layer Index at
http://layers.openembedded.org/layerindex/).
diff --git a/documentation/toaster-manual/toaster-manual-reference.rst b/documentation/toaster-manual/reference.rst
similarity index 98%
rename from documentation/toaster-manual/toaster-manual-reference.rst
rename to documentation/toaster-manual/reference.rst
index ed0bad11b..c3f0fef0a 100644
--- a/documentation/toaster-manual/toaster-manual-reference.rst
+++ b/documentation/toaster-manual/reference.rst
@@ -476,7 +476,7 @@ get the status of a specific build, use the following call::
Be sure to provide values for
host, port, and ID. You can find the value for ID from the Builds
-Completed query. See the ":ref:`toaster-manual/toaster-manual-reference:checking status of builds completed`"
+Completed query. See the ":ref:`toaster-manual/reference:checking status of builds completed`"
section for more information.
The output is a JSON file that itemizes the specific build and includes
@@ -549,7 +549,7 @@ database.
You need to run the ``buildslist`` command first to identify existing
builds in the database before using the
-:ref:`toaster-manual/toaster-manual-reference:\`\`builddelete\`\`` command. Here is an
+:ref:`toaster-manual/reference:\`\`builddelete\`\`` command. Here is an
example that assumes default repository and build directory names:
.. code-block:: shell
@@ -558,7 +558,7 @@ example that assumes default repository and build directory names:
$ python ../bitbake/lib/toaster/manage.py buildslist
If your Toaster database had only one build, the above
-:ref:`toaster-manual/toaster-manual-reference:\`\`buildslist\`\``
+:ref:`toaster-manual/reference:\`\`buildslist\`\``
command would return something like the following::
1: qemux86 poky core-image-minimal
@@ -579,7 +579,7 @@ the database.
Prior to running the ``builddelete`` command, you need to get the ID
associated with builds by using the
-:ref:`toaster-manual/toaster-manual-reference:\`\`buildslist\`\`` command.
+:ref:`toaster-manual/reference:\`\`buildslist\`\`` command.
``perf``
--------
diff --git a/documentation/toaster-manual/toaster-manual-setup-and-use.rst b/documentation/toaster-manual/setup-and-use.rst
similarity index 98%
rename from documentation/toaster-manual/toaster-manual-setup-and-use.rst
rename to documentation/toaster-manual/setup-and-use.rst
index 6e2ba0253..2cb7884eb 100644
--- a/documentation/toaster-manual/toaster-manual-setup-and-use.rst
+++ b/documentation/toaster-manual/setup-and-use.rst
@@ -10,7 +10,7 @@ Starting Toaster for Local Development
======================================
Once you have set up the Yocto Project and installed the Toaster system
-dependencies as described in the ":ref:`toaster-manual/toaster-manual-start:Preparing to Use
+dependencies as described in the ":ref:`toaster-manual/start:Preparing to Use
Toaster`" chapter, you are ready to start
Toaster.
@@ -30,7 +30,7 @@ Next, from the build directory (e.g.
You can now run your builds from the command line, or with Toaster
as explained in section
-":ref:`toaster-manual/toaster-manual-setup-and-use:using the toaster web interface`".
+":ref:`toaster-manual/setup-and-use:using the toaster web interface`".
To access the Toaster web interface, open your favorite browser and
enter the following::
@@ -200,7 +200,7 @@ Be sure you meet the following requirements:
You must comply with all Apache, ``mod-wsgi``, and Mysql requirements.
-- Have all the build requirements as described in the ":ref:`toaster-manual/toaster-manual-start:Preparing to
+- Have all the build requirements as described in the ":ref:`toaster-manual/start:Preparing to
Use Toaster`" chapter.
- Have an Apache webserver.
@@ -314,7 +314,7 @@ Perform the following steps to install Toaster:
``TEMPLATECONF`` value reflects the contents of
``poky/.templateconf``, and by default, should include the string
"poky". For more information on the Toaster configuration file, see
- the ":ref:`toaster-manual/toaster-manual-reference:Configuring Toaster`" section.
+ the ":ref:`toaster-manual/reference:Configuring Toaster`" section.
This line also runs the ``checksettings`` command, which configures
the location of the Toaster :term:`Build Directory`.
@@ -544,7 +544,7 @@ Additional Information About the Local Yocto Project Release
This section only applies if you have set up Toaster for local
development, as explained in the
-":ref:`toaster-manual/toaster-manual-setup-and-use:starting toaster for local development`"
+":ref:`toaster-manual/setup-and-use:starting toaster for local development`"
section.
When you create a project in Toaster, you will be asked to provide a
diff --git a/documentation/toaster-manual/toaster-manual-start.rst b/documentation/toaster-manual/start.rst
similarity index 100%
rename from documentation/toaster-manual/toaster-manual-start.rst
rename to documentation/toaster-manual/start.rst
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 05/10] dev-manual: remove 'dev-manual' from filenames
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
` (3 preceding siblings ...)
2020-12-03 21:38 ` [PATCH 04/10] toaster-manual: remove 'toaster-manual' " Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 06/10] kernel-dev: remove 'kernel-dev' " Nicolas Dechesne
` (4 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
All filenames duplicate the 'manual name', which is not needed, and
make all references longer than they should. Rename all files to be as
consise as possible, and fix all references
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
documentation/brief-yoctoprojectqs/index.rst | 14 +--
documentation/bsp-guide/bsp.rst | 36 +++---
...nual-common-tasks.rst => common-tasks.rst} | 54 ++++-----
documentation/dev-manual/index.rst | 8 +-
.../{dev-manual-intro.rst => intro.rst} | 0
.../{dev-manual-qemu.rst => qemu.rst} | 0
.../{dev-manual-start.rst => start.rst} | 20 ++--
.../kernel-dev/kernel-dev-common.rst | 26 ++---
documentation/kernel-dev/kernel-dev-faq.rst | 2 +-
documentation/kernel-dev/kernel-dev-intro.rst | 4 +-
.../overview-manual-concepts.rst | 20 ++--
...verview-manual-development-environment.rst | 26 ++---
.../overview-manual-yp-intro.rst | 16 +--
documentation/ref-manual/faq.rst | 6 +-
documentation/ref-manual/migration-1.4.rst | 2 +-
documentation/ref-manual/migration-1.5.rst | 4 +-
documentation/ref-manual/migration-1.6.rst | 6 +-
documentation/ref-manual/migration-1.7.rst | 2 +-
documentation/ref-manual/migration-2.1.rst | 2 +-
documentation/ref-manual/migration-2.3.rst | 2 +-
documentation/ref-manual/migration-2.5.rst | 2 +-
documentation/ref-manual/migration-2.6.rst | 2 +-
documentation/ref-manual/ref-classes.rst | 34 +++---
.../ref-manual/ref-devtool-reference.rst | 4 +-
documentation/ref-manual/ref-features.rst | 6 +-
documentation/ref-manual/ref-images.rst | 4 +-
documentation/ref-manual/ref-kickstart.rst | 2 +-
.../ref-manual/ref-release-process.rst | 6 +-
documentation/ref-manual/ref-structure.rst | 14 +--
.../ref-manual/ref-system-requirements.rst | 2 +-
documentation/ref-manual/ref-tasks.rst | 10 +-
documentation/ref-manual/ref-terms.rst | 4 +-
documentation/ref-manual/ref-variables.rst | 104 +++++++++---------
documentation/ref-manual/resources.rst | 4 +-
.../sdk-manual/sdk-appendix-obtain.rst | 8 +-
documentation/sdk-manual/sdk-intro.rst | 2 +-
documentation/test-manual/intro.rst | 2 +-
documentation/toaster-manual/reference.rst | 2 +-
documentation/toaster-manual/start.rst | 2 +-
.../transitioning-to-a-custom-environment.rst | 8 +-
documentation/what-i-wish-id-known.rst | 2 +-
41 files changed, 237 insertions(+), 237 deletions(-)
rename documentation/dev-manual/{dev-manual-common-tasks.rst => common-tasks.rst} (99%)
rename documentation/dev-manual/{dev-manual-intro.rst => intro.rst} (100%)
rename documentation/dev-manual/{dev-manual-qemu.rst => qemu.rst} (100%)
rename documentation/dev-manual/{dev-manual-start.rst => start.rst} (97%)
diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst
index c1b78d0f5..51f684af0 100644
--- a/documentation/brief-yoctoprojectqs/index.rst
+++ b/documentation/brief-yoctoprojectqs/index.rst
@@ -20,7 +20,7 @@ build a reference embedded OS called Poky.
(:term:`Build Host`) is not
a native Linux system, you can still perform these steps by using
CROss PlatformS (CROPS) and setting up a Poky container. See the
- :ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`
+ :ref:`dev-manual/start:setting up to use cross platforms (crops)`
section
in the Yocto Project Development Tasks Manual for more
information.
@@ -34,7 +34,7 @@ build a reference embedded OS called Poky.
compatible but not officially supported nor validated with
WSLv2, if you still decide to use WSL please upgrade to WSLv2.
- See the :ref:`dev-manual/dev-manual-start:setting up to use windows
+ See the :ref:`dev-manual/start:setting up to use windows
subsystem for linux (wslv2)` section in the Yocto Project Development
Tasks Manual for more information.
@@ -55,7 +55,7 @@ following requirements:
:ref:`ref-manual/ref-system-requirements:supported linux distributions`
section in the Yocto Project Reference Manual. For detailed
information on preparing your build host, see the
- :ref:`dev-manual/dev-manual-start:preparing the build host`
+ :ref:`dev-manual/start:preparing the build host`
section in the Yocto Project Development Tasks Manual.
-
@@ -145,7 +145,7 @@ branch at the time of the Yocto Project &DISTRO_REL_TAG; release.
For more options and information about accessing Yocto Project related
repositories, see the
-:ref:`dev-manual/dev-manual-start:locating yocto project source files`
+:ref:`dev-manual/start:locating yocto project source files`
section in the Yocto Project Development Tasks Manual.
Building Your Image
@@ -257,7 +257,7 @@ an entire Linux distribution, including the toolchain, from source.
$ runqemu qemux86-64
If you want to learn more about running QEMU, see the
- :ref:`dev-manual/dev-manual-qemu:using the quick emulator (qemu)` chapter in
+ :ref:`dev-manual/qemu:using the quick emulator (qemu)` chapter in
the Yocto Project Development Tasks Manual.
#. **Exit QEMU:** Exit QEMU by either clicking on the shutdown icon or by typing
@@ -346,7 +346,7 @@ Follow these steps to add a hardware layer:
You can find
more information on adding layers in the
- :ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`
+ :ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`
section.
Completing these steps has added the ``meta-altera`` layer to your Yocto
@@ -381,7 +381,7 @@ The following commands run the tool to create a layer named
For more information
on layers and how to create them, see the
-:ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`
+:ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`
section in the Yocto Project Development Tasks Manual.
Where To Go Next
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 357e740a5..6d3ccd49b 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -72,7 +72,7 @@ For information on typical BSP development workflow, see the
section. For more
information on how to set up a local copy of source files from a Git
repository, see the
-:ref:`dev-manual/dev-manual-start:locating yocto project source files`
+:ref:`dev-manual/start:locating yocto project source files`
section in the Yocto Project Development Tasks Manual.
The BSP layer's base directory (``meta-bsp_root_name``) is the root
@@ -128,7 +128,7 @@ you want to work with, such as: ::
and so on.
For more information on layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
section of the Yocto Project Development Tasks Manual.
Preparing Your Build Host to Work With BSP Layers
@@ -146,7 +146,7 @@ section.
:ref:`bsp-guide/bsp:example filesystem layout` section.
#. *Set Up the Build Environment:* Be sure you are set up to use BitBake
- in a shell. See the ":ref:`dev-manual/dev-manual-start:preparing the build host`"
+ in a shell. See the ":ref:`dev-manual/start:preparing the build host`"
section in the Yocto Project Development Tasks Manual for information on how
to get a build host ready that is either a native Linux machine or a machine
that uses CROPS.
@@ -154,10 +154,10 @@ section.
#. *Clone the poky Repository:* You need to have a local copy of the
Yocto Project :term:`Source Directory` (i.e. a local
``poky`` repository). See the
- ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" and
+ ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and
possibly the
- ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" or
- ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`"
+ ":ref:`dev-manual/start:checking out by branch in poky`" or
+ ":ref:`dev-manual/start:checking out by tag in poky`"
sections
all in the Yocto Project Development Tasks Manual for information on
how to clone the ``poky`` repository and check out the appropriate
@@ -205,7 +205,7 @@ section.
To see the available branch names in a cloned repository, use the ``git
branch -al`` command. See the
- ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`"
+ ":ref:`dev-manual/start:checking out by branch in poky`"
section in the Yocto Project Development Tasks Manual for more
information.
@@ -463,7 +463,7 @@ requirements are handled with the ``COPYING.MIT`` file.
Licensing files can be MIT, BSD, GPLv*, and so forth. These files are
recommended for the BSP but are optional and totally up to the BSP
developer. For information on how to maintain license compliance, see
-the ":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+the ":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
section in the Yocto Project Development Tasks Manual.
README File
@@ -589,7 +589,7 @@ filenames correspond to the values to which users have set the
These files define things such as the kernel package to use
(:term:`PREFERRED_PROVIDER` of
-:ref:`virtual/kernel <dev-manual/dev-manual-common-tasks:using virtual providers>`),
+:ref:`virtual/kernel <dev-manual/common-tasks:using virtual providers>`),
the hardware drivers to include in different types of images, any
special software components that are needed, any bootloader information,
and also any special image format requirements.
@@ -726,7 +726,7 @@ workflow.
:align: center
#. *Set up Your Host Development System to Support Development Using the
- Yocto Project*: See the ":ref:`dev-manual/dev-manual-start:preparing the build host`"
+ Yocto Project*: See the ":ref:`dev-manual/start:preparing the build host`"
section in the Yocto Project Development Tasks Manual for options on how to
get a system ready to use the Yocto Project.
@@ -756,7 +756,7 @@ workflow.
OpenEmbedded build system knows about. For more information on
layers, see the ":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
section in the Yocto Project Overview and Concepts Manual. You can also
- reference the ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+ reference the ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual. For more
information on BSP layers, see the ":ref:`bsp-guide/bsp:bsp layers`"
section.
@@ -815,7 +815,7 @@ workflow.
key configuration files are configured appropriately: the
``conf/local.conf`` and the ``conf/bblayers.conf`` file. You must
make the OpenEmbedded build system aware of your new layer. See the
- ":ref:`dev-manual/dev-manual-common-tasks:enabling your layer`"
+ ":ref:`dev-manual/common-tasks:enabling your layer`"
section in the Yocto Project Development Tasks Manual for information
on how to let the build system know about your new layer.
@@ -846,7 +846,7 @@ Before looking at BSP requirements, you should consider the following:
layer that can be added to the Yocto Project. For guidelines on
creating a layer that meets these base requirements, see the
":ref:`bsp-guide/bsp:bsp layers`" section in this manual and the
- ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+ ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual.
- The requirements in this section apply regardless of how you package
@@ -928,7 +928,7 @@ Yocto Project:
- The name and contact information for the BSP layer maintainer.
This is the person to whom patches and questions should be sent.
For information on how to find the right person, see the
- ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+ ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section in the Yocto Project Development Tasks Manual.
- Instructions on how to build the BSP using the BSP layer.
@@ -1013,7 +1013,7 @@ If you plan on customizing a recipe for a particular BSP, you need to do
the following:
- Create a ``*.bbappend`` file for the modified recipe. For information on using
- append files, see the ":ref:`dev-manual/dev-manual-common-tasks:using
+ append files, see the ":ref:`dev-manual/common-tasks:using
.bbappend files in your layer`" section in the Yocto Project Development
Tasks Manual.
@@ -1118,7 +1118,7 @@ list describes them in order of preference:
Specifying the matching license string signifies that you agree to
the license. Thus, the build system can build the corresponding
recipe and include the component in the image. See the
- ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
+ ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
section in the Yocto Project Development Tasks Manual for details on
how to use these variables.
@@ -1170,7 +1170,7 @@ Use these steps to create a BSP layer:
``create-layer`` subcommand to create a new general layer. For
instructions on how to create a general layer using the
``bitbake-layers`` script, see the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+ ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
section in the Yocto Project Development Tasks Manual.
- *Create a Layer Configuration File:* Every layer needs a layer
@@ -1230,7 +1230,7 @@ configuration files is to examine various files for BSP from the
:yocto_git:`Source Repositories <>`.
For a detailed description of this particular layer configuration file,
-see ":ref:`step 3 <dev-manual/dev-manual-common-tasks:creating your own layer>`"
+see ":ref:`step 3 <dev-manual/common-tasks:creating your own layer>`"
in the discussion that describes how to create layers in the Yocto
Project Development Tasks Manual.
diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/common-tasks.rst
similarity index 99%
rename from documentation/dev-manual/dev-manual-common-tasks.rst
rename to documentation/dev-manual/common-tasks.rst
index 0a2e6d9df..c627491f3 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -31,7 +31,7 @@ layers so that you can better understand them. For information about the
layer-creation tools, see the
":ref:`bsp-guide/bsp:creating a new bsp layer using the \`\`bitbake-layers\`\` script`"
section in the Yocto Project Board Support Package (BSP) Developer's
-Guide and the ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+Guide and the ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
section further down in this manual.
Follow these general steps to create your layer without using tools:
@@ -725,7 +725,7 @@ simplifies creating a new general layer.
- In order to use a layer with the OpenEmbedded build system, you
need to add the layer to your ``bblayers.conf`` configuration
- file. See the ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
+ file. See the ":ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
section for more information.
The default mode of the script's operation with this subcommand is to
@@ -1106,7 +1106,7 @@ that can help you quickly get a start on a new recipe:
.. note::
For information on recipe syntax, see the
- ":ref:`dev-manual/dev-manual-common-tasks:recipe syntax`" section.
+ ":ref:`dev-manual/common-tasks:recipe syntax`" section.
Creating the Base Recipe Using ``devtool add``
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1538,7 +1538,7 @@ variables:
differences result in an error with the message containing the
current checksum. For more explanation and examples of how to set the
``LIC_FILES_CHKSUM`` variable, see the
- ":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section.
+ ":ref:`dev-manual/common-tasks:tracking license changes`" section.
To determine the correct checksum string, you can list the
appropriate files in the ``LIC_FILES_CHKSUM`` variable with incorrect
@@ -1771,7 +1771,7 @@ Here are some common issues that cause failures.
For cases where improper paths are detected for configuration files
or for when libraries/headers cannot be found, be sure you are using
the more robust ``pkg-config``. See the note in section
- ":ref:`dev-manual/dev-manual-common-tasks:Configuring the Recipe`" for additional information.
+ ":ref:`dev-manual/common-tasks:Configuring the Recipe`" for additional information.
- *Parallel build failures:* These failures manifest themselves as
intermittent errors, or errors reporting that a file or directory
@@ -2338,7 +2338,7 @@ Following is one example: (``hello_2.3.bb``)
The variable ``LIC_FILES_CHKSUM`` is used to track source license
changes as described in the
-":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`" section in
+":ref:`dev-manual/common-tasks:tracking license changes`" section in
the Yocto Project Overview and Concepts Manual. You can quickly create
Autotool-based recipes in a manner similar to the previous example.
@@ -2963,7 +2963,7 @@ The following steps describe how to set up the AUH utility:
1. *Be Sure the Development Host is Set Up:* You need to be sure that
your development host is set up to use the Yocto Project. For
information on how to set up your host, see the
- ":ref:`dev-manual/dev-manual-start:Preparing the Build Host`" section.
+ ":ref:`dev-manual/start:Preparing the Build Host`" section.
2. *Make Sure Git is Configured:* The AUH utility requires Git to be
configured because AUH uses Git to save upgrades. Thus, you must have
@@ -3015,7 +3015,7 @@ The following steps describe how to set up the AUH utility:
configurations:
- If you want to enable :ref:`Build
- History <dev-manual/dev-manual-common-tasks:maintaining build output quality>`,
+ History <dev-manual/common-tasks:maintaining build output quality>`,
which is optional, you need the following lines in the
``conf/local.conf`` file:
::
@@ -3267,8 +3267,8 @@ Manually Upgrading a Recipe
---------------------------
If for some reason you choose not to upgrade recipes using
-:ref:`dev-manual/dev-manual-common-tasks:Using the Auto Upgrade Helper (AUH)` or
-by :ref:`dev-manual/dev-manual-common-tasks:Using \`\`devtool upgrade\`\``,
+:ref:`dev-manual/common-tasks:Using the Auto Upgrade Helper (AUH)` or
+by :ref:`dev-manual/common-tasks:Using \`\`devtool upgrade\`\``,
you can manually edit the recipe files to upgrade the versions.
.. note::
@@ -3467,7 +3467,7 @@ Follow these general steps:
(i.e. ``bitbake -c clean package`` and ``bitbake -c cleanall package``).
Modifications will also disappear if you use the ``rm_work`` feature as
described in the
- ":ref:`dev-manual/dev-manual-common-tasks:conserving disk space during builds`"
+ ":ref:`dev-manual/common-tasks:conserving disk space during builds`"
section.
7. *Generate the Patch:* Once your changes work as expected, you need to
@@ -3667,7 +3667,7 @@ The following figure and list overviews the build process:
:align: center
1. *Set up Your Host Development System to Support Development Using the
- Yocto Project*: See the ":doc:`dev-manual-start`" section for options on how to get a
+ Yocto Project*: See the ":doc:`start`" section for options on how to get a
build host ready to use the Yocto Project.
2. *Initialize the Build Environment:* Initialize the build environment
@@ -4046,7 +4046,7 @@ your own distribution that are likely modeled after ``poky-tiny``.
To use ``poky-tiny`` in your build, set the ``DISTRO`` variable in your
``local.conf`` file to "poky-tiny" as described in the
- ":ref:`dev-manual/dev-manual-common-tasks:creating your own distribution`"
+ ":ref:`dev-manual/common-tasks:creating your own distribution`"
section.
Understanding some memory concepts will help you reduce the system size.
@@ -5736,7 +5736,7 @@ or ::
For more information on how to use the ``bmaptool``
to flash a device with an image, see the
- ":ref:`dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\``"
+ ":ref:`dev-manual/common-tasks:flashing images using \`\`bmaptool\`\``"
section.
Using a Modified Kickstart File
@@ -5956,7 +5956,7 @@ the existing kernel, and then inserts a new kernel:
Once the new kernel is added back into the image, you can use the
``dd`` command or :ref:`bmaptool
- <dev-manual/dev-manual-common-tasks:flashing images using \`\`bmaptool\`\`>`
+ <dev-manual/common-tasks:flashing images using \`\`bmaptool\`\`>`
to flash your wic image onto an SD card or USB stick and test your
target.
@@ -6202,7 +6202,7 @@ layer. The following steps provide some more detail:
just placing configurations in a ``local.conf`` configuration file
makes it easier to reproduce the same build configuration when using
multiple build machines. See the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+ ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
section for information on how to quickly set up a layer.
- *Create the distribution configuration file:* The distribution
@@ -7979,7 +7979,7 @@ associated ``EXTRA_IMAGE_FEATURES`` variable, as in:
EXTRA_IMAGE_FEATURES = "read-only-rootfs"
For more information on how to use these variables, see the
-":ref:`dev-manual/dev-manual-common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA_IMAGE_FEATURES\`\``"
+":ref:`dev-manual/common-tasks:Customizing Images Using Custom \`\`IMAGE_FEATURES\`\` and \`\`EXTRA_IMAGE_FEATURES\`\``"
section. For information on the variables, see
:term:`IMAGE_FEATURES` and
:term:`EXTRA_IMAGE_FEATURES`.
@@ -8056,13 +8056,13 @@ the information.
The remainder of this section describes the following:
-- :ref:`How you can enable and disable build history <dev-manual/dev-manual-common-tasks:enabling and disabling build history>`
+- :ref:`How you can enable and disable build history <dev-manual/common-tasks:enabling and disabling build history>`
-- :ref:`How to understand what the build history contains <dev-manual/dev-manual-common-tasks:understanding what the build history contains>`
+- :ref:`How to understand what the build history contains <dev-manual/common-tasks:understanding what the build history contains>`
-- :ref:`How to limit the information used for build history <dev-manual/dev-manual-common-tasks:using build history to gather image information only>`
+- :ref:`How to limit the information used for build history <dev-manual/common-tasks:using build history to gather image information only>`
-- :ref:`How to examine the build history from both a command-line and web interface <dev-manual/dev-manual-common-tasks:examining build history information>`
+- :ref:`How to examine the build history from both a command-line and web interface <dev-manual/common-tasks:examining build history information>`
Enabling and Disabling Build History
------------------------------------
@@ -9084,7 +9084,7 @@ situations.
completes to log error information into a common database, that can
help you figure out what might be going wrong. For information on how
to enable and use this feature, see the
- ":ref:`dev-manual/dev-manual-common-tasks:using the error reporting tool`"
+ ":ref:`dev-manual/common-tasks:using the error reporting tool`"
section.
The following list shows the debugging topics in the remainder of this
@@ -9100,7 +9100,7 @@ section:
use the BitBake ``-e`` option to examine variable values after a
recipe has been parsed.
-- ":ref:`dev-manual/dev-manual-common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
+- ":ref:`dev-manual/common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
describes how to use the ``oe-pkgdata-util`` utility to query
:term:`PKGDATA_DIR` and
display package-related information for built packages.
@@ -10581,7 +10581,7 @@ Yocto Project Reference Manual.
Here is the general procedure on how to submit a patch through email
without using the scripts once the steps in
-:ref:`dev-manual/dev-manual-common-tasks:preparing changes for submission` have been followed:
+:ref:`dev-manual/common-tasks:preparing changes for submission` have been followed:
1. *Format the Commit:* Format the commit into an email message. To
format commits, use the ``git format-patch`` command. When you
@@ -10670,7 +10670,7 @@ and ``send-pull-request`` scripts from openembedded-core to create and send a
patch series with a link to the branch for review.
Follow this procedure to push a change to an upstream "contrib" Git
-repository once the steps in :ref:`dev-manual/dev-manual-common-tasks:preparing changes for submission` have
+repository once the steps in :ref:`dev-manual/common-tasks:preparing changes for submission` have
been followed:
.. note::
@@ -10845,8 +10845,8 @@ follows:
a newer version of the software which includes an upstream fix for the
issue or when the issue has been fixed on the master branch in a way
that introduces backwards incompatible changes. In this case follow the
- steps in :ref:`dev-manual/dev-manual-common-tasks:preparing changes for submission` and
- :ref:`dev-manual/dev-manual-common-tasks:using email to submit a patch` but modify the subject header of your patch
+ steps in :ref:`dev-manual/common-tasks:preparing changes for submission` and
+ :ref:`dev-manual/common-tasks:using email to submit a patch` but modify the subject header of your patch
email to include the name of the stable branch which you are
targetting. This can be done using the ``--subject-prefix`` argument to
``git format-patch``, for example to submit a patch to the dunfell
diff --git a/documentation/dev-manual/index.rst b/documentation/dev-manual/index.rst
index 8f09224fe..941db2df8 100644
--- a/documentation/dev-manual/index.rst
+++ b/documentation/dev-manual/index.rst
@@ -10,10 +10,10 @@ Yocto Project Development Tasks Manual
:caption: Table of Contents
:numbered:
- dev-manual-intro
- dev-manual-start
- dev-manual-common-tasks
- dev-manual-qemu
+ intro
+ start
+ common-tasks
+ qemu
history
.. include:: /boilerplate.rst
diff --git a/documentation/dev-manual/dev-manual-intro.rst b/documentation/dev-manual/intro.rst
similarity index 100%
rename from documentation/dev-manual/dev-manual-intro.rst
rename to documentation/dev-manual/intro.rst
diff --git a/documentation/dev-manual/dev-manual-qemu.rst b/documentation/dev-manual/qemu.rst
similarity index 100%
rename from documentation/dev-manual/dev-manual-qemu.rst
rename to documentation/dev-manual/qemu.rst
diff --git a/documentation/dev-manual/dev-manual-start.rst b/documentation/dev-manual/start.rst
similarity index 97%
rename from documentation/dev-manual/dev-manual-start.rst
rename to documentation/dev-manual/start.rst
index 75b5d7b5f..85ec97b9e 100644
--- a/documentation/dev-manual/dev-manual-start.rst
+++ b/documentation/dev-manual/start.rst
@@ -7,7 +7,7 @@ Setting Up to Use the Yocto Project
This chapter provides guidance on how to prepare to use the Yocto
Project. You can learn about creating a team environment to develop
using the Yocto Project, how to set up a :ref:`build
-host <dev-manual/dev-manual-start:preparing the build host>`, how to locate
+host <dev-manual/start:preparing the build host>`, how to locate
Yocto Project source repositories, and how to create local Git
repositories.
@@ -224,7 +224,7 @@ particular working environment and set of practices.
- Maintain your Metadata in layers that make sense for your
situation. See the ":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
section in the Yocto Project Overview and Concepts Manual and the
- ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+ ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section for more information on layers.
- Separate the project's Metadata and code by using separate Git
@@ -248,13 +248,13 @@ particular working environment and set of practices.
project to fix bugs or add features. If you do submit patches,
follow the project commit guidelines for writing good commit
messages. See the
- ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+ ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section.
- Send changes to the core sooner than later as others are likely
to run into the same issues. For some guidance on mailing lists
to use, see the list in the
- ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+ ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section. For a description
of the available mailing lists, see the ":ref:`resources-mailinglist`" section in
the Yocto Project Reference Manual.
@@ -340,7 +340,7 @@ Project Build Host:
Once you have completed the previous steps, you are ready to continue
using a given development path on your native Linux machine. If you are
going to use BitBake, see the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section. If you are going
to use the Extensible SDK, see the ":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
@@ -440,7 +440,7 @@ as your Yocto Project build host:
Once you have a container set up, everything is in place to develop just
as if you were running on a native Linux machine. If you are going to
use the Poky container, see the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section. If you are going to use the Extensible SDK container, see the
":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
@@ -582,7 +582,7 @@ files you'll need to work with the Yocto Project.
Accessing Source Repositories
-----------------------------
-Working from a copy of the upstream :ref:`dev-manual/dev-manual-start:accessing source repositories` is the
+Working from a copy of the upstream :ref:`dev-manual/start:accessing source repositories` is the
preferred method for obtaining and using a Yocto Project release. You
can view the Yocto Project Source Repositories at
:yocto_git:`/`. In particular, you can find the ``poky``
@@ -605,7 +605,7 @@ Use the following procedure to locate the latest upstream copy of the
.. note::
For information on cloning a repository, see the
- ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" section.
+ ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" section.
Accessing Index of Releases
---------------------------
@@ -801,7 +801,7 @@ and then specifically check out that development branch.
1. *Switch to the Poky Directory:* If you have a local poky Git
repository, switch to that directory. If you do not have the local
copy of poky, see the
- ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+ ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section.
2. *Determine Existing Branch Names:*
@@ -864,7 +864,7 @@ similar to checking out by branch name except you use tag names.
1. *Switch to the Poky Directory:* If you have a local poky Git
repository, switch to that directory. If you do not have the local
copy of poky, see the
- ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+ ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section.
2. *Fetch the Tag Names:* To checkout the branch based on a tag name,
diff --git a/documentation/kernel-dev/kernel-dev-common.rst b/documentation/kernel-dev/kernel-dev-common.rst
index 8e9bc27bf..4bb553f8d 100644
--- a/documentation/kernel-dev/kernel-dev-common.rst
+++ b/documentation/kernel-dev/kernel-dev-common.rst
@@ -21,11 +21,11 @@ Preparing the Build Host to Work on the Kernel
Before you can do any kernel development, you need to be sure your build
host is set up to use the Yocto Project. For information on how to get
-set up, see the ":doc:`/dev-manual/dev-manual-start`" section in
+set up, see the ":doc:`/dev-manual/start`" section in
the Yocto Project Development Tasks Manual. Part of preparing the system
is creating a local Git repository of the
:term:`Source Directory` (``poky``) on your system. Follow the steps in the
-":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`"
+":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section in the Yocto Project Development Tasks Manual to set up your
Source Directory.
@@ -34,8 +34,8 @@ Source Directory.
Be sure you check out the appropriate development branch or you
create your local branch by checking out a specific tag to get the
desired version of Yocto Project. See the
- ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" and
- ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`"
+ ":ref:`dev-manual/start:checking out by branch in poky`" and
+ ":ref:`dev-manual/start:checking out by tag in poky`"
sections in the Yocto Project Development Tasks Manual for more information.
Kernel development is best accomplished using
@@ -104,13 +104,13 @@ section:
For background information on working with common and BSP layers,
see the
- ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+ ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual and the
":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto Project Board
Support (BSP) Developer's Guide, respectively. For information on how to
use the ``bitbake-layers create-layer`` command to quickly set up a layer,
see the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+ ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
section in the Yocto Project Development Tasks Manual.
4. *Inform the BitBake Build Environment About Your Layer:* As directed
@@ -236,7 +236,7 @@ section:
Also, for this example, be sure that the local branch you have
checked out for ``poky`` is the Yocto Project &DISTRO_NAME; branch. If
you need to checkout out the &DISTRO_NAME; branch, see the
- ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`"
+ ":ref:`dev-manual/start:checking out by branch in poky`"
section in the Yocto Project Development Tasks Manual.
::
@@ -289,13 +289,13 @@ section:
For background information on working with common and BSP layers,
see the
- ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+ ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual and the
":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto Project Board
Support (BSP) Developer's Guide, respectively. For information on how to
use the ``bitbake-layers create-layer`` command to quickly set up a layer,
see the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+ ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
section in the Yocto Project Development Tasks Manual.
4. *Inform the BitBake Build Environment About Your Layer:* As directed
@@ -378,7 +378,7 @@ layer contains its own :term:`BitBake`
append files (``.bbappend``) and provides a convenient mechanism to
create your own recipe files (``.bb``) as well as store and use kernel
patch files. For background information on working with layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual.
.. note::
@@ -386,7 +386,7 @@ section in the Yocto Project Development Tasks Manual.
The Yocto Project comes with many tools that simplify tasks you need
to perform. One such tool is the ``bitbake-layers create-layer``
command, which simplifies creating a new layer. See the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+ ":ref:`dev-manual/common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
section in the Yocto Project Development Tasks Manual for
information on how to use this script to quick set up a new layer.
@@ -443,7 +443,7 @@ home directory:
The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
enable the OpenEmbedded build system to find patch files. For more
information on using append files, see the
- ":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+ ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
section in the Yocto Project Development Tasks Manual.
Modifying an Existing Recipe
@@ -1108,7 +1108,7 @@ Section.
For more information on append files and patches, see the "`Creating
the Append File <#creating-the-append-file>`__" and "`Applying
Patches <#applying-patches>`__" sections. You can also see the
- ":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+ ":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
section in the Yocto Project Development Tasks Manual.
.. note::
diff --git a/documentation/kernel-dev/kernel-dev-faq.rst b/documentation/kernel-dev/kernel-dev-faq.rst
index 424e62617..54623453a 100644
--- a/documentation/kernel-dev/kernel-dev-faq.rst
+++ b/documentation/kernel-dev/kernel-dev-faq.rst
@@ -38,7 +38,7 @@ The kernel image (e.g. ``vmlinuz``) is provided by the
specify whether or not the kernel image is installed in the generated
root filesystem, override ``RDEPENDS_${KERNEL_PACKAGE_NAME}-base`` to include or not
include "kernel-image". See the
-":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
section in the
Yocto Project Development Tasks Manual for information on how to use an
append file to override metadata.
diff --git a/documentation/kernel-dev/kernel-dev-intro.rst b/documentation/kernel-dev/kernel-dev-intro.rst
index 29d4516c5..3987b0e59 100644
--- a/documentation/kernel-dev/kernel-dev-intro.rst
+++ b/documentation/kernel-dev/kernel-dev-intro.rst
@@ -88,7 +88,7 @@ understand the following documentation:
as described in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
-- The ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+- The ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual.
- The "`Kernel Modification
@@ -111,7 +111,7 @@ general information and references for further information.
:align: center
1. *Set up Your Host Development System to Support Development Using the
- Yocto Project*: See the ":doc:`/dev-manual/dev-manual-start`" section in
+ Yocto Project*: See the ":doc:`/dev-manual/start`" section in
the Yocto Project Development Tasks Manual for options on how to get
a build host ready to use the Yocto Project.
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst
index bbf2d0494..d2e335e80 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/overview-manual-concepts.rst
@@ -34,7 +34,7 @@ itself is of various types:
BitBake knows how to combine multiple data sources together and refers
to each data source as a layer. For information on layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
section of the Yocto Project Development Tasks Manual.
Following are some brief details on these core components. For
@@ -153,7 +153,7 @@ Conforming to a known structure allows BitBake to make assumptions
during builds on where to find types of metadata. You can find
procedures and learn about tools (i.e. ``bitbake-layers``) for creating
layers suitable for the Yocto Project in the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
section of the Yocto Project Development Tasks Manual.
OpenEmbedded Build System Concepts
@@ -317,7 +317,7 @@ during the build. By default, the layers listed in this file include
layers minimally needed by the build system. However, you must manually
add any custom layers you have created. You can find more information on
working with the ``bblayers.conf`` file in the
-":ref:`dev-manual/dev-manual-common-tasks:enabling your layer`"
+":ref:`dev-manual/common-tasks:enabling your layer`"
section in the Yocto Project Development Tasks Manual.
The files ``site.conf`` and ``auto.conf`` are not created by the
@@ -418,7 +418,7 @@ a ``README`` file as good practice and especially if the layer is to be
distributed, a configuration directory, and recipe directories. You can
learn about the general structure for layers used with the Yocto Project
in the
-":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`"
+":ref:`dev-manual/common-tasks:creating your own layer`"
section in the
Yocto Project Development Tasks Manual. For a general discussion on
layers and the many layers from which you can draw, see the
@@ -827,7 +827,7 @@ For more information on how the source directories are created, see the
"`Source Fetching <#source-fetching-dev-environment>`__" section. For
more information on how to create patches and how the build system
processes patches, see the
-":ref:`dev-manual/dev-manual-common-tasks:patching code`"
+":ref:`dev-manual/common-tasks:patching code`"
section in the
Yocto Project Development Tasks Manual. You can also see the
":ref:`sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
@@ -1029,7 +1029,7 @@ stage of package installation, post installation scripts that are part
of the packages are run. Any scripts that fail to run on the build host
are run on the target when the target system is first booted. If you are
using a
-:ref:`read-only root filesystem <dev-manual/dev-manual-common-tasks:creating a read-only root filesystem>`,
+:ref:`read-only root filesystem <dev-manual/common-tasks:creating a read-only root filesystem>`,
all the post installation scripts must succeed on the build host during
the package installation phase since the root filesystem on the target
is read-only.
@@ -1192,7 +1192,7 @@ varflag. If some other task depends on such a task, then that task will
also always be considered out of date, which might not be what you want.
For details on how to view information about a task's signature, see the
-":ref:`dev-manual/dev-manual-common-tasks:viewing task variable dependencies`"
+":ref:`dev-manual/common-tasks:viewing task variable dependencies`"
section in the Yocto Project Development Tasks Manual.
Setscene Tasks and Shared State
@@ -1626,15 +1626,15 @@ them if they are deemed to be valid.
the shared state packages. Consequently, considerations exist that
affect maintaining shared state feeds. For information on how the
build system works with packages and can track incrementing ``PR``
- information, see the ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
+ information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
section in the Yocto Project Development Tasks Manual.
- The code in the build system that supports incremental builds is
not simple code. For techniques that help you work around issues
related to shared state code, see the
- ":ref:`dev-manual/dev-manual-common-tasks:viewing metadata used to create the input signature of a shared state task`"
+ ":ref:`dev-manual/common-tasks:viewing metadata used to create the input signature of a shared state task`"
and
- ":ref:`dev-manual/dev-manual-common-tasks:invalidating shared state to force a task to run`"
+ ":ref:`dev-manual/common-tasks:invalidating shared state to force a task to run`"
sections both in the Yocto Project Development Tasks Manual.
The rest of this section goes into detail about the overall incremental
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index 2421ec1a8..e03b4cdc6 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -66,7 +66,7 @@ to set up a CROPS machine, you effectively have access to a shell
environment that is similar to what you see when using a Linux-based
development host. For the steps needed to set up a system using CROPS,
see the
-":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`"
+":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
section in
the Yocto Project Development Tasks Manual.
@@ -77,7 +77,7 @@ distribution on the system is one that supports the Yocto Project. You
also need to be sure that the correct set of host packages are installed
that allow development using the Yocto Project. For the steps needed to
set up a development host that runs Linux, see the
-":ref:`dev-manual/dev-manual-start:setting up a native linux host`"
+":ref:`dev-manual/start:setting up a native linux host`"
section in the Yocto Project Development Tasks Manual.
Once your development host is set up to use the Yocto Project, several
@@ -94,7 +94,7 @@ methods exist for you to do work in the Yocto Project environment:
through your Linux distribution and the Yocto Project.
For a general flow of the build procedures, see the
- ":ref:`dev-manual/dev-manual-common-tasks:building a simple image`"
+ ":ref:`dev-manual/common-tasks:building a simple image`"
section in the Yocto Project Development Tasks Manual.
- *Board Support Package (BSP) Development:* Development of BSPs
@@ -178,7 +178,7 @@ development:
:align: center
For steps on how to view and access these upstream Git repositories,
- see the ":ref:`dev-manual/dev-manual-start:accessing source repositories`"
+ see the ":ref:`dev-manual/start:accessing source repositories`"
Section in the Yocto Project Development Tasks Manual.
- :yocto_dl:`Index of /releases: </releases>` This is an index
@@ -192,7 +192,7 @@ development:
:align: center
For steps on how to view and access these files, see the
- ":ref:`dev-manual/dev-manual-start:accessing index of releases`"
+ ":ref:`dev-manual/start:accessing index of releases`"
section in the Yocto Project Development Tasks Manual.
- *"DOWNLOADS" page for the* :yocto_home:`Yocto Project Website <>` *:*
@@ -207,7 +207,7 @@ development:
:align: center
For steps on how to use the "DOWNLOADS" page, see the
- ":ref:`dev-manual/dev-manual-start:using the downloads page`"
+ ":ref:`dev-manual/start:using the downloads page`"
section in the Yocto Project Development Tasks Manual.
Git Workflows and the Yocto Project
@@ -242,7 +242,7 @@ and so forth.
For information on finding out who is responsible for (maintains) a
particular area of code in the Yocto Project, see the
- ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+ ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section of the Yocto Project Development Tasks Manual.
The Yocto Project ``poky`` Git repository also has an upstream
@@ -274,7 +274,7 @@ push them into the "contrib" area and subsequently request that the
maintainer include them into an upstream branch. This process is called
"submitting a patch" or "submitting a change." For information on
submitting patches and changes, see the
-":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section in the Yocto Project Development Tasks Manual.
In summary, a single point of entry exists for changes into a "master"
@@ -341,7 +341,7 @@ Book <http://book.git-scm.com>`__.
the ``scripts`` folder of the
:term:`Source Directory`. For information
on how to use these scripts, see the
- ":ref:`dev-manual/dev-manual-common-tasks:using scripts to push a change upstream and request a pull`"
+ ":ref:`dev-manual/common-tasks:using scripts to push a change upstream and request a pull`"
section in the Yocto Project Development Tasks Manual.
- *Patch Workflow:* This workflow allows you to notify the maintainer
@@ -350,7 +350,7 @@ Book <http://book.git-scm.com>`__.
this type of change, you format the patch and then send the email
using the Git commands ``git format-patch`` and ``git send-email``.
For information on how to use these scripts, see the
- ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
+ ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
section in the Yocto Project Development Tasks Manual.
Git
@@ -376,7 +376,7 @@ commands.
page, see http://git-scm.com/download.
- For information beyond the introductory nature in this section,
- see the ":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+ see the ":ref:`dev-manual/start:locating yocto project source files`"
section in the Yocto Project Development Tasks Manual.
Repositories, Tags, and Branches
@@ -408,7 +408,7 @@ You can create a local copy of any repository by "cloning" it with the
an identical copy of the repository on your development system. Once you
have a local copy of a repository, you can take steps to develop
locally. For examples on how to clone Git repositories, see the
-":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+":ref:`dev-manual/start:locating yocto project source files`"
section in the Yocto Project Development Tasks Manual.
It is important to understand that Git tracks content change and not
@@ -661,5 +661,5 @@ Project uses in the ``meta/files/common-licenses`` directory in your
For information that can help you maintain compliance with various open
source licensing during the lifecycle of a product created using the
Yocto Project, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
section in the Yocto Project Development Tasks Manual.
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index d6488c621..a6568d1c8 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -130,7 +130,7 @@ Project:
arbitrarily include packages.
- *License Manifest:* The Yocto Project provides a :ref:`license
- manifest <dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle>`
+ manifest <dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle>`
for review by people who need to track the use of open source
licenses (e.g. legal teams).
@@ -228,7 +228,7 @@ your Metadata, the easier it is to cope with future changes.
- Layers support the inclusion of technologies, hardware components,
and software components. The :ref:`Yocto Project
- Compatible <dev-manual/dev-manual-common-tasks:making sure your layer is compatible with yocto project>`
+ Compatible <dev-manual/common-tasks:making sure your layer is compatible with yocto project>`
designation provides a minimum level of standardization that
contributes to a strong ecosystem. "YP Compatible" is applied to
appropriate products and software components such as BSPs, other
@@ -274,7 +274,7 @@ of the ``poky`` repository, you will see several layers: ``meta``,
layer.
For procedures on how to create layers, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual.
Components and Tools
@@ -357,7 +357,7 @@ activities using the Yocto Project:
(BitBake and
OE-Core) automatically generates upgrades for recipes that are based
on new versions of the recipes published upstream. See
- :ref:`dev-manual/dev-manual-common-tasks:using the auto upgrade helper (auh)`
+ :ref:`dev-manual/common-tasks:using the auto upgrade helper (auh)`
for how to set it up.
- *Recipe Reporting System:* The Recipe Reporting System tracks recipe
@@ -601,7 +601,7 @@ Project.
For information on how to set up a Build Host on a system running
Linux as its native operating system, see the
- ":ref:`dev-manual/dev-manual-start:setting up a native linux host`"
+ ":ref:`dev-manual/start:setting up a native linux host`"
section in the Yocto Project Development Tasks Manual.
- *CROss PlatformS (CROPS):* Typically, you use
@@ -621,7 +621,7 @@ Project.
system natively running Linux.
For information on how to set up a Build Host with CROPS, see the
- ":ref:`dev-manual/dev-manual-start:setting up to use cross platforms (crops)`"
+ ":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
section in the Yocto Project Development Tasks Manual.
- *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem
@@ -638,7 +638,7 @@ Project.
virtualization technology.
For information on how to set up a Build Host with WSLv2, see the
- ":ref:`dev-manual/dev-manual-start:setting up to use windows subsystem for linux (wslv2)`"
+ ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wslv2)`"
section in the Yocto Project Development Tasks Manual.
- *Toaster:* Regardless of what your Build Host is running, you can use
@@ -824,7 +824,7 @@ helpful for getting started:
Project.
For more detailed information on layers, see the
- ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+ ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual. For a
discussion specifically on BSP Layers, see the
":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index 819b6857d..5b9fcc191 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -45,7 +45,7 @@ section for steps on how to update your build tools.
**A:** Support for an additional board is added by creating a Board
Support Package (BSP) layer for it. For more information on how to
create a BSP layer, see the
-":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual and the
:doc:`/bsp-guide/index`.
@@ -73,7 +73,7 @@ device.
**A:** To add a package, you need to create a BitBake recipe. For
information on how to create a BitBake recipe, see the
-":ref:`dev-manual/dev-manual-common-tasks:writing a new recipe`"
+":ref:`dev-manual/common-tasks:writing a new recipe`"
section in the Yocto Project Development Tasks Manual.
**Q:** Do I have to reflash my entire board with a new Yocto Project
@@ -201,7 +201,7 @@ You can find more information on licensing in the
":ref:`overview-manual/overview-manual-development-environment:licensing`"
section in the Yocto
Project Overview and Concepts Manual and also in the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
section in the Yocto Project Development Tasks Manual.
**Q:** How do I disable the cursor on my touchscreen device?
diff --git a/documentation/ref-manual/migration-1.4.rst b/documentation/ref-manual/migration-1.4.rst
index daaea0ffa..0b7e86117 100644
--- a/documentation/ref-manual/migration-1.4.rst
+++ b/documentation/ref-manual/migration-1.4.rst
@@ -84,7 +84,7 @@ create an append file for the ``init-ifupdown`` recipe instead, which
you can find in the :term:`Source Directory` at
``meta/recipes-core/init-ifupdown``. For information on how to use
append files, see the
-":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
+":ref:`dev-manual/common-tasks:using .bbappend files in your layer`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.4-remote-debugging:
diff --git a/documentation/ref-manual/migration-1.5.rst b/documentation/ref-manual/migration-1.5.rst
index 5e1e23f21..b5e4bb1fd 100644
--- a/documentation/ref-manual/migration-1.5.rst
+++ b/documentation/ref-manual/migration-1.5.rst
@@ -246,7 +246,7 @@ A new automated image testing framework has been added through the
framework replaces the older ``imagetest-qemu`` framework.
You can learn more about performing automated image tests in the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.5-build-history:
@@ -269,7 +269,7 @@ Following are changes to Build History:
option for each utility for more information on the new syntax.
For more information on Build History, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.5-udev:
diff --git a/documentation/ref-manual/migration-1.6.rst b/documentation/ref-manual/migration-1.6.rst
index 822d5cfa0..f95f45ec9 100644
--- a/documentation/ref-manual/migration-1.6.rst
+++ b/documentation/ref-manual/migration-1.6.rst
@@ -12,7 +12,7 @@ Project 1.6 Release from the prior release.
The :ref:`archiver <ref-classes-archiver>` class has been rewritten
and its configuration has been simplified. For more details on the
source archiver, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.6-packaging-changes:
@@ -148,7 +148,7 @@ NFS mount, an error occurs.
The ``PRINC`` variable has been deprecated and triggers a warning if
detected during a build. For :term:`PR` increments on changes,
use the PR service instead. You can find out more about this service in
-the ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`"
+the ":ref:`dev-manual/common-tasks:working with a pr service`"
section in the Yocto Project Development Tasks Manual.
.. _migration-1.6-variable-changes-IMAGE_TYPES:
@@ -221,7 +221,7 @@ Package Test (ptest)
Package Tests (ptest) are built but not installed by default. For
information on using Package Tests, see the
-":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+":ref:`dev-manual/common-tasks:testing packages with ptest`"
section in the Yocto Project Development Tasks Manual. For information on the
``ptest`` class, see the ":ref:`ptest.bbclass <ref-classes-ptest>`"
section.
diff --git a/documentation/ref-manual/migration-1.7.rst b/documentation/ref-manual/migration-1.7.rst
index c3f9469da..85894d9df 100644
--- a/documentation/ref-manual/migration-1.7.rst
+++ b/documentation/ref-manual/migration-1.7.rst
@@ -217,7 +217,7 @@ The following miscellaneous change occurred:
should manually remove old "build-id" files from your existing build
history repositories to avoid confusion. For information on the build
history feature, see the
- ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+ ":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
diff --git a/documentation/ref-manual/migration-2.1.rst b/documentation/ref-manual/migration-2.1.rst
index ada9d2986..678a767e1 100644
--- a/documentation/ref-manual/migration-2.1.rst
+++ b/documentation/ref-manual/migration-2.1.rst
@@ -346,7 +346,7 @@ This release supports generation of GLib Introspective Repository (GIR)
files through GObject introspection, which is the standard mechanism for
accessing GObject-based software from runtime environments. You can
enable, disable, and test the generation of this data. See the
-":ref:`dev-manual/dev-manual-common-tasks:enabling gobject introspection support`"
+":ref:`dev-manual/common-tasks:enabling gobject introspection support`"
section in the Yocto Project Development Tasks Manual for more
information.
diff --git a/documentation/ref-manual/migration-2.3.rst b/documentation/ref-manual/migration-2.3.rst
index c0a8f0419..9e95f45e1 100644
--- a/documentation/ref-manual/migration-2.3.rst
+++ b/documentation/ref-manual/migration-2.3.rst
@@ -366,7 +366,7 @@ The following changes have been made to Wic:
.. note::
For more information on Wic, see the
- ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+ ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section in the Yocto Project Development Tasks Manual.
- *Default Output Directory Changed:* Wic's default output directory is
diff --git a/documentation/ref-manual/migration-2.5.rst b/documentation/ref-manual/migration-2.5.rst
index 7f1b80938..9f45ffce7 100644
--- a/documentation/ref-manual/migration-2.5.rst
+++ b/documentation/ref-manual/migration-2.5.rst
@@ -266,7 +266,7 @@ The following are additional changes:
will trigger a warning during ``do_rootfs``.
For more information, see the
- ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
+ ":ref:`dev-manual/common-tasks:post-installation scripts`"
section in the Yocto Project Development Tasks Manual.
- The ``elf`` image type has been removed. This image type was removed
diff --git a/documentation/ref-manual/migration-2.6.rst b/documentation/ref-manual/migration-2.6.rst
index cc7c24c5b..5d524f381 100644
--- a/documentation/ref-manual/migration-2.6.rst
+++ b/documentation/ref-manual/migration-2.6.rst
@@ -372,7 +372,7 @@ Any failure of a ``pkg_postinst()`` script (including exit 1) triggers
an error during the :ref:`ref-tasks-rootfs` task.
For more information on post-installation behavior, see the
-":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
+":ref:`dev-manual/common-tasks:post-installation scripts`"
section in the Yocto Project Development Tasks Manual.
.. _migration-2.6-python-3-profile-guided-optimizations:
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst
index e0cdbe87f..4147044ea 100644
--- a/documentation/ref-manual/ref-classes.rst
+++ b/documentation/ref-manual/ref-classes.rst
@@ -68,7 +68,7 @@ The ``archiver`` class supports releasing source code and other
materials with the binaries.
For more details on the source archiver, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
section in the Yocto Project Development Tasks Manual. You can also see
the :term:`ARCHIVER_MODE` variable for information
about the variable flags (varflags) that help control archive creation.
@@ -86,7 +86,7 @@ standardization. This class defines a set of tasks (e.g. ``configure``,
should usually be enough to define a few standard variables and then
simply ``inherit autotools``. These classes can also work with software
that emulates Autotools. For more information, see the
-":ref:`dev-manual/dev-manual-common-tasks:autotooled package`" section
+":ref:`dev-manual/common-tasks:autotooled package`" section
in the Yocto Project Development Tasks Manual.
By default, the ``autotools*`` classes use out-of-tree builds (i.e.
@@ -236,7 +236,7 @@ The ``buildhistory`` class records a history of build output metadata,
which can be used to detect possible regressions as well as used for
analysis of the build output. For more information on using Build
History, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-buildstats:
@@ -458,7 +458,7 @@ staging the files from ``DEPLOYDIR`` to ``DEPLOY_DIR_IMAGE``.
====================
The ``devshell`` class adds the ``do_devshell`` task. Distribution
-policy dictates whether to include this class. See the ":ref:`dev-manual/dev-manual-common-tasks:using a development shell`"
+policy dictates whether to include this class. See the ":ref:`dev-manual/common-tasks:using a development shell`"
section in the Yocto Project Development Tasks Manual for more
information about using ``devshell``.
@@ -586,7 +586,7 @@ For more information on the ``externalsrc`` class, see the comments in
``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`.
For information on how to use the
``externalsrc`` class, see the
-":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
+":ref:`dev-manual/common-tasks:building software from an external source`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-extrausers:
@@ -927,7 +927,7 @@ then one or more image files are created.
install into the image.
For information on customizing images, see the
-":ref:`dev-manual/dev-manual-common-tasks:customizing images`" section
+":ref:`dev-manual/common-tasks:customizing images`" section
in the Yocto Project Development Tasks Manual. For information on how
images are created, see the
":ref:`overview-manual/overview-manual-concepts:images`" section in the
@@ -1344,7 +1344,7 @@ packages such as ``kernel-vmlinux``.
The ``kernel`` class contains logic that allows you to embed an initial
RAM filesystem (initramfs) image when you build the kernel image. For
information on how to build an initramfs, see the
-":ref:`dev-manual/dev-manual-common-tasks:building an initial ram filesystem (initramfs) image`" section in
+":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section in
the Yocto Project Development Tasks Manual.
Various other classes are used by the ``kernel`` and ``module`` classes
@@ -1620,7 +1620,7 @@ different target optimizations or target architectures and installing
them side-by-side in the same image.
For more information on using the Multilib feature, see the
-":ref:`dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image`"
+":ref:`dev-manual/common-tasks:combining multiple versions of library files into one image`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-native:
@@ -1732,7 +1732,7 @@ package manager (NPM) <https://en.wikipedia.org/wiki/Npm_(software)>`__.
fetcher to have dependencies fetched and packaged automatically.
For information on how to create NPM packages, see the
-":ref:`dev-manual/dev-manual-common-tasks:creating node package manager (npm) packages`"
+":ref:`dev-manual/common-tasks:creating node package manager (npm) packages`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-oelint:
@@ -1802,7 +1802,7 @@ If you take the optional step to set up a repository (package feed) on
the development host that can be used by DNF, you can install packages
from the feed while you are running the image on the target (i.e.
runtime installation of packages). For more information, see the
-":ref:`dev-manual/dev-manual-common-tasks:using runtime package management`"
+":ref:`dev-manual/common-tasks:using runtime package management`"
section in the Yocto Project Development Tasks Manual.
The package-specific class you choose can affect build-time performance
@@ -1921,7 +1921,7 @@ so forth). It is highly recommended that all package group recipes
inherit this class.
For information on how to use this class, see the
-":ref:`dev-manual/dev-manual-common-tasks:customizing images using custom package groups`"
+":ref:`dev-manual/common-tasks:customizing images using custom package groups`"
section in the Yocto Project Development Tasks Manual.
Previously, this class was called the ``task`` class.
@@ -2080,7 +2080,7 @@ The ``primport`` class provides functionality for importing
==================
The ``prserv`` class provides functionality for using a :ref:`PR
-service <dev-manual/dev-manual-common-tasks:working with a pr service>` in order to
+service <dev-manual/common-tasks:working with a pr service>` in order to
automatically manage the incrementing of the :term:`PR`
variable for each recipe.
@@ -2100,7 +2100,7 @@ runtime tests for recipes that build software that provides these tests.
This class is intended to be inherited by individual recipes. However,
the class' functionality is largely disabled unless "ptest" appears in
:term:`DISTRO_FEATURES`. See the
-":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+":ref:`dev-manual/common-tasks:testing packages with ptest`"
section in the Yocto Project Development Tasks Manual for more information
on ptest.
@@ -2113,7 +2113,7 @@ Enables package tests (ptests) specifically for GNOME packages, which
have tests intended to be executed with ``gnome-desktop-testing``.
For information on setting up and running ptests, see the
-":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`"
+":ref:`dev-manual/common-tasks:testing packages with ptest`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-python-dir:
@@ -2199,7 +2199,7 @@ override the removal by setting ``REMOVE_LIBTOOL_LA`` to "0" as follows:
========================
The ``report-error`` class supports enabling the :ref:`error reporting
-tool <dev-manual/dev-manual-common-tasks:using the error reporting tool>`",
+tool <dev-manual/common-tasks:using the error reporting tool>`",
which allows you to submit build error information to a central database.
The class collects debug information for recipe, recipe version, task,
@@ -2554,7 +2554,7 @@ unless you have set
:term:`SYSTEMD_AUTO_ENABLE` to "disable".
For more information on ``systemd``, see the
-":ref:`dev-manual/dev-manual-common-tasks:selecting an initialization manager`"
+":ref:`dev-manual/common-tasks:selecting an initialization manager`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-systemd-boot:
@@ -2631,7 +2631,7 @@ runs tests on an image after the image is constructed (i.e.
:term:`TESTIMAGE_AUTO` must be set to "1").
For information on how to enable, run, and create new tests, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
.. _ref-classes-testsdk:
diff --git a/documentation/ref-manual/ref-devtool-reference.rst b/documentation/ref-manual/ref-devtool-reference.rst
index 83861d271..11b4cb5d5 100644
--- a/documentation/ref-manual/ref-devtool-reference.rst
+++ b/documentation/ref-manual/ref-devtool-reference.rst
@@ -413,7 +413,7 @@ Upgrading a Recipe
As software matures, upstream recipes are upgraded to newer versions. As
a developer, you need to keep your local recipes up-to-date with the
upstream version releases. Several methods exist by which you can
-upgrade recipes. You can read about them in the ":ref:`dev-manual/dev-manual-common-tasks:upgrading recipes`"
+upgrade recipes. You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`"
section of the Yocto Project Development Tasks Manual. This section
overviews the ``devtool upgrade`` command.
@@ -441,7 +441,7 @@ You can read more on the ``devtool upgrade`` workflow in the
":ref:`sdk-manual/sdk-extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual. You can also see an example of
-how to use ``devtool upgrade`` in the ":ref:`dev-manual/dev-manual-common-tasks:using \`\`devtool upgrade\`\``"
+how to use ``devtool upgrade`` in the ":ref:`dev-manual/common-tasks:using \`\`devtool upgrade\`\``"
section in the Yocto Project Development Tasks Manual.
.. _devtool-resetting-a-recipe:
diff --git a/documentation/ref-manual/ref-features.rst b/documentation/ref-manual/ref-features.rst
index 6c85c2418..cb4b57436 100644
--- a/documentation/ref-manual/ref-features.rst
+++ b/documentation/ref-manual/ref-features.rst
@@ -156,7 +156,7 @@ metadata:
- *ptest:* Enables building the package tests where supported by
individual recipes. For more information on package tests, see the
- ":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`" section
+ ":ref:`dev-manual/common-tasks:testing packages with ptest`" section
in the Yocto Project Development Tasks Manual.
- *smbfs:* Include SMB networks client support (for mounting
@@ -236,7 +236,7 @@ The following image features are available for all images:
- *read-only-rootfs:* Creates an image whose root filesystem is
read-only. See the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
+ ":ref:`dev-manual/common-tasks:creating a read-only root filesystem`"
section in the Yocto Project Development Tasks Manual for more
information.
@@ -273,7 +273,7 @@ these valid features is as follows:
- *tools-debug:* Installs debugging tools such as ``strace`` and
``gdb``. For information on GDB, see the
- ":ref:`dev-manual/dev-manual-common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
+ ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
in the Yocto Project Development Tasks Manual. For information on
tracing and profiling, see the :doc:`/profile-manual/index`.
diff --git a/documentation/ref-manual/ref-images.rst b/documentation/ref-manual/ref-images.rst
index 56ec8562f..5e9374eae 100644
--- a/documentation/ref-manual/ref-images.rst
+++ b/documentation/ref-manual/ref-images.rst
@@ -122,7 +122,7 @@ Following is a list of supported recipes:
deployed to a separate partition so that you can boot into it and use
it to deploy a second image to be tested. You can find more
information about runtime testing in the
- ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+ ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
- ``core-image-testmaster-initramfs``: A RAM-based Initial Root
@@ -132,7 +132,7 @@ Following is a list of supported recipes:
- ``core-image-weston``: A very basic Wayland image with a terminal.
This image provides the Wayland protocol libraries and the reference
Weston compositor. For more information, see the
- ":ref:`dev-manual/dev-manual-common-tasks:using wayland and weston`"
+ ":ref:`dev-manual/common-tasks:using wayland and weston`"
section in the Yocto Project Development Tasks Manual.
- ``core-image-x11``: A very basic X11 image with a terminal.
diff --git a/documentation/ref-manual/ref-kickstart.rst b/documentation/ref-manual/ref-kickstart.rst
index 7f6d4ebe1..bb9c0460f 100644
--- a/documentation/ref-manual/ref-kickstart.rst
+++ b/documentation/ref-manual/ref-kickstart.rst
@@ -79,7 +79,7 @@ the ``part`` and ``partition`` commands:
source of the data that populates the partition. The most common
value for this option is "rootfs", but you can use any value that
maps to a valid source plugin. For information on the source plugins,
- see the ":ref:`dev-manual/dev-manual-common-tasks:using the wic plugin interface`"
+ see the ":ref:`dev-manual/common-tasks:using the wic plugin interface`"
section in the Yocto Project Development Tasks Manual.
If you use ``--source rootfs``, Wic creates a partition as large as
diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst
index ec6d23387..54cd9510f 100644
--- a/documentation/ref-manual/ref-release-process.rst
+++ b/documentation/ref-manual/ref-release-process.rst
@@ -106,7 +106,7 @@ Additionally, because the test strategies are visible to you as a
developer, you can validate your projects. This section overviews the
available test infrastructure used in the Yocto Project. For information
on how to run available tests on your projects, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
The QA/testing infrastructure is woven into the project to the point
@@ -128,12 +128,12 @@ consists of the following pieces:
- :ref:`testimage.bbclass <ref-classes-testimage*>`: This class
performs runtime testing of images after they are built. The tests
- are usually used with :doc:`QEMU </dev-manual/dev-manual-qemu>`
+ are usually used with :doc:`QEMU </dev-manual/qemu>`
to boot the images and check the combined runtime result boot
operation and functions. However, the test can also use the IP
address of a machine to test.
-- :ref:`ptest <dev-manual/dev-manual-common-tasks:testing packages with ptest>`:
+- :ref:`ptest <dev-manual/common-tasks:testing packages with ptest>`:
Runs tests against packages produced during the build for a given
piece of software. The test allows the packages to be be run within a
target image.
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index d3a231554..b681e8233 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -12,7 +12,7 @@ and directories.
For information on how to establish a local Source Directory on your
development system, see the
-":ref:`dev-manual/dev-manual-start:locating yocto project source files`"
+":ref:`dev-manual/start:locating yocto project source files`"
section in the Yocto Project Development Tasks Manual.
.. note::
@@ -176,7 +176,7 @@ within the :term:`Source Directory`. If you design a
custom distribution, you can include your own version of this
configuration file to mention the targets defined by your distribution.
See the
-":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`"
+":ref:`dev-manual/common-tasks:creating a custom template configuration directory`"
section in the Yocto Project Development Tasks Manual for more
information.
@@ -193,7 +193,7 @@ Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`:
The OpenEmbedded build system uses the template configuration files, which
are found by default in the ``meta-poky/conf/`` directory in the Source
Directory. See the
-":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`"
+":ref:`dev-manual/common-tasks:creating a custom template configuration directory`"
section in the Yocto Project Development Tasks Manual for more
information.
@@ -236,7 +236,7 @@ The OpenEmbedded build system creates this directory when you enable
build history via the ``buildhistory`` class file. The directory
organizes build information into image, packages, and SDK
subdirectories. For information on the build history feature, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
.. _structure-build-conf-local.conf:
@@ -292,7 +292,7 @@ file, it uses ``sed`` to substitute final
----------------------------
This configuration file defines
-:ref:`layers <dev-manual/dev-manual-common-tasks:understanding and creating layers>`,
+:ref:`layers <dev-manual/common-tasks:understanding and creating layers>`,
which are directory trees, traversed (or walked) by BitBake. The
``bblayers.conf`` file uses the :term:`BBLAYERS`
variable to list the layers BitBake tries to find.
@@ -438,7 +438,7 @@ directory contains sub-directories for ``bash``, ``busybox``, and
``glibc`` (among others) that in turn contain appropriate ``COPYING``
license files with other licensing information. For information on
licensing, see the
-":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`"
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
section in the Yocto Project Development Tasks Manual.
.. _structure-build-tmp-deploy-images:
@@ -577,7 +577,7 @@ built within the Yocto Project. For this package, a work directory of
``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred
to as the ``WORKDIR``, is created. Within this directory, the source is
unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt.
-(See the ":ref:`dev-manual/dev-manual-common-tasks:using quilt in your workflow`" section in
+(See the ":ref:`dev-manual/common-tasks:using quilt in your workflow`" section in
the Yocto Project Development Tasks Manual for more information.) Within
the ``linux-qemux86-standard-build`` directory, standard Quilt
directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and
diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/ref-system-requirements.rst
index 2c7c1e075..d162c9bad 100644
--- a/documentation/ref-manual/ref-system-requirements.rst
+++ b/documentation/ref-manual/ref-system-requirements.rst
@@ -94,7 +94,7 @@ distributions:
interested in hearing about your experience. For information on
how to submit a bug, see the Yocto Project
:yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
- and the ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`"
+ and the ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
section in the Yocto Project Development Tasks Manual.
diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst
index 9fde9a837..89731d459 100644
--- a/documentation/ref-manual/ref-tasks.rst
+++ b/documentation/ref-manual/ref-tasks.rst
@@ -351,7 +351,7 @@ applied as a patch by default except for the ``patch_file5`` patch.
You can find out more about the patching process in the
":ref:`overview-manual/overview-manual-concepts:patching`" section in
the Yocto Project Overview and Concepts Manual and the
-":ref:`dev-manual/dev-manual-common-tasks:patching code`" section in the
+":ref:`dev-manual/common-tasks:patching code`" section in the
Yocto Project Development Tasks Manual.
.. _ref-tasks-populate_lic:
@@ -567,7 +567,7 @@ scratch is guaranteed.
Starts a shell in which an interactive Python interpreter allows you to
interact with the BitBake build environment. From within this shell, you
can directly examine and set bits from the data store and execute
-functions as if within the BitBake environment. See the ":ref:`dev-manual/dev-manual-common-tasks:using a development python shell`" section in
+functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a development python shell`" section in
the Yocto Project Development Tasks Manual for more information about
using ``devpyshell``.
@@ -577,7 +577,7 @@ using ``devpyshell``.
---------------
Starts a shell whose environment is set up for development, debugging,
-or both. See the ":ref:`dev-manual/dev-manual-common-tasks:using a development shell`" section in the
+or both. See the ":ref:`dev-manual/common-tasks:using a development shell`" section in the
Yocto Project Development Tasks Manual for more information about using
``devshell``.
@@ -642,7 +642,7 @@ information on how the root filesystem is created.
Boots an image and performs runtime tests within the image. For
information on automatically testing images, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
.. _ref-tasks-testimage_auto:
@@ -655,7 +655,7 @@ after it has been built. This task is enabled when you set
:term:`TESTIMAGE_AUTO` equal to "1".
For information on automatically testing images, see the
-":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
Kernel-Related Tasks
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index 6f0facf72..ba1930ebd 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -21,7 +21,7 @@ universal, the list includes them just in case:
Information in append files extends or overrides the information in the
similarly-named recipe file. For an example of an append file in use, see
- the ":ref:`dev-manual/dev-manual-common-tasks:Using .bbappend Files in
+ the ":ref:`dev-manual/common-tasks:Using .bbappend Files in
Your Layer`" section in the Yocto Project Development Tasks Manual.
When you name an append file, you can use the "``%``" wildcard character
@@ -192,7 +192,7 @@ universal, the list includes them just in case:
":ref:`overview-manual/overview-manual-yp-intro:The Yocto Project Layer
Model`" section in the Yocto Project Overview and Concepts Manual. For
more detailed information on layers, see the
- ":ref:`dev-manual/dev-manual-common-tasks:Understanding and Creating
+ ":ref:`dev-manual/common-tasks:Understanding and Creating
Layers`" section in the Yocto Project Development Tasks Manual. For a
discussion specifically on BSP Layers, see the ":ref:`bsp-guide/bsp:BSP
Layers`" section in the Yocto Project Board Support Packages (BSP)
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index 8411989b6..65f64b91a 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -239,7 +239,7 @@ system and gives an overview of their function and contents.
so that it does contain ``${SRCPV}``.
For more information see the
- ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
+ ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
section in the Yocto Project Development Tasks Manual.
:term:`AVAILABLE_LICENSES`
@@ -261,7 +261,7 @@ system and gives an overview of their function and contents.
The list simply presents the tunes that are available. Not all tunes
may be compatible with a particular machine configuration, or with
each other in a
- :ref:`Multilib <dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image>`
+ :ref:`Multilib <dev-manual/common-tasks:combining multiple versions of library files into one image>`
configuration.
To add a tune to the list, be sure to append it with spaces using the
@@ -317,7 +317,7 @@ system and gives an overview of their function and contents.
:term:`BASE_LIB`
The library directory name for the CPU or Application Binary
Interface (ABI) tune. The ``BASE_LIB`` applies only in the Multilib
- context. See the ":ref:`dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image`"
+ context. See the ":ref:`dev-manual/common-tasks:combining multiple versions of library files into one image`"
section in the Yocto Project Development Tasks Manual for information
on Multilib.
@@ -545,7 +545,7 @@ system and gives an overview of their function and contents.
is not set higher than "20".
For more information on speeding up builds, see the
- ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+ ":ref:`dev-manual/common-tasks:speeding up a build`"
section in the Yocto Project Development Tasks Manual.
:term:`BB_SERVER_TIMEOUT`
@@ -746,7 +746,7 @@ system and gives an overview of their function and contents.
For information on how to use ``BBMULTICONFIG`` in an environment
that supports building targets with multiple configurations, see the
- ":ref:`dev-manual/dev-manual-common-tasks:building images for multiple targets using multiple configurations`"
+ ":ref:`dev-manual/common-tasks:building images for multiple targets using multiple configurations`"
section in the Yocto Project Development Tasks Manual.
:term:`BBPATH`
@@ -1002,7 +1002,7 @@ system and gives an overview of their function and contents.
When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
class, this variable specifies the build history features to be
enabled. For more information on how build history works, see the
- ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`"
+ ":ref:`dev-manual/common-tasks:maintaining build output quality`"
section in the Yocto Project Development Tasks Manual.
You can specify these features in the form of a space-separated list:
@@ -1299,7 +1299,7 @@ system and gives an overview of their function and contents.
will be the aggregate of all of them.
For information on creating an initramfs, see the
- ":ref:`dev-manual/dev-manual-common-tasks:building an initial ram filesystem (initramfs) image`" section
+ ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`CONFIG_SITE`
@@ -1402,7 +1402,7 @@ system and gives an overview of their function and contents.
newly installed packages to an image, which might be most suitable for
read-only filesystems that cannot be upgraded. See the
:term:`LICENSE_CREATE_PACKAGE` variable for additional information.
- You can also reference the ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+ You can also reference the ":ref:`dev-manual/common-tasks:providing license text`"
section in the Yocto Project Development Tasks Manual for
information on providing license text.
@@ -1418,7 +1418,7 @@ system and gives an overview of their function and contents.
newly installed packages to an image, which might be most suitable for
read-only filesystems that cannot be upgraded. See the
:term:`LICENSE_CREATE_PACKAGE` variable for additional information.
- You can also reference the ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+ You can also reference the ":ref:`dev-manual/common-tasks:providing license text`"
section in the Yocto Project Development Tasks Manual for
information on providing license text.
@@ -2029,7 +2029,7 @@ system and gives an overview of their function and contents.
When used with the :ref:`report-error <ref-classes-report-error>`
class, specifies the path used for storing the debug files created by
the :ref:`error reporting
- tool <dev-manual/dev-manual-common-tasks:using the error reporting tool>`, which
+ tool <dev-manual/common-tasks:using the error reporting tool>`, which
allows you to submit build errors you encounter to a central
database. By default, the value of this variable is
``${``\ :term:`LOG_DIR`\ ``}/error-report``.
@@ -2129,7 +2129,7 @@ system and gives an overview of their function and contents.
For more information on ``externalsrc.bbclass``, see the
":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
can also find information on how to use this variable in the
- ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
+ ":ref:`dev-manual/common-tasks:building software from an external source`"
section in the Yocto Project Development Tasks Manual.
:term:`EXTERNALSRC_BUILD`
@@ -2143,7 +2143,7 @@ system and gives an overview of their function and contents.
For more information on ``externalsrc.bbclass``, see the
":ref:`externalsrc.bbclass <ref-classes-externalsrc>`" section. You
can also find information on how to use this variable in the
- ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`"
+ ":ref:`dev-manual/common-tasks:building software from an external source`"
section in the Yocto Project Development Tasks Manual.
:term:`EXTRA_AUTORECONF`
@@ -2181,7 +2181,7 @@ system and gives an overview of their function and contents.
useful if you want to develop against the libraries in the image.
- "read-only-rootfs" - Creates an image whose root filesystem is
read-only. See the
- ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`"
+ ":ref:`dev-manual/common-tasks:creating a read-only root filesystem`"
section in the Yocto Project Development Tasks Manual for more
information
- "tools-debug" - Adds debugging tools such as gdb and strace.
@@ -2194,7 +2194,7 @@ system and gives an overview of their function and contents.
Project, see the ":ref:`ref-features-image`" section.
For an example that shows how to customize your image by using this
- variable, see the ":ref:`dev-manual/dev-manual-common-tasks:customizing images using custom \`\`image_features\`\` and \`\`extra_image_features\`\``"
+ variable, see the ":ref:`dev-manual/common-tasks:customizing images using custom \`\`image_features\`\` and \`\`extra_image_features\`\``"
section in the Yocto Project Development Tasks Manual.
:term:`EXTRA_IMAGECMD`
@@ -2511,7 +2511,7 @@ system and gives an overview of their function and contents.
You can find out more about the patching process in the
":ref:`overview-manual/overview-manual-concepts:patching`" section
in the Yocto Project Overview and Concepts Manual and the
- ":ref:`dev-manual/dev-manual-common-tasks:patching code`" section in
+ ":ref:`dev-manual/common-tasks:patching code`" section in
the Yocto Project Development Tasks Manual. See the
:ref:`ref-tasks-patch` task as well.
@@ -2904,7 +2904,7 @@ system and gives an overview of their function and contents.
the same files into a ``boot`` directory within the target partition.
You can find information on how to use the Wic tool in the
- ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+ ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section of the Yocto Project Development Tasks Manual. Reference
material for Wic is located in the
":doc:`/ref-manual/ref-kickstart`" chapter.
@@ -2940,7 +2940,7 @@ system and gives an overview of their function and contents.
the same files into a ``boot`` directory within the target partition.
You can find information on how to use the Wic tool in the
- ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+ ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section of the Yocto Project Development Tasks Manual. Reference
material for Wic is located in the
":doc:`/ref-manual/ref-kickstart`" chapter.
@@ -3000,7 +3000,7 @@ system and gives an overview of their function and contents.
the ":ref:`ref-features-image`" section.
For an example that shows how to customize your image by using this
- variable, see the ":ref:`dev-manual/dev-manual-common-tasks:customizing images using custom \`\`image_features\`\` and \`\`extra_image_features\`\``"
+ variable, see the ":ref:`dev-manual/common-tasks:customizing images using custom \`\`image_features\`\` and \`\`extra_image_features\`\``"
section in the Yocto Project Development Tasks Manual.
:term:`IMAGE_FSTYPES`
@@ -3058,7 +3058,7 @@ system and gives an overview of their function and contents.
allows the initial RAM filesystem (initramfs) recipe to use a
fixed set of packages and not be affected by ``IMAGE_INSTALL``.
For information on creating an initramfs, see the
- ":ref:`dev-manual/dev-manual-common-tasks:building an initial ram filesystem (initramfs) image`"
+ ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`"
section in the Yocto Project Development Tasks Manual.
- Using ``IMAGE_INSTALL`` with the
@@ -3554,7 +3554,7 @@ system and gives an overview of their function and contents.
:term:`INITRAMFS_IMAGE_BUNDLE`
variable, which allows the generated image to be bundled inside the
kernel image. Additionally, for information on creating an initramfs
- image, see the ":ref:`dev-manual/dev-manual-common-tasks:building an initial ram filesystem (initramfs) image`" section
+ image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`INITRAMFS_IMAGE_BUNDLE`
@@ -3602,7 +3602,7 @@ system and gives an overview of their function and contents.
See the
:yocto_git:`local.conf.sample.extended </poky/tree/meta-poky/conf/local.conf.sample.extended>`
file for additional information. Also, for information on creating an
- initramfs, see the ":ref:`dev-manual/dev-manual-common-tasks:building an initial ram filesystem (initramfs) image`" section
+ initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`INITRAMFS_LINK_NAME`
@@ -4191,7 +4191,7 @@ system and gives an overview of their function and contents.
The OpenEmbedded build system produces a warning if the variable
is not set for any given layer.
- See the ":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`"
+ See the ":ref:`dev-manual/common-tasks:creating your own layer`"
section in the Yocto Project Development Tasks Manual.
:term:`LAYERVERSION`
@@ -4240,7 +4240,7 @@ system and gives an overview of their function and contents.
This variable must be defined for all recipes (unless
:term:`LICENSE` is set to "CLOSED").
- For more information, see the ":ref:`dev-manual/dev-manual-common-tasks:tracking license changes`"
+ For more information, see the ":ref:`dev-manual/common-tasks:tracking license changes`"
section in the Yocto Project Development Tasks Manual.
:term:`LICENSE`
@@ -4306,7 +4306,7 @@ system and gives an overview of their function and contents.
For related information on providing license text, see the
:term:`COPY_LIC_DIRS` variable, the
:term:`COPY_LIC_MANIFEST` variable, and the
- ":ref:`dev-manual/dev-manual-common-tasks:providing license text`"
+ ":ref:`dev-manual/common-tasks:providing license text`"
section in the Yocto Project Development Tasks Manual.
:term:`LICENSE_FLAGS`
@@ -4319,7 +4319,7 @@ system and gives an overview of their function and contents.
typically used to mark recipes that might require additional licenses
in order to be used in a commercial product. For more information,
see the
- ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
+ ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
section in the Yocto Project Development Tasks Manual.
:term:`LICENSE_FLAGS_WHITELIST`
@@ -4327,7 +4327,7 @@ system and gives an overview of their function and contents.
:term:`LICENSE_FLAGS` within a recipe should not
prevent that recipe from being built. This practice is otherwise
known as "whitelisting" license flags. For more information, see the
- ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`"
+ ":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
section in the Yocto Project Development Tasks Manual.
:term:`LICENSE_PATH`
@@ -4890,7 +4890,7 @@ system and gives an overview of their function and contents.
Controls how the OpenEmbedded build system spawns interactive
terminals on the host development system (e.g. using the BitBake
command with the ``-c devshell`` command-line option). For more
- information, see the ":ref:`dev-manual/dev-manual-common-tasks:using a development shell`" section in
+ information, see the ":ref:`dev-manual/common-tasks:using a development shell`" section in
the Yocto Project Development Tasks Manual.
You can use the following values for the ``OE_TERMINAL`` variable:
@@ -4959,7 +4959,7 @@ system and gives an overview of their function and contents.
An easy way to see what overrides apply is to search for ``OVERRIDES``
in the output of the ``bitbake -e`` command. See the
- ":ref:`dev-manual/dev-manual-common-tasks:viewing variable values`" section in the Yocto
+ ":ref:`dev-manual/common-tasks:viewing variable values`" section in the Yocto
Project Development Tasks Manual for more information.
:term:`P`
@@ -4981,7 +4981,7 @@ system and gives an overview of their function and contents.
specific by using the package name as a suffix.
You can find out more about applying this variable in the
- ":ref:`dev-manual/dev-manual-common-tasks:adding custom metadata to packages`"
+ ":ref:`dev-manual/common-tasks:adding custom metadata to packages`"
section in the Yocto Project Development Tasks Manual.
:term:`PACKAGE_ARCH`
@@ -5079,7 +5079,7 @@ system and gives an overview of their function and contents.
separate ``*-src`` pkg. This is the default behavior.
You can find out more about debugging using GDB by reading the
- ":ref:`dev-manual/dev-manual-common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
+ ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
in the Yocto Project Development Tasks Manual.
:term:`PACKAGE_EXCLUDE_COMPLEMENTARY`
@@ -5243,7 +5243,7 @@ system and gives an overview of their function and contents.
the :ref:`core-image-minimal-initramfs <ref-manual/ref-images:images>`
image. When working with an initial RAM filesystem (initramfs) image,
use the ``PACKAGE_INSTALL`` variable. For information on creating an
- initramfs, see the ":ref:`dev-manual/dev-manual-common-tasks:building an initial ram filesystem (initramfs) image`" section
+ initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
in the Yocto Project Development Tasks Manual.
:term:`PACKAGE_INSTALL_ATTEMPTONLY`
@@ -5266,7 +5266,7 @@ system and gives an overview of their function and contents.
``PACKAGE_WRITE_DEPS``.
For information on running post-installation scripts, see the
- ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`"
+ ":ref:`dev-manual/common-tasks:post-installation scripts`"
section in the Yocto Project Development Tasks Manual.
:term:`PACKAGECONFIG`
@@ -5423,7 +5423,7 @@ system and gives an overview of their function and contents.
For an example of how to use the ``PACKAGES_DYNAMIC`` variable when
you are splitting packages, see the
- ":ref:`dev-manual/dev-manual-common-tasks:handling optional module packaging`"
+ ":ref:`dev-manual/common-tasks:handling optional module packaging`"
section in the Yocto Project Development Tasks Manual.
:term:`PACKAGESPLITFUNCS`
@@ -5458,7 +5458,7 @@ system and gives an overview of their function and contents.
the ``do_compile`` task that result in race conditions, you can clear
the ``PARALLEL_MAKE`` variable within the recipe as a workaround. For
information on addressing race conditions, see the
- ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`"
+ ":ref:`dev-manual/common-tasks:debugging parallel make races`"
section in the Yocto Project Development Tasks Manual.
For single socket systems (i.e. one CPU), you should not have to
@@ -5468,7 +5468,7 @@ system and gives an overview of their function and contents.
not set higher than "-j 20".
For more information on speeding up builds, see the
- ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`"
+ ":ref:`dev-manual/common-tasks:speeding up a build`"
section in the Yocto Project Development Tasks Manual.
:term:`PARALLEL_MAKEINST`
@@ -5488,7 +5488,7 @@ system and gives an overview of their function and contents.
the ``do_install`` task that result in race conditions, you can
clear the ``PARALLEL_MAKEINST`` variable within the recipe as a
workaround. For information on addressing race conditions, see the
- ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`"
+ ":ref:`dev-manual/common-tasks:debugging parallel make races`"
section in the Yocto Project Development Tasks Manual.
:term:`PATCHRESOLVE`
@@ -5580,7 +5580,7 @@ system and gives an overview of their function and contents.
For examples of how this data is used, see the
":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual and the
- ":ref:`dev-manual/dev-manual-common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
+ ":ref:`dev-manual/common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
section in the Yocto Project Development Tasks Manual. For more
information on the shared, global-state directory, see
:term:`STAGING_DIR_HOST`.
@@ -5713,7 +5713,7 @@ system and gives an overview of their function and contents.
Because manually managing ``PR`` can be cumbersome and error-prone,
an automated solution exists. See the
- ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`" section
+ ":ref:`dev-manual/common-tasks:working with a pr service`" section
in the Yocto Project Development Tasks Manual for more information.
:term:`PREFERRED_PROVIDER`
@@ -5738,7 +5738,7 @@ system and gives an overview of their function and contents.
PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
For more
- information, see the ":ref:`dev-manual/dev-manual-common-tasks:using virtual providers`"
+ information, see the ":ref:`dev-manual/common-tasks:using virtual providers`"
section in the Yocto Project Development Tasks Manual.
.. note::
@@ -5951,7 +5951,7 @@ system and gives an overview of their function and contents.
You must
set the variable if you want to automatically start a local :ref:`PR
- service <dev-manual/dev-manual-common-tasks:working with a pr service>`. You can
+ service <dev-manual/common-tasks:working with a pr service>`. You can
set ``PRSERV_HOST`` to other values to use a remote PR service.
@@ -5965,7 +5965,7 @@ system and gives an overview of their function and contents.
:term:`PTEST_ENABLED`
Specifies whether or not :ref:`Package
- Test <dev-manual/dev-manual-common-tasks:testing packages with ptest>` (ptest)
+ Test <dev-manual/common-tasks:testing packages with ptest>` (ptest)
functionality is enabled when building a recipe. You should not set
this variable directly. Enabling and disabling building Package Tests
at build time should be done by adding "ptest" to (or removing it
@@ -7000,7 +7000,7 @@ system and gives an overview of their function and contents.
various ``SPL_*`` variables used by the OpenEmbedded build system.
See the BeagleBone machine configuration example in the
- ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
+ ":ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
section in the Yocto Project Board Support Package Developer's Guide
for additional information.
@@ -7200,7 +7200,7 @@ system and gives an overview of their function and contents.
For information on limitations when inheriting the latest revision
of software using ``SRCREV``, see the :term:`AUTOREV` variable
description and the
- ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`"
+ ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
section, which is in the Yocto Project Development Tasks Manual.
:term:`SSTATE_DIR`
@@ -7660,7 +7660,7 @@ system and gives an overview of their function and contents.
:term:`SYSVINIT_ENABLED_GETTYS`
When using
- :ref:`SysVinit <dev-manual/dev-manual-common-tasks:enabling system services>`,
+ :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
specifies a space-separated list of the virtual terminals that should
run a `getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__
(allowing login), assuming :term:`USE_VT` is not set to
@@ -7946,7 +7946,7 @@ system and gives an overview of their function and contents.
file.
For more information on testing images, see the
- ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+ ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
:term:`TEST_SERIALCONTROL_CMD`
@@ -8022,7 +8022,7 @@ system and gives an overview of their function and contents.
TEST_SUITES = "test_A test_B"
For more information on testing images, see the
- ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+ ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual.
:term:`TEST_TARGET`
@@ -8042,7 +8042,7 @@ system and gives an overview of their function and contents.
You can provide the following arguments with ``TEST_TARGET``:
- *"qemu":* Boots a QEMU image and runs the tests. See the
- ":ref:`dev-manual/dev-manual-common-tasks:enabling runtime tests on qemu`" section
+ ":ref:`dev-manual/common-tasks:enabling runtime tests on qemu`" section
in the Yocto Project Development Tasks Manual for more
information.
@@ -8058,7 +8058,7 @@ system and gives an overview of their function and contents.
``meta/lib/oeqa/controllers/simpleremote.py``.
For information on running tests on hardware, see the
- ":ref:`dev-manual/dev-manual-common-tasks:enabling runtime tests on hardware`"
+ ":ref:`dev-manual/common-tasks:enabling runtime tests on hardware`"
section in the Yocto Project Development Tasks Manual.
:term:`TEST_TARGET_IP`
@@ -8096,7 +8096,7 @@ system and gives an overview of their function and contents.
For more information
on enabling, running, and writing these tests, see the
- ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`"
+ ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
section in the Yocto Project Development Tasks Manual and the
":ref:`testimage*.bbclass <ref-classes-testimage*>`" section.
@@ -8554,13 +8554,13 @@ system and gives an overview of their function and contents.
specifically set. Typically, you would set ``USE_DEVFS`` to "0" for a
statically populated ``/dev`` directory.
- See the ":ref:`dev-manual/dev-manual-common-tasks:selecting a device manager`" section in
+ See the ":ref:`dev-manual/common-tasks:selecting a device manager`" section in
the Yocto Project Development Tasks Manual for information on how to
use this variable.
:term:`USE_VT`
When using
- :ref:`SysVinit <dev-manual/dev-manual-common-tasks:enabling system services>`,
+ :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
determines whether or not to run a
`getty <http://en.wikipedia.org/wiki/Getty_%28Unix%29>`__ on any
virtual terminals in order to enable logging in through those
@@ -8735,7 +8735,7 @@ system and gives an overview of their function and contents.
OpenEmbedded build system to create a partitioned image
(image\ ``.wic``). For information on how to create a partitioned
image, see the
- ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`"
+ ":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section in the Yocto Project Development Tasks Manual. For details on
the kickstart file format, see the ":doc:`/ref-manual/ref-kickstart`" Chapter.
diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst
index fd04593d4..77c367809 100644
--- a/documentation/ref-manual/resources.rst
+++ b/documentation/ref-manual/resources.rst
@@ -23,7 +23,7 @@ The Yocto Project gladly accepts contributions. You can submit changes
to the project either by creating and sending pull requests, or by
submitting patches through email. For information on how to do both as
well as information on how to identify the maintainer for each area of
-code, see the ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`" section in the
+code, see the ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" section in the
Yocto Project Development Tasks Manual.
.. _resources-bugtracker:
@@ -47,7 +47,7 @@ A general procedure and guidelines exist for when you use Bugzilla to
submit a bug. For information on how to use Bugzilla to submit a bug
against the Yocto Project, see the following:
-- The ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`"
+- The ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
section in the Yocto Project Development Tasks Manual.
- The Yocto Project :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
diff --git a/documentation/sdk-manual/sdk-appendix-obtain.rst b/documentation/sdk-manual/sdk-appendix-obtain.rst
index 6b7128c27..8d4fe0964 100644
--- a/documentation/sdk-manual/sdk-appendix-obtain.rst
+++ b/documentation/sdk-manual/sdk-appendix-obtain.rst
@@ -81,7 +81,7 @@ As an alternative to locating and downloading an SDK installer, you can
build the SDK installer. Follow these steps:
1. *Set Up the Build Environment:* Be sure you are set up to use BitBake
- in a shell. See the ":ref:`dev-manual/dev-manual-start:preparing the build host`" section
+ in a shell. See the ":ref:`dev-manual/start:preparing the build host`" section
in the Yocto Project Development Tasks Manual for information on how
to get a build host ready that is either a native Linux machine or a
machine that uses CROPS.
@@ -89,9 +89,9 @@ build the SDK installer. Follow these steps:
2. *Clone the ``poky`` Repository:* You need to have a local copy of the
Yocto Project :term:`Source Directory`
(i.e. a local
- ``poky`` repository). See the ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" and
- possibly the ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" and
- ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`" sections
+ ``poky`` repository). See the ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" and
+ possibly the ":ref:`dev-manual/start:checking out by branch in poky`" and
+ ":ref:`dev-manual/start:checking out by tag in poky`" sections
all in the Yocto Project Development Tasks Manual for information on
how to clone the ``poky`` repository and check out the appropriate
branch for your work.
diff --git a/documentation/sdk-manual/sdk-intro.rst b/documentation/sdk-manual/sdk-intro.rst
index 5514c6767..66b12cdff 100644
--- a/documentation/sdk-manual/sdk-intro.rst
+++ b/documentation/sdk-manual/sdk-intro.rst
@@ -211,7 +211,7 @@ You just need to follow these general steps:
tools to develop your application. If you need to separately install
and use the QEMU emulator, you can go to `QEMU Home
Page <http://wiki.qemu.org/Main_Page>`__ to download and learn about
- the emulator. See the ":doc:`/dev-manual/dev-manual-qemu`" chapter in the
+ the emulator. See the ":doc:`/dev-manual/qemu`" chapter in the
Yocto Project Development Tasks Manual for information on using QEMU
within the Yocto Project.
diff --git a/documentation/test-manual/intro.rst b/documentation/test-manual/intro.rst
index 6168ad770..3dc64bcd4 100644
--- a/documentation/test-manual/intro.rst
+++ b/documentation/test-manual/intro.rst
@@ -142,7 +142,7 @@ thefollowing types of tests:
- *Package Testing:* A Package Test (ptest) runs tests against packages
built by the OpenEmbedded build system on the target machine. See the
:ref:`Testing Packages With
- ptest <dev-manual/dev-manual-common-tasks:Testing Packages With ptest>` section
+ ptest <dev-manual/common-tasks:Testing Packages With ptest>` section
in the Yocto Project Development Tasks Manual and the
":yocto_wiki:`Ptest </Ptest>`" Wiki page for more
information on Ptest.
diff --git a/documentation/toaster-manual/reference.rst b/documentation/toaster-manual/reference.rst
index c3f0fef0a..4da415d86 100644
--- a/documentation/toaster-manual/reference.rst
+++ b/documentation/toaster-manual/reference.rst
@@ -67,7 +67,7 @@ layers.
For general information on layers, see the
":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
section in the Yocto Project Overview and Concepts Manual. For information on how
-to create layers, see the ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+to create layers, see the ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual.
Configuring Toaster to Hook Into Your Layer Index
diff --git a/documentation/toaster-manual/start.rst b/documentation/toaster-manual/start.rst
index 888337416..c687a8253 100644
--- a/documentation/toaster-manual/start.rst
+++ b/documentation/toaster-manual/start.rst
@@ -14,7 +14,7 @@ Setting Up the Basic System Requirements
Before you can use Toaster, you need to first set up your build system
to run the Yocto Project. To do this, follow the instructions in the
-":ref:`dev-manual/dev-manual-start:preparing the build host`" section of
+":ref:`dev-manual/start:preparing the build host`" section of
the Yocto Project Development Tasks Manual. For Ubuntu/Debian, you might
also need to do an additional install of pip3. ::
diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst
index 3663f5336..997f599f5 100644
--- a/documentation/transitioning-to-a-custom-environment.rst
+++ b/documentation/transitioning-to-a-custom-environment.rst
@@ -42,7 +42,7 @@ Transitioning to a custom environment for systems development
You might want to start with the build specification that Poky provides
(which is reference embedded distribution) and then add your newly chosen
layers to that. Here is the information :ref:`about adding layers
- <dev-manual/dev-manual-common-tasks:Understanding and Creating Layers>`.
+ <dev-manual/common-tasks:Understanding and Creating Layers>`.
#. **Based on the layers you've chosen, make needed changes in your
configuration**.
@@ -58,7 +58,7 @@ Transitioning to a custom environment for systems development
releases. If you are using a Yocto Project release earlier than 2.4, use the
``yocto-layer create`` tool. The ``bitbake-layers`` tool also provides a number
of other useful layer-related commands. See
- :ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the
+ :ref:`dev-manual/common-tasks:creating a general layer using the
\`\`bitbake-layers\`\` script` section.
#. **Create your own layer for the BSP you're going to use**.
@@ -79,7 +79,7 @@ Transitioning to a custom environment for systems development
process of refinement. Start by getting each step of the build process
working beginning with fetching all the way through packaging. Next, run the
software on your target and refine further as needed. See :ref:`Writing a New
- Recipe <dev-manual/dev-manual-common-tasks:writing a new recipe>` in the
+ Recipe <dev-manual/common-tasks:writing a new recipe>` in the
Yocto Project Development Tasks Manual for more information.
#. **Now you're ready to create an image recipe**.
@@ -103,7 +103,7 @@ Transitioning to a custom environment for systems development
needs to change for your distribution. If you find yourself adding a lot of
configuration to your local.conf file aside from paths and other typical
local settings, it's time to :ref:`consider creating your own distribution
- <dev-manual/dev-manual-common-tasks:creating your own distribution>`.
+ <dev-manual/common-tasks:creating your own distribution>`.
You can add product specifications that can customize the distribution if
needed in other layers. You can also add other functionality specific to the
diff --git a/documentation/what-i-wish-id-known.rst b/documentation/what-i-wish-id-known.rst
index 563594b52..a8902c0be 100644
--- a/documentation/what-i-wish-id-known.rst
+++ b/documentation/what-i-wish-id-known.rst
@@ -132,7 +132,7 @@ contact us with other suggestions.
say "bitbake foo" where "foo" is the name for a specific recipe. As you
become more advanced using the Yocto Project, and if builds are failing, it
can be useful to make sure the fetch itself works as desired. Here are some
- valuable links: :ref:`dev-manual/dev-manual-common-tasks:Using a Development
+ valuable links: :ref:`dev-manual/common-tasks:Using a Development
Shell` for information on how to build and run a specific task using
devshell. Also, the :ref:`SDK manual shows how to build out a specific recipe
<sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`.
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 06/10] kernel-dev: remove 'kernel-dev' from filenames
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
` (4 preceding siblings ...)
2020-12-03 21:38 ` [PATCH 05/10] dev-manual: remove 'dev-manual' " Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 07/10] profile-manual: remove 'profile-manual' " Nicolas Dechesne
` (3 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
All filenames duplicate the 'manual name', which is not needed, and
make all references longer than they should. Rename all files to be as
consise as possible, and fix all references
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
documentation/bsp-guide/bsp.rst | 4 +-
documentation/dev-manual/common-tasks.rst | 4 +-
documentation/dev-manual/start.rst | 2 +-
.../{kernel-dev-advanced.rst => advanced.rst} | 18 +++----
.../{kernel-dev-common.rst => common.rst} | 48 +++++++++----------
...ev-concepts-appx.rst => concepts-appx.rst} | 14 +++---
.../{kernel-dev-faq.rst => faq.rst} | 8 ++--
documentation/kernel-dev/index.rst | 12 ++---
.../{kernel-dev-intro.rst => intro.rst} | 16 +++----
...rnel-dev-maint-appx.rst => maint-appx.rst} | 2 +-
.../overview-manual-concepts.rst | 2 +-
...verview-manual-development-environment.rst | 2 +-
documentation/ref-manual/ref-classes.rst | 2 +-
documentation/ref-manual/ref-tasks.rst | 8 ++--
documentation/ref-manual/ref-variables.rst | 14 +++---
15 files changed, 78 insertions(+), 78 deletions(-)
rename documentation/kernel-dev/{kernel-dev-advanced.rst => advanced.rst} (97%)
rename documentation/kernel-dev/{kernel-dev-common.rst => common.rst} (97%)
rename documentation/kernel-dev/{kernel-dev-concepts-appx.rst => concepts-appx.rst} (97%)
rename documentation/kernel-dev/{kernel-dev-faq.rst => faq.rst} (89%)
rename documentation/kernel-dev/{kernel-dev-intro.rst => intro.rst} (91%)
rename documentation/kernel-dev/{kernel-dev-maint-appx.rst => maint-appx.rst} (99%)
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 6d3ccd49b..e20df3f6b 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -693,7 +693,7 @@ BSP settings to the kernel, thus configuring the kernel for your
particular BSP.
You can find more information on what your append file should contain in
-the ":ref:`kernel-dev/kernel-dev-common:creating the append file`" section
+the ":ref:`kernel-dev/common:creating the append file`" section
in the Yocto Project Linux Kernel Development Manual.
An alternate scenario is when you create your own kernel recipe for the
@@ -1197,7 +1197,7 @@ Use these steps to create a BSP layer:
``recipes-kernel/linux`` by either using a kernel append file or a
new custom kernel recipe file (e.g. ``yocto-linux_4.12.bb``). The BSP
layers mentioned in the previous step also contain different kernel
- examples. See the ":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`"
+ examples. See the ":ref:`kernel-dev/common:modifying an existing recipe`"
section in the Yocto Project Linux Kernel Development Manual for
information on how to create a custom kernel.
diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index c627491f3..fe3667bfb 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -2874,7 +2874,7 @@ the ``SRC_URI`` and adding the machine to the expression in
COMPATIBLE_MACHINE = '(qemux86|qemumips)'
For more information on ``defconfig`` files, see the
-":ref:`kernel-dev/kernel-dev-common:changing the configuration`"
+":ref:`kernel-dev/common:changing the configuration`"
section in the Yocto Project Linux Kernel Development Manual.
Adding a Formfactor Configuration File
@@ -4084,7 +4084,7 @@ view file dependencies in a human-readable form:
directory.
For more information on configuration fragments, see the
- ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
+ ":ref:`kernel-dev/common:creating configuration fragments`"
section in the Yocto Project Linux Kernel Development Manual.
- ``bitbake -u taskexp -g bitbake_target``: Using the BitBake command
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst
index 85ec97b9e..8244d68ed 100644
--- a/documentation/dev-manual/start.rst
+++ b/documentation/dev-manual/start.rst
@@ -288,7 +288,7 @@ Package (BSP) development and kernel development:
section in the Yocto Project Board Support Package (BSP) Developer's
Guide.
-- *Kernel Development:* See the ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+- *Kernel Development:* See the ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
section in the Yocto Project Linux Kernel Development Manual.
Setting Up a Native Linux Host
diff --git a/documentation/kernel-dev/kernel-dev-advanced.rst b/documentation/kernel-dev/advanced.rst
similarity index 97%
rename from documentation/kernel-dev/kernel-dev-advanced.rst
rename to documentation/kernel-dev/advanced.rst
index ddb31edca..163560b69 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.rst
+++ b/documentation/kernel-dev/advanced.rst
@@ -243,7 +243,7 @@ two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the
CONFIG_X86_BIGSMP=y
You can find general information on configuration
-fragment files in the ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`" section.
+fragment files in the ":ref:`kernel-dev/common:creating configuration fragments`" section.
Within the ``smp.scc`` file, the
:term:`KFEATURE_DESCRIPTION`
@@ -264,7 +264,7 @@ non-hardware fragment.
fragment.
As described in the
-":ref:`kernel-dev/kernel-dev-common:validating configuration`" section, you can
+":ref:`kernel-dev/common:validating configuration`" section, you can
use the following BitBake command to audit your configuration:
::
@@ -325,8 +325,8 @@ for the five patches in the directory.
You can create a typical ``.patch`` file using ``diff -Nurp`` or
``git format-patch`` commands. For information on how to create patches,
-see the ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
-and ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+see the ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
+and ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
sections.
Features
@@ -388,7 +388,7 @@ type as follows:
You can find kernel recipes in the ``meta/recipes-kernel/linux`` directory
of the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
(e.g. ``poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb``). See the
- ":ref:`kernel-dev/kernel-dev-advanced:using kernel metadata in a recipe`"
+ ":ref:`kernel-dev/advanced:using kernel metadata in a recipe`"
section for more information.
Three kernel types ("standard", "tiny", and "preempt-rt") are supported
@@ -453,7 +453,7 @@ and ``patch`` commands, respectively.
It is not strictly necessary to create a kernel type ``.scc``
file. The Board Support Package (BSP) file can implicitly define the
kernel type using a ``define`` :term:`KTYPE` ``myktype`` line. See the
- ":ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`" section for more
+ ":ref:`kernel-dev/advanced:bsp descriptions`" section for more
information.
BSP Descriptions
@@ -555,7 +555,7 @@ You can see that in the BeagleBone example with the following:
include beaglebone.scc
For information on how to break a complete ``.config`` file into the various
-configuration fragments, see the ":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`" section.
+configuration fragments, see the ":ref:`kernel-dev/common:creating configuration fragments`" section.
Finally, if you have any configurations specific to the hardware that
are not in a ``*.scc`` file, you can include them as follows:
@@ -696,7 +696,7 @@ good approach if you are working with Linux kernel sources you do not
control or if you just do not want to maintain a Linux kernel Git
repository on your own. For partial information on how you can define
kernel Metadata in the recipe-space, see the
-":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`" section.
+":ref:`kernel-dev/common:modifying an existing recipe`" section.
Conversely, if you are actively developing a kernel and are already
maintaining a Linux kernel Git repository of your own, you might find it
@@ -716,7 +716,7 @@ modifying
``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to
a recipe in your layer, ``FILESEXTRAPATHS`` is typically set to
``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``.
-See the ":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`"
+See the ":ref:`kernel-dev/common:modifying an existing recipe`"
section for more information.
Here is an example that shows a trivial tree of kernel Metadata stored
diff --git a/documentation/kernel-dev/kernel-dev-common.rst b/documentation/kernel-dev/common.rst
similarity index 97%
rename from documentation/kernel-dev/kernel-dev-common.rst
rename to documentation/kernel-dev/common.rst
index 4bb553f8d..403a63d58 100644
--- a/documentation/kernel-dev/kernel-dev-common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -49,7 +49,7 @@ Getting Ready to Develop Using ``devtool``
Follow these steps to prepare to update the kernel image using
``devtool``. Completing this procedure leaves you with a clean kernel
image and ready to make modifications as described in the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
section:
1. *Initialize the BitBake Environment:* Before building an extensible
@@ -212,7 +212,7 @@ section:
At this point you have set up to start making modifications to the
kernel by using the extensible SDK. For a continued example, see the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
section.
Getting Ready for Traditional Kernel Development
@@ -226,7 +226,7 @@ you will be editing these files.
Follow these steps to prepare to update the kernel image using
traditional kernel development flow with the Yocto Project. Completing
this procedure leaves you ready to make modifications to the kernel
-source as described in the ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+source as described in the ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
section:
1. *Initialize the BitBake Environment:* Before you can do anything
@@ -457,11 +457,11 @@ the :term:`Source Directory` in
Modifying an existing recipe can consist of the following:
-- :ref:`kernel-dev/kernel-dev-common:creating the append file`
+- :ref:`kernel-dev/common:creating the append file`
-- :ref:`kernel-dev/kernel-dev-common:applying patches`
+- :ref:`kernel-dev/common:applying patches`
-- :ref:`kernel-dev/kernel-dev-common:changing the configuration`
+- :ref:`kernel-dev/common:changing the configuration`
Before modifying an existing recipe, be sure that you have created a
minimal, custom layer from which you can work. See the "`Creating and
@@ -642,9 +642,9 @@ and applies the patches before building the kernel.
For a detailed example showing how to patch the kernel using
``devtool``, see the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
and
-":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
sections.
Changing the Configuration
@@ -769,7 +769,7 @@ the extensible SDK and ``devtool``.
Before attempting this procedure, be sure you have performed the
steps to get ready for updating the kernel as described in the
- ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+ ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
section.
Patching the kernel involves changing or adding configurations to an
@@ -782,7 +782,7 @@ output at boot time through ``printk`` statements in the kernel's
``calibrate.c`` source code file. Applying the patch and booting the
modified image causes the added messages to appear on the emulator's
console. The example is a continuation of the setup procedure found in
-the ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``" Section.
+the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Section.
1. *Check Out the Kernel Source Files:* First you must use ``devtool``
to checkout the kernel source code in its workspace. Be sure you are
@@ -791,7 +791,7 @@ the ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devto
.. note::
See this step in the
- ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+ ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
section for more information.
Use the following ``devtool`` command to check out the code:
@@ -912,7 +912,7 @@ the ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devto
.. note::
See Step 3 of the
- ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+ ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
section for information on setting up this layer.
Once the command
@@ -935,14 +935,14 @@ Using Traditional Kernel Development to Patch the Kernel
The steps in this procedure show you how you can patch the kernel using
traditional kernel development (i.e. not using ``devtool`` and the
extensible SDK as described in the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
section).
.. note::
Before attempting this procedure, be sure you have performed the
steps to get ready for updating the kernel as described in the
- ":ref:`kernel-dev/kernel-dev-common:getting ready for traditional kernel development`"
+ ":ref:`kernel-dev/common:getting ready for traditional kernel development`"
section.
Patching the kernel involves changing or adding configurations to an
@@ -1190,9 +1190,9 @@ the tool and save your changes to create an updated version of the
You can use the entire ``.config`` file as the ``defconfig`` file. For
information on ``defconfig`` files, see the
- ":ref:`kernel-dev/kernel-dev-common:changing the configuration`",
- ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`",
- and ":ref:`kernel-dev/kernel-dev-common:creating a \`\`defconfig\`\` file`"
+ ":ref:`kernel-dev/common:changing the configuration`",
+ ":ref:`kernel-dev/common:using an "in-tree" \`\`defconfig\`\` file`",
+ and ":ref:`kernel-dev/common:creating a \`\`defconfig\`\` file`"
sections.
Consider an example that configures the "CONFIG_SMP" setting for the
@@ -1320,7 +1320,7 @@ appear in the ``.config`` file, which is in the :term:`Build Directory`.
For more information about where the ``.config`` file is located, see the
example in the
- ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
+ ":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
section.
It is simple to create a configuration fragment. One method is to use
@@ -1377,7 +1377,7 @@ information on how to use the output as a configuration fragment.
.. note::
You can also use this method to create configuration fragments for a
- BSP. See the ":ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`"
+ BSP. See the ":ref:`kernel-dev/advanced:bsp descriptions`"
section for more information.
Where do you put your configuration fragment files? You can place these
@@ -1423,7 +1423,7 @@ when you override a policy configuration in a hardware configuration
fragment.
In order to run this task, you must have an existing ``.config`` file.
-See the ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``" section for
+See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" section for
information on how to create a configuration file.
Following is sample output from the ``do_kernel_configcheck`` task:
@@ -1496,7 +1496,7 @@ and
tasks until they produce no warnings.
For more information on how to use the ``menuconfig`` tool, see the
-:ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\`` section.
+:ref:`kernel-dev/common:using \`\`menuconfig\`\`` section.
Fine-Tuning the Kernel Configuration File
-----------------------------------------
@@ -1612,7 +1612,7 @@ source directory. Follow these steps to clean up the version string:
Depending on your particular kernel development workflow, the
commands you use to rebuild the kernel might differ. For information
on building the kernel image when using ``devtool``, see the
- ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+ ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
section. For
information on building the kernel image when using Bitbake, see the
"`Using Traditional Kernel Development to Patch the
@@ -1942,7 +1942,7 @@ Adding Recipe-Space Kernel Features
===================================
You can add kernel features in the
-:ref:`recipe-space <kernel-dev/kernel-dev-advanced:recipe-space metadata>`
+:ref:`recipe-space <kernel-dev/advanced:recipe-space metadata>`
by using the :term:`KERNEL_FEATURES`
variable and by specifying the feature's ``.scc`` file path in the
:term:`SRC_URI` statement. When you
@@ -1961,7 +1961,7 @@ OpenEmbedded build system searches all forms of kernel Metadata on the
``SRC_URI`` statement regardless of whether the Metadata is in the
"kernel-cache", system kernel Metadata, or a recipe-space Metadata (i.e.
part of the kernel recipe). See the
-":ref:`kernel-dev/kernel-dev-advanced:kernel metadata location`" section for
+":ref:`kernel-dev/advanced:kernel metadata location`" section for
additional information.
When you specify the feature's ``.scc`` file on the ``SRC_URI``
diff --git a/documentation/kernel-dev/kernel-dev-concepts-appx.rst b/documentation/kernel-dev/concepts-appx.rst
similarity index 97%
rename from documentation/kernel-dev/kernel-dev-concepts-appx.rst
rename to documentation/kernel-dev/concepts-appx.rst
index 470d6ce1c..865f6d8be 100644
--- a/documentation/kernel-dev/kernel-dev-concepts-appx.rst
+++ b/documentation/kernel-dev/concepts-appx.rst
@@ -71,7 +71,7 @@ and included with Yocto Project releases:
and configurations for the linux-yocto kernel tree. This repository
is useful when working on the linux-yocto kernel. For more
information on this "Advanced Kernel Metadata", see the
- ":doc:`kernel-dev-advanced`" Chapter.
+ ":doc:`/kernel-dev/advanced`" Chapter.
- *linux-yocto-dev:* A development kernel based on the latest
upstream release candidate available.
@@ -293,13 +293,13 @@ ways:
- *Files Accessed While using devtool:* ``devtool``, which is
available with the Yocto Project, is the preferred method by which to
- modify the kernel. See the ":ref:`kernel-dev/kernel-dev-intro:kernel modification workflow`" section.
+ modify the kernel. See the ":ref:`kernel-dev/intro:kernel modification workflow`" section.
- *Cloned Repository:* If you are working in the kernel all the time,
you probably would want to set up your own local Git repository of
the Yocto Linux kernel tree. For information on how to clone a Yocto
Linux kernel Git repository, see the
- ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+ ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
section.
- *Temporary Source Files from a Build:* If you just need to make some
@@ -327,11 +327,11 @@ source files used during the build.
Again, for additional information on the Yocto Project kernel's
architecture and its branching strategy, see the
-":ref:`kernel-dev/kernel-dev-concepts-appx:yocto linux kernel architecture and branching strategies`"
+":ref:`kernel-dev/concepts-appx:yocto linux kernel architecture and branching strategies`"
section. You can also reference the
-":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
and
-":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
sections for detailed example that modifies the kernel.
Determining Hardware and Non-Hardware Features for the Kernel Configuration Audit Phase
@@ -341,7 +341,7 @@ This section describes part of the kernel configuration audit phase that
most developers can ignore. For general information on kernel
configuration including ``menuconfig``, ``defconfig`` files, and
configuration fragments, see the
-":ref:`kernel-dev/kernel-dev-common:configuring the kernel`" section.
+":ref:`kernel-dev/common:configuring the kernel`" section.
During this part of the audit phase, the contents of the final
``.config`` file are compared against the fragments specified by the
diff --git a/documentation/kernel-dev/kernel-dev-faq.rst b/documentation/kernel-dev/faq.rst
similarity index 89%
rename from documentation/kernel-dev/kernel-dev-faq.rst
rename to documentation/kernel-dev/faq.rst
index 54623453a..c2106f81e 100644
--- a/documentation/kernel-dev/kernel-dev-faq.rst
+++ b/documentation/kernel-dev/faq.rst
@@ -13,21 +13,21 @@ How do I use my own Linux kernel ``.config`` file?
--------------------------------------------------
Refer to the
-":ref:`kernel-dev/kernel-dev-common:changing the configuration`"
+":ref:`kernel-dev/common:changing the configuration`"
section for information.
How do I create configuration fragments?
----------------------------------------
A: Refer to the
-":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
+":ref:`kernel-dev/common:creating configuration fragments`"
section for information.
How do I use my own Linux kernel sources?
-----------------------------------------
Refer to the
-":ref:`kernel-dev/kernel-dev-common:working with your own sources`"
+":ref:`kernel-dev/common:working with your own sources`"
section for information.
How do I install/not-install the kernel image on the rootfs?
@@ -63,7 +63,7 @@ machine:
MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123"
For more information, see the
-":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`" section.
+":ref:`kernel-dev/common:incorporating out-of-tree modules`" section.
How do I change the Linux kernel command line?
----------------------------------------------
diff --git a/documentation/kernel-dev/index.rst b/documentation/kernel-dev/index.rst
index 55b42ed99..a8848ec8c 100644
--- a/documentation/kernel-dev/index.rst
+++ b/documentation/kernel-dev/index.rst
@@ -10,12 +10,12 @@ Yocto Project Linux Kernel Development Manual
:caption: Table of Contents
:numbered:
- kernel-dev-intro
- kernel-dev-common
- kernel-dev-advanced
- kernel-dev-concepts-appx
- kernel-dev-maint-appx
- kernel-dev-faq
+ intro
+ common
+ advanced
+ concepts-appx
+ maint-appx
+ faq
history
.. include:: /boilerplate.rst
diff --git a/documentation/kernel-dev/kernel-dev-intro.rst b/documentation/kernel-dev/intro.rst
similarity index 91%
rename from documentation/kernel-dev/kernel-dev-intro.rst
rename to documentation/kernel-dev/intro.rst
index 3987b0e59..2b60616df 100644
--- a/documentation/kernel-dev/kernel-dev-intro.rst
+++ b/documentation/kernel-dev/intro.rst
@@ -27,7 +27,7 @@ and supported for at least one additional Yocto Project release. As they
align, these previous releases are updated to include the latest from
the Long Term Support Initiative (LTSI) project. You can learn more
about Yocto Linux kernels and LTSI in the
-":ref:`kernel-dev/kernel-dev-concepts-appx:yocto project kernel development and maintenance`" section.
+":ref:`kernel-dev/concepts-appx:yocto project kernel development and maintenance`" section.
Also included is a Yocto Linux kernel development recipe
(``linux-yocto-dev.bb``) should you want to work with the very latest in
@@ -36,7 +36,7 @@ upstream Yocto Linux kernel development and kernel Metadata development.
.. note::
For more on Yocto Linux kernels, see the
- ":ref:`kernel-dev/kernel-dev-concepts-appx:yocto project kernel development and maintenance`"
+ ":ref:`kernel-dev/concepts-appx:yocto project kernel development and maintenance`"
section.
The Yocto Project also provides a powerful set of kernel tools for
@@ -124,13 +124,13 @@ general information and references for further information.
Using ``devtool`` and the eSDK requires that you have a clean build
of the image and that you are set up with the appropriate eSDK. For
more information, see the
- ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+ ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
section.
Using traditional kernel development requires that you have the
kernel source available in an isolated local Git repository. For more
information, see the
- ":ref:`kernel-dev/kernel-dev-common:getting ready for traditional kernel development`"
+ ":ref:`kernel-dev/common:getting ready for traditional kernel development`"
section.
3. *Make Changes to the Kernel Source Code if applicable:* Modifying the
@@ -138,17 +138,17 @@ general information and references for further information.
if you have to do this, you make the changes to the files in the
eSDK's Build Directory if you are using ``devtool``. For more
information, see the
- ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+ ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
section.
If you are using traditional kernel development, you edit the source
files in the kernel's local Git repository. For more information, see the
- ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+ ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
section.
4. *Make Kernel Configuration Changes if Applicable:* If your situation
calls for changing the kernel's configuration, you can use
- :ref:`menuconfig <kernel-dev/kernel-dev-common:using \`\`menuconfig\`\`>`,
+ :ref:`menuconfig <kernel-dev/common:using \`\`menuconfig\`\`>`,
which allows you to
interactively develop and test the configuration changes you are
making to the kernel. Saving changes you make with ``menuconfig``
@@ -165,7 +165,7 @@ general information and references for further information.
``menuconfig`` and you have saved them, you can directly compare the
resulting ``.config`` file against an existing original and gather
those changes into a
- :ref:`configuration fragment file <kernel-dev/kernel-dev-common:creating configuration fragments>` to be
+ :ref:`configuration fragment file <kernel-dev/common:creating configuration fragments>` to be
referenced from within the kernel's ``.bbappend`` file.
Additionally, if you are working in a BSP layer and need to modify
diff --git a/documentation/kernel-dev/kernel-dev-maint-appx.rst b/documentation/kernel-dev/maint-appx.rst
similarity index 99%
rename from documentation/kernel-dev/kernel-dev-maint-appx.rst
rename to documentation/kernel-dev/maint-appx.rst
index ec1c0ac03..89f4b4334 100644
--- a/documentation/kernel-dev/kernel-dev-maint-appx.rst
+++ b/documentation/kernel-dev/maint-appx.rst
@@ -37,7 +37,7 @@ kernel that branches off ``linux.org`` version 4.12 and the
For more information on
how to set up a local Git repository of the Yocto Project Linux kernel
files, see the
-":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
section.
Once you have cloned the kernel Git repository and the cache of Metadata
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/overview-manual-concepts.rst
index d2e335e80..a10670fc5 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/overview-manual-concepts.rst
@@ -833,7 +833,7 @@ Yocto Project Development Tasks Manual. You can also see the
":ref:`sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (SDK) manual and the
-":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
+":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
section in the Yocto Project Linux Kernel Development Manual.
Configuration, Compilation, and Staging
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index e03b4cdc6..9a2997d9f 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -117,7 +117,7 @@ methods exist for you to do work in the Yocto Project environment:
The :doc:`/kernel-dev/index` provides kernel-related
development information. For specifics on development host
preparation, see the
- ":ref:`kernel-dev/kernel-dev-common:preparing the build host to work on the kernel`"
+ ":ref:`kernel-dev/common:preparing the build host to work on the kernel`"
section in the Yocto Project Linux Kernel Development Manual.
- *Using Toaster:* The other Yocto Project development method that
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst
index 4147044ea..914ca4232 100644
--- a/documentation/ref-manual/ref-classes.rst
+++ b/documentation/ref-manual/ref-classes.rst
@@ -1596,7 +1596,7 @@ and implements the :ref:`ref-tasks-compile` and
everything needed to build and package a kernel module.
For general information on out-of-tree Linux kernel modules, see the
-":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
+":ref:`kernel-dev/common:incorporating out-of-tree modules`"
section in the Yocto Project Linux Kernel Development Manual.
.. _ref-classes-module-base:
diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst
index 89731d459..768c10eeb 100644
--- a/documentation/ref-manual/ref-tasks.rst
+++ b/documentation/ref-manual/ref-tasks.rst
@@ -693,7 +693,7 @@ from the command line as follows:
$ bitbake linux-yocto -c diffconfig
For more information, see the
-":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`"
+":ref:`kernel-dev/common:creating configuration fragments`"
section in the Yocto Project Linux Kernel Development Manual.
.. _ref-tasks-kernel_checkout:
@@ -724,7 +724,7 @@ following command:
$ bitbake linux-yocto -c kernel_configcheck -f
For more information, see the
-":ref:`kernel-dev/kernel-dev-common:validating configuration`"
+":ref:`kernel-dev/common:validating configuration`"
section in the Yocto Project Linux Kernel Development Manual.
.. _ref-tasks-kernel_configme:
@@ -756,7 +756,7 @@ tool, which you then use to modify the kernel configuration.
$ bitbake linux-yocto -c menuconfig
-See the ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
+See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
section in the Yocto Project Linux Kernel Development Manual for more
information on this configuration tool.
@@ -780,7 +780,7 @@ which can then be applied by subsequent tasks such as
Runs ``make menuconfig`` for the kernel. For information on
``menuconfig``, see the
-":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
+":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
section in the Yocto Project Linux Kernel Development Manual.
.. _ref-tasks-savedefconfig:
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index 65f64b91a..d98e35817 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -3723,7 +3723,7 @@ system and gives an overview of their function and contents.
- qemu
- mips
- You define the ``KARCH`` variable in the :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`.
+ You define the ``KARCH`` variable in the :ref:`kernel-dev/advanced:bsp descriptions`.
:term:`KBRANCH`
A regular expression used by the build process to explicitly identify
@@ -3793,7 +3793,7 @@ system and gives an overview of their function and contents.
For more
information on how to use the ``KBUILD_DEFCONFIG`` variable, see the
- ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`"
+ ":ref:`kernel-dev/common:using an "in-tree" \`\`defconfig\`\` file`"
section in the Yocto Project Linux Kernel Development Manual.
:term:`KERNEL_ALT_IMAGETYPE`
@@ -4029,7 +4029,7 @@ system and gives an overview of their function and contents.
of the :term:`STAGING_KERNEL_DIR` within
the :ref:`module <ref-classes-module>` class. For information on
how this variable is used, see the
- ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
+ ":ref:`kernel-dev/common:incorporating out-of-tree modules`"
section in the Yocto Project Linux Kernel Development Manual.
To help maximize compatibility with out-of-tree drivers used to build
@@ -4043,7 +4043,7 @@ system and gives an overview of their function and contents.
of the :term:`STAGING_KERNEL_DIR` within
the :ref:`module <ref-classes-module>` class. For information on
how this variable is used, see the
- ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`"
+ ":ref:`kernel-dev/common:incorporating out-of-tree modules`"
section in the Yocto Project Linux Kernel Development Manual.
To help maximize compatibility with out-of-tree drivers used to build
@@ -4108,13 +4108,13 @@ system and gives an overview of their function and contents.
:term:`KTYPE`
Defines the kernel type to be used in assembling the configuration.
The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
- kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+ kernel types. See the ":ref:`kernel-dev/advanced:kernel types`"
section in the
Yocto Project Linux Kernel Development Manual for more information on
kernel types.
You define the ``KTYPE`` variable in the
- :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`. The
+ :ref:`kernel-dev/advanced:bsp descriptions`. The
value you use must match the value used for the
:term:`LINUX_KERNEL_TYPE` value used by the
kernel recipe.
@@ -4343,7 +4343,7 @@ system and gives an overview of their function and contents.
:term:`LINUX_KERNEL_TYPE`
Defines the kernel type to be used in assembling the configuration.
The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
- kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`"
+ kernel types. See the ":ref:`kernel-dev/advanced:kernel types`"
section in the
Yocto Project Linux Kernel Development Manual for more information on
kernel types.
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 07/10] profile-manual: remove 'profile-manual' from filenames
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
` (5 preceding siblings ...)
2020-12-03 21:38 ` [PATCH 06/10] kernel-dev: remove 'kernel-dev' " Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 08/10] overview-manual: remove 'overview-manual' " Nicolas Dechesne
` (2 subsequent siblings)
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
All filenames duplicate the 'manual name', which is not needed, and
make all references longer than they should. Rename all files to be as
consise as possible, and fix all references
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
.../{profile-manual-arch.rst => arch.rst} | 0
...rofile-manual-examples.rst => examples.rst} | 0
documentation/profile-manual/index.rst | 8 ++++----
.../{profile-manual-intro.rst => intro.rst} | 0
.../{profile-manual-usage.rst => usage.rst} | 18 +++++++++---------
5 files changed, 13 insertions(+), 13 deletions(-)
rename documentation/profile-manual/{profile-manual-arch.rst => arch.rst} (100%)
rename documentation/profile-manual/{profile-manual-examples.rst => examples.rst} (100%)
rename documentation/profile-manual/{profile-manual-intro.rst => intro.rst} (100%)
rename documentation/profile-manual/{profile-manual-usage.rst => usage.rst} (99%)
diff --git a/documentation/profile-manual/profile-manual-arch.rst b/documentation/profile-manual/arch.rst
similarity index 100%
rename from documentation/profile-manual/profile-manual-arch.rst
rename to documentation/profile-manual/arch.rst
diff --git a/documentation/profile-manual/profile-manual-examples.rst b/documentation/profile-manual/examples.rst
similarity index 100%
rename from documentation/profile-manual/profile-manual-examples.rst
rename to documentation/profile-manual/examples.rst
diff --git a/documentation/profile-manual/index.rst b/documentation/profile-manual/index.rst
index 5ec5b9e75..6e54133e0 100644
--- a/documentation/profile-manual/index.rst
+++ b/documentation/profile-manual/index.rst
@@ -10,10 +10,10 @@ Yocto Project Profiling and Tracing Manual
:caption: Table of Contents
:numbered:
- profile-manual-intro
- profile-manual-arch
- profile-manual-usage
- profile-manual-examples
+ intro
+ arch
+ usage
+ examples
history
.. include:: /boilerplate.rst
diff --git a/documentation/profile-manual/profile-manual-intro.rst b/documentation/profile-manual/intro.rst
similarity index 100%
rename from documentation/profile-manual/profile-manual-intro.rst
rename to documentation/profile-manual/intro.rst
diff --git a/documentation/profile-manual/profile-manual-usage.rst b/documentation/profile-manual/usage.rst
similarity index 99%
rename from documentation/profile-manual/profile-manual-usage.rst
rename to documentation/profile-manual/usage.rst
index cc403a554..418f4e993 100644
--- a/documentation/profile-manual/profile-manual-usage.rst
+++ b/documentation/profile-manual/usage.rst
@@ -45,7 +45,7 @@ Perf Setup
----------
For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section.
+outlined in the ":ref:`profile-manual/intro:General Setup`" section.
In particular, you'll get the most mileage out of perf if you profile an
image built with the following in your ``local.conf`` file: ::
@@ -1183,7 +1183,7 @@ ftrace Setup
------------
For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section.
+outlined in the ":ref:`profile-manual/intro:General Setup`" section.
ftrace, trace-cmd, and kernelshark run on the target system, and are
ready to go out-of-the-box - no additional setup is necessary. For the
@@ -1871,7 +1871,7 @@ having done a build: ::
So essentially what you need to
do is build an SDK image or image with 'tools-profile' as detailed in
-the ":ref:`profile-manual/profile-manual-intro:General Setup`" section of this
+the ":ref:`profile-manual/intro:General Setup`" section of this
manual, and boot the resulting target image.
.. note::
@@ -1954,7 +1954,7 @@ Sysprof Setup
-------------
For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section.
+outlined in the ":ref:`profile-manual/intro:General Setup`" section.
Sysprof is a GUI-based application that runs on the target system. For
the rest of this document we assume you've ssh'ed to the host and will
@@ -2025,7 +2025,7 @@ LTTng Setup
-----------
For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section.
+outlined in the ":ref:`profile-manual/intro:General Setup`" section.
LTTng is run on the target system by ssh'ing to it.
Collecting and Viewing Traces
@@ -2033,7 +2033,7 @@ Collecting and Viewing Traces
Once you've applied the above commits and built and booted your image
(you need to build the core-image-sato-sdk image or use one of the other
-methods described in the ":ref:`profile-manual/profile-manual-intro:General Setup`" section), you're ready to start
+methods described in the ":ref:`profile-manual/intro:General Setup`" section), you're ready to start
tracing.
Collecting and viewing a trace on the target (inside a shell)
@@ -2230,14 +2230,14 @@ blktrace Setup
--------------
For this section, we'll assume you've already performed the basic setup
-outlined in the ":ref:`profile-manual/profile-manual-intro:General Setup`"
+outlined in the ":ref:`profile-manual/intro:General Setup`"
section.
blktrace is an application that runs on the target system. You can run
the entire blktrace and blkparse pipeline on the target, or you can run
blktrace in 'listen' mode on the target and have blktrace and blkparse
collect and analyze the data on the host (see the
-":ref:`profile-manual/profile-manual-usage:Using blktrace Remotely`" section
+":ref:`profile-manual/usage:Using blktrace Remotely`" section
below). For the rest of this section we assume you've ssh'ed to the host and
will be running blkrace on the target.
@@ -2512,7 +2512,7 @@ Tracing Block I/O via 'ftrace'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It's also possible to trace block I/O using only
-:ref:`profile-manual/profile-manual-usage:The 'trace events' Subsystem`, which
+:ref:`profile-manual/usage:The 'trace events' Subsystem`, which
can be useful for casual tracing if you don't want to bother dealing with the
userspace tools.
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 08/10] overview-manual: remove 'overview-manual' from filenames
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
` (6 preceding siblings ...)
2020-12-03 21:38 ` [PATCH 07/10] profile-manual: remove 'profile-manual' " Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 09/10] sdk-manual: remove 'sdk' " Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 10/10] ref-manual: remove 'ref' " Nicolas Dechesne
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
All filenames duplicate the 'manual name', which is not needed, and
make all references longer than they should. Rename all files to be as
consise as possible, and fix all references
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
documentation/brief-yoctoprojectqs/index.rst | 2 +-
documentation/bsp-guide/bsp.rst | 6 +--
documentation/dev-manual/common-tasks.rst | 40 ++++++++--------
documentation/dev-manual/start.rst | 16 +++----
documentation/kernel-dev/advanced.rst | 4 +-
documentation/kernel-dev/common.rst | 4 +-
documentation/kernel-dev/concepts-appx.rst | 6 +--
...rview-manual-concepts.rst => concepts.rst} | 4 +-
...onment.rst => development-environment.rst} | 0
documentation/overview-manual/index.rst | 8 ++--
.../{overview-manual-intro.rst => intro.rst} | 2 +-
...rview-manual-yp-intro.rst => yp-intro.rst} | 2 +-
documentation/ref-manual/faq.rst | 2 +-
documentation/ref-manual/migration-1.7.rst | 2 +-
documentation/ref-manual/migration-2.3.rst | 2 +-
documentation/ref-manual/ref-classes.rst | 12 ++---
.../ref-manual/ref-release-process.rst | 2 +-
documentation/ref-manual/ref-structure.rst | 6 +--
.../ref-manual/ref-system-requirements.rst | 2 +-
documentation/ref-manual/ref-tasks.rst | 36 +++++++--------
documentation/ref-manual/ref-terms.rst | 6 +--
documentation/ref-manual/ref-variables.rst | 46 +++++++++----------
.../sdk-manual/sdk-appendix-customizing.rst | 2 +-
documentation/sdk-manual/sdk-extensible.rst | 2 +-
documentation/toaster-manual/reference.rst | 2 +-
25 files changed, 108 insertions(+), 108 deletions(-)
rename documentation/overview-manual/{overview-manual-concepts.rst => concepts.rst} (99%)
rename documentation/overview-manual/{overview-manual-development-environment.rst => development-environment.rst} (100%)
rename documentation/overview-manual/{overview-manual-intro.rst => intro.rst} (98%)
rename documentation/overview-manual/{overview-manual-yp-intro.rst => yp-intro.rst} (99%)
diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst
index 51f684af0..5dc0bc792 100644
--- a/documentation/brief-yoctoprojectqs/index.rst
+++ b/documentation/brief-yoctoprojectqs/index.rst
@@ -244,7 +244,7 @@ an entire Linux distribution, including the toolchain, from source.
$ bitbake core-image-sato
For information on using the ``bitbake`` command, see the
- :ref:`overview-manual/overview-manual-concepts:bitbake` section in the Yocto Project Overview and
+ :ref:`overview-manual/concepts:bitbake` section in the Yocto Project Overview and
Concepts Manual, or see the ":ref:`BitBake Command
<bitbake:bitbake-user-manual/bitbake-user-manual-intro:the bitbake command>`" section in the BitBake User Manual.
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index e20df3f6b..48bff35fa 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -44,7 +44,7 @@ machine or platform name, which is "bsp_root_name" in the above form.
To help understand the BSP layer concept, consider the BSPs that the
Yocto Project supports and provides with each release. You can see the
layers in the
-:ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+:ref:`overview-manual/development-environment:yocto project source repositories`
through
a web interface at :yocto_git:`/`. If you go to that interface,
you will find a list of repositories under "Yocto Metadata Layers".
@@ -253,7 +253,7 @@ developers can use this structure with other build systems besides the
OpenEmbedded build system. It is also intended that it will be be simple
to extract information and convert it to other formats if required. The
OpenEmbedded build system, through its standard :ref:`layers mechanism
-<overview-manual/overview-manual-yp-intro:the yocto project layer model>`, can
+<overview-manual/yp-intro:the yocto project layer model>`, can
directly accept the format described as a layer. The BSP layer captures
all the hardware-specific details in one place using a standard format,
which is useful for any person wishing to use the hardware platform
@@ -754,7 +754,7 @@ workflow.
are kept. The key point for a layer is that it is an isolated area
that contains all the relevant information for the project that the
OpenEmbedded build system knows about. For more information on
- layers, see the ":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+ layers, see the ":ref:`overview-manual/yp-intro:the yocto project layer model`"
section in the Yocto Project Overview and Concepts Manual. You can also
reference the ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual. For more
diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index fe3667bfb..abeb1ed9c 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -18,7 +18,7 @@ The OpenEmbedded build system supports organizing
Layers allow you to isolate different types of customizations from each
other. For introductory information on the Yocto Project Layer Model,
see the
-":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+":ref:`overview-manual/yp-intro:the yocto project layer model`"
section in the Yocto Project Overview and Concepts Manual.
Creating Your Own Layer
@@ -1319,7 +1319,7 @@ to determine how well the build went.
``log.do_fetch``, and ``log.do_compile``).
You can find more information about the build process in
-":doc:`/overview-manual/overview-manual-development-environment`"
+":doc:`/overview-manual/development-environment`"
chapter of the Yocto Project Overview and Concepts Manual.
Fetching Code
@@ -1330,7 +1330,7 @@ files. Fetching is controlled mainly through the
:term:`SRC_URI` variable. Your recipe
must have a ``SRC_URI`` variable that points to where the source is
located. For a graphical representation of source locations, see the
-":ref:`overview-manual/overview-manual-concepts:sources`" section in
+":ref:`overview-manual/concepts:sources`" section in
the Yocto Project Overview and Concepts Manual.
The :ref:`ref-tasks-fetch` task uses
@@ -1599,7 +1599,7 @@ package "example" contains "libexample" and another package "mypackage"
contains a binary that links to "libexample" then the OpenEmbedded build
system will automatically add a runtime dependency to "mypackage" on
"example"). See the
-":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual for further
details.
@@ -2486,7 +2486,7 @@ Reference Manual's variable glossary.
- Using ``DEPENDS`` also allows runtime dependencies between
packages to be added automatically. See the
- ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+ ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual for more
information.
@@ -3658,7 +3658,7 @@ build host running Linux.
The build process creates an entire Linux distribution from source and
places it in your :term:`Build Directory` under
``tmp/deploy/images``. For detailed information on the build process
-using BitBake, see the ":ref:`overview-manual/overview-manual-concepts:images`" section in the
+using BitBake, see the ":ref:`overview-manual/concepts:images`" section in the
Yocto Project Overview and Concepts Manual.
The following figure and list overviews the build process:
@@ -5490,7 +5490,7 @@ Using an Existing Kickstart File
If you do not want to create your own kickstart file, you can use an
existing file provided by the Wic installation. As shipped, kickstart
-files can be found in the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in the
+files can be found in the :ref:`overview-manual/development-environment:yocto project source repositories` in the
following two locations:
::
@@ -6526,7 +6526,7 @@ revision, respectively). The values are highly dependent on the policies
and procedures of a given distribution and package feed.
Because the OpenEmbedded build system uses
-":ref:`signatures <overview-manual/overview-manual-concepts:checksums (signatures)>`", which are
+":ref:`signatures <overview-manual/concepts:checksums (signatures)>`", which are
unique to a given build, the build system knows when to rebuild
packages. All the inputs into a given task are represented by a
signature, which can trigger a rebuild when different. Thus, the build
@@ -6600,7 +6600,7 @@ Quality <#maintaining-build-output-quality>`__" section.
use a PR Service while others do not leads to obvious problems.
For more information on shared state, see the
- ":ref:`overview-manual/overview-manual-concepts:shared state cache`"
+ ":ref:`overview-manual/concepts:shared state cache`"
section in the Yocto Project Overview and Concepts Manual.
Manually Bumping PR
@@ -6767,7 +6767,7 @@ multiple times if you have more than one set of modules to package.
For more examples that show how to use ``do_split_packages``, see the
``connman.inc`` file in the ``meta/recipes-connectivity/connman/``
-directory of the ``poky`` :ref:`source repository <overview-manual/overview-manual-development-environment:yocto project source repositories>`. You can
+directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can
also find examples in ``meta/classes/kernel.bbclass``.
Following is a reference that shows ``do_split_packages`` mandatory and
@@ -8080,7 +8080,7 @@ variable to "1" at the end of your ``conf/local.conf`` file found in the
Enabling build history as
previously described causes the OpenEmbedded build system to collect
build output information and commit it as a single commit to a local
-:ref:`overview-manual/overview-manual-development-environment:git` repository.
+:ref:`overview-manual/development-environment:git` repository.
.. note::
@@ -9394,7 +9394,7 @@ BitBake has determined by doing the following:
${BUILDDIR}/tmp/stamps/i586-poky-linux/db/6.0.30-r1.do_fetch.sigdata.7c048c18222b16ff0bcee2000ef648b1
For tasks that are accelerated through the shared state
- (:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache, an
+ (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, an
additional ``siginfo`` file is written into
:term:`SSTATE_DIR` along with
the cached task output. The ``siginfo`` files contain exactly the
@@ -9461,15 +9461,15 @@ files, see the "`Viewing Task Variable
Dependencies <#dev-viewing-task-variable-dependencies>`__" section.
For conceptual information on shared state, see the
-":ref:`overview-manual/overview-manual-concepts:shared state`"
+":ref:`overview-manual/concepts:shared state`"
section in the Yocto Project Overview and Concepts Manual.
Invalidating Shared State to Force a Task to Run
------------------------------------------------
The OpenEmbedded build system uses
-:ref:`checksums <overview-manual/overview-manual-concepts:checksums (signatures)>` and
-:ref:`overview-manual/overview-manual-concepts:shared state` cache to avoid unnecessarily
+:ref:`checksums <overview-manual/concepts:checksums (signatures)>` and
+:ref:`overview-manual/concepts:shared state` cache to avoid unnecessarily
rebuilding tasks. Collectively, this scheme is known as "shared state
code".
@@ -9530,7 +9530,7 @@ tasks (including tasks from other recipes) that the specified task
depends on will be run before the task. Even when you manually specify a
task to run with ``-c``, BitBake will only run the task if it considers
it "out of date". See the
-":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
+":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
section in the Yocto Project Overview and Concepts Manual for how
BitBake determines whether a task is "out of date".
@@ -10458,7 +10458,7 @@ Yocto general mailing list or on the openembedded-devel mailing list.
You can also push a change upstream and request a maintainer to pull the
change into the component's upstream repository. You do this by pushing
to a contribution repository that is upstream. See the
-":ref:`overview-manual/overview-manual-development-environment:git workflows and the yocto project`"
+":ref:`overview-manual/development-environment:git workflows and the yocto project`"
section in the Yocto Project Overview and Concepts Manual for additional
concepts on working in the Yocto Project development environment.
@@ -10707,7 +10707,7 @@ been followed:
located in the :term:`Source Directory` at
``meta/conf/distro/include``, to see who is responsible for code.
- - *Search by File:* Using :ref:`overview-manual/overview-manual-development-environment:git`, you can
+ - *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
enter the following command to bring up a short list of all
commits against a specific file:
::
@@ -10856,7 +10856,7 @@ follows:
Working With Licenses
=====================
-As mentioned in the ":ref:`overview-manual/overview-manual-development-environment:licensing`"
+As mentioned in the ":ref:`overview-manual/development-environment:licensing`"
section in the Yocto Project Overview and Concepts Manual, open source
projects are open to the public and they consequently have different
licensing structures in place. This section describes the mechanism by
@@ -11299,7 +11299,7 @@ By releasing the version of the OpenEmbedded build system and the layers
used during the build, you will be providing both compilation scripts
and the source code modifications in one step.
-If the deployment team has a :ref:`overview-manual/overview-manual-concepts:bsp layer`
+If the deployment team has a :ref:`overview-manual/concepts:bsp layer`
and a distro layer, and those
those layers are used to patch, compile, package, or modify (in any way)
any open source software included in your released images, you might be
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst
index 8244d68ed..a26d2a3ea 100644
--- a/documentation/dev-manual/start.rst
+++ b/documentation/dev-manual/start.rst
@@ -78,7 +78,7 @@ particular working environment and set of practices.
developing under the control of an SCM system that is compatible
with the OpenEmbedded build system is advisable. Of all of the SCMs
supported by BitBake, the Yocto Project team strongly recommends using
- :ref:`overview-manual/overview-manual-development-environment:git`.
+ :ref:`overview-manual/development-environment:git`.
Git is a distributed system
that is easy to back up, allows you to work remotely, and then
connects back to the infrastructure.
@@ -165,7 +165,7 @@ particular working environment and set of practices.
- Highlights when commits break the build.
- Populates an :ref:`sstate
- cache <overview-manual/overview-manual-concepts:shared state cache>` from which
+ cache <overview-manual/concepts:shared state cache>` from which
developers can pull rather than requiring local builds.
- Allows commit hook triggers, which trigger builds when commits
@@ -218,17 +218,17 @@ particular working environment and set of practices.
some best practices exist within the Yocto Project development
environment. Consider the following:
- - Use :ref:`overview-manual/overview-manual-development-environment:git` as the source control
+ - Use :ref:`overview-manual/development-environment:git` as the source control
system.
- Maintain your Metadata in layers that make sense for your
- situation. See the ":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+ situation. See the ":ref:`overview-manual/yp-intro:the yocto project layer model`"
section in the Yocto Project Overview and Concepts Manual and the
":ref:`dev-manual/common-tasks:understanding and creating layers`"
section for more information on layers.
- Separate the project's Metadata and code by using separate Git
- repositories. See the ":ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`"
+ repositories. See the ":ref:`overview-manual/development-environment:yocto project source repositories`"
section in the Yocto Project Overview and Concepts Manual for
information on these repositories. See the "`Locating Yocto
Project Source Files <#locating-yocto-project-source-files>`__"
@@ -572,11 +572,11 @@ files you'll need to work with the Yocto Project.
.. note::
- For concepts and introductory information about Git as it is used
- in the Yocto Project, see the ":ref:`overview-manual/overview-manual-development-environment:git`"
+ in the Yocto Project, see the ":ref:`overview-manual/development-environment:git`"
section in the Yocto Project Overview and Concepts Manual.
- For concepts on Yocto Project source repositories, see the
- ":ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`"
+ ":ref:`overview-manual/development-environment:yocto project source repositories`"
section in the Yocto Project Overview and Concepts Manual."
Accessing Source Repositories
@@ -722,7 +722,7 @@ files is referred to as the :term:`Source Directory`
in the Yocto Project documentation.
The preferred method of creating your Source Directory is by using
-:ref:`overview-manual/overview-manual-development-environment:git` to clone a local copy of the upstream
+:ref:`overview-manual/development-environment:git` to clone a local copy of the upstream
``poky`` repository. Working from a cloned copy of the upstream
repository allows you to contribute back into the Yocto Project or to
simply work with the latest software on a development branch. Because
diff --git a/documentation/kernel-dev/advanced.rst b/documentation/kernel-dev/advanced.rst
index 163560b69..dd0b76bc3 100644
--- a/documentation/kernel-dev/advanced.rst
+++ b/documentation/kernel-dev/advanced.rst
@@ -16,7 +16,7 @@ complexity of the configuration and sources used to support multiple
BSPs and Linux kernel types.
Kernel Metadata exists in many places. One area in the
-:ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+:ref:`overview-manual/development-environment:yocto project source repositories`
is the ``yocto-kernel-cache`` Git repository. You can find this repository
grouped under the "Yocto Linux Kernel" heading in the
:yocto_git:`Yocto Project Source Repositories <>`.
@@ -386,7 +386,7 @@ type as follows:
.. note::
You can find kernel recipes in the ``meta/recipes-kernel/linux`` directory
- of the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+ of the :ref:`overview-manual/development-environment:yocto project source repositories`
(e.g. ``poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb``). See the
":ref:`kernel-dev/advanced:using kernel metadata in a recipe`"
section for more information.
diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index 403a63d58..67f8777c4 100644
--- a/documentation/kernel-dev/common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -63,7 +63,7 @@ section:
.. note::
The previous commands assume the
- :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+ :ref:`overview-manual/development-environment:yocto project source repositories`
(i.e. ``poky``) have been cloned using Git and the local repository is named
"poky".
@@ -249,7 +249,7 @@ section:
.. note::
The previous commands assume the
- :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+ :ref:`overview-manual/development-environment:yocto project source repositories`
(i.e. ``poky``) have been cloned using Git and the local repository is named
"poky".
diff --git a/documentation/kernel-dev/concepts-appx.rst b/documentation/kernel-dev/concepts-appx.rst
index 865f6d8be..4b6dbe5ef 100644
--- a/documentation/kernel-dev/concepts-appx.rst
+++ b/documentation/kernel-dev/concepts-appx.rst
@@ -35,7 +35,7 @@ Yocto Project Linux kernel that caters to specific embedded designer
needs for targeted hardware.
You can find a web interface to the Yocto Linux kernels in the
-:ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+:ref:`overview-manual/development-environment:yocto project source repositories`
at :yocto_git:`/`. If you look at the interface, you will see to
the left a grouping of Git repositories titled "Yocto Linux Kernel".
Within this group, you will find several Linux Yocto kernels developed
@@ -160,7 +160,7 @@ implemented by the Yocto Project team using the Source Code Manager
- You can find documentation on Git at https://git-scm.com/doc. You can
also get an introduction to Git as it applies to the Yocto Project in the
- ":ref:`overview-manual/overview-manual-development-environment:git`" section in the Yocto Project
+ ":ref:`overview-manual/development-environment:git`" section in the Yocto Project
Overview and Concepts Manual. The latter reference provides an
overview of Git and presents a minimal set of Git commands that
allows you to be functional using Git. You can use as much, or as
@@ -258,7 +258,7 @@ Yocto Linux kernel needed for any given set of requirements.
Yocto Linux kernels, but rather shows a single generic kernel just
for conceptual purposes. Also keep in mind that this structure
represents the
- :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+ :ref:`overview-manual/development-environment:yocto project source repositories`
that are either pulled from during the build or established on the
host development system prior to the build by either cloning a
particular kernel's Git repository or by downloading and unpacking a
diff --git a/documentation/overview-manual/overview-manual-concepts.rst b/documentation/overview-manual/concepts.rst
similarity index 99%
rename from documentation/overview-manual/overview-manual-concepts.rst
rename to documentation/overview-manual/concepts.rst
index a10670fc5..8aa86c06e 100644
--- a/documentation/overview-manual/overview-manual-concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -40,7 +40,7 @@ section of the Yocto Project Development Tasks Manual.
Following are some brief details on these core components. For
additional information on how these components interact during a build,
see the
-":ref:`overview-manual/overview-manual-concepts:openembedded build system concepts`"
+":ref:`overview-manual/concepts:openembedded build system concepts`"
section.
BitBake
@@ -1109,7 +1109,7 @@ the extensible SDK (eSDK):
.. note::
For more information on the cross-development toolchain generation,
- see the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+ see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
section. For information on advantages gained when building a
cross-development toolchain using the do_populate_sdk task, see the
":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" section in
diff --git a/documentation/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/development-environment.rst
similarity index 100%
rename from documentation/overview-manual/overview-manual-development-environment.rst
rename to documentation/overview-manual/development-environment.rst
diff --git a/documentation/overview-manual/index.rst b/documentation/overview-manual/index.rst
index f20b20e32..123aed9b8 100644
--- a/documentation/overview-manual/index.rst
+++ b/documentation/overview-manual/index.rst
@@ -10,10 +10,10 @@ Yocto Project Overview and Concepts Manual
:caption: Table of Contents
:numbered:
- overview-manual-intro
- overview-manual-yp-intro
- overview-manual-development-environment
- overview-manual-concepts
+ intro
+ yp-intro
+ development-environment
+ concepts
history
.. include:: /boilerplate.rst
diff --git a/documentation/overview-manual/overview-manual-intro.rst b/documentation/overview-manual/intro.rst
similarity index 98%
rename from documentation/overview-manual/overview-manual-intro.rst
rename to documentation/overview-manual/intro.rst
index 50c623c3b..bd247dd45 100644
--- a/documentation/overview-manual/overview-manual-intro.rst
+++ b/documentation/overview-manual/intro.rst
@@ -28,7 +28,7 @@ The following list describes what you can get from this manual:
Yocto Project source repositories, workflows using Git and the Yocto
Project, a Git primer, and information about licensing.
-- :doc:`overview-manual-concepts` *:* This
+- :doc:`/overview-manual/concepts` *:* This
chapter presents various concepts regarding the Yocto Project. You
can find conceptual information about components, development,
cross-toolchains, and so forth.
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/yp-intro.rst
similarity index 99%
rename from documentation/overview-manual/overview-manual-yp-intro.rst
rename to documentation/overview-manual/yp-intro.rst
index a6568d1c8..3afbb9378 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/yp-intro.rst
@@ -589,7 +589,7 @@ Project.
.. note::
For additional detail about the Yocto Project development
- environment, see the ":doc:`overview-manual-development-environment`"
+ environment, see the ":doc:`/overview-manual/development-environment`"
chapter.
- *Native Linux Host:* By far the best option for a Build Host. A
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index 5b9fcc191..cc6b3aee1 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -198,7 +198,7 @@ and also any configuration information about how that package was
configured and built.
You can find more information on licensing in the
-":ref:`overview-manual/overview-manual-development-environment:licensing`"
+":ref:`overview-manual/development-environment:licensing`"
section in the Yocto
Project Overview and Concepts Manual and also in the
":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
diff --git a/documentation/ref-manual/migration-1.7.rst b/documentation/ref-manual/migration-1.7.rst
index 85894d9df..177d40900 100644
--- a/documentation/ref-manual/migration-1.7.rst
+++ b/documentation/ref-manual/migration-1.7.rst
@@ -26,7 +26,7 @@ QEMU, you should now have these lines in ``local.conf``:
Minimum Git version
-------------------
-The minimum :ref:`overview-manual/overview-manual-development-environment:git`
+The minimum :ref:`overview-manual/development-environment:git`
version required on the
build host is now 1.7.8 because the ``--list`` option is now required by
BitBake's Git fetcher. As always, if your host distribution does not
diff --git a/documentation/ref-manual/migration-2.3.rst b/documentation/ref-manual/migration-2.3.rst
index 9e95f45e1..6984ff91e 100644
--- a/documentation/ref-manual/migration-2.3.rst
+++ b/documentation/ref-manual/migration-2.3.rst
@@ -51,7 +51,7 @@ Consider the following:
:term:`SYSROOT_PREPROCESS_FUNCS`.
For an example, see the ``pixbufcache`` class in ``meta/classes/`` in
- the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`.
+ the :ref:`overview-manual/development-environment:yocto project source repositories`.
.. note::
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst
index 914ca4232..900341e5a 100644
--- a/documentation/ref-manual/ref-classes.rst
+++ b/documentation/ref-manual/ref-classes.rst
@@ -406,7 +406,7 @@ cross-compilation tools.
The ``cross-canadian`` class provides support for the recipes that build
the Canadian Cross-compilation tools for SDKs. See the
-":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+":ref:`overview-manual/concepts:cross-development toolchain generation`"
section in the Yocto Project Overview and Concepts Manual for more
discussion on these cross-compilation tools.
@@ -417,7 +417,7 @@ discussion on these cross-compilation tools.
The ``crosssdk`` class provides support for the recipes that build the
cross-compilation tools used for building SDKs. See the
-":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+":ref:`overview-manual/concepts:cross-development toolchain generation`"
section in the Yocto Project Overview and Concepts Manual for more
discussion on these cross-compilation tools.
@@ -930,7 +930,7 @@ For information on customizing images, see the
":ref:`dev-manual/common-tasks:customizing images`" section
in the Yocto Project Development Tasks Manual. For information on how
images are created, see the
-":ref:`overview-manual/overview-manual-concepts:images`" section in the
+":ref:`overview-manual/concepts:images`" section in the
Yocto Project Overview and Concpets Manual.
.. _ref-classes-image-buildinfo:
@@ -2039,7 +2039,7 @@ These classes are inherited by and used with the ``populate_sdk_base``
class.
For more information on the cross-development toolchain generation, see
-the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`"
+the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
section in the Yocto Project Overview and Concepts Manual. For
information on advantages gained when building a cross-development
toolchain using the :ref:`ref-tasks-populate_sdk`
@@ -2268,7 +2268,7 @@ The root filesystem is created from packages using one of the
:term:`PACKAGE_CLASSES` variable.
For information on how root filesystem images are created, see the
-":ref:`overview-manual/overview-manual-concepts:image generation`"
+":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual.
.. _ref-classes-sanity:
@@ -2375,7 +2375,7 @@ default, the class is enabled through the
:term:`INHERIT_DISTRO` variable's default value.
For more information on sstate, see the
-":ref:`overview-manual/overview-manual-concepts:shared state cache`"
+":ref:`overview-manual/concepts:shared state cache`"
section in the Yocto Project Overview and Concepts Manual.
.. _ref-classes-staging:
diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst
index 54cd9510f..20be09a4f 100644
--- a/documentation/ref-manual/ref-release-process.rst
+++ b/documentation/ref-manual/ref-release-process.rst
@@ -50,7 +50,7 @@ Major Release Codenames
=======================
Each major release receives a codename that identifies the release in
-the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`.
+the :ref:`overview-manual/development-environment:yocto project source repositories`.
The concept is that branches of :term:`Metadata` with the same
codename are likely to be compatible and thus work together.
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index b681e8233..606a77c7f 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -399,8 +399,8 @@ This directory contains any "end result" output from the OpenEmbedded
build process. The :term:`DEPLOY_DIR` variable points
to this directory. For more detail on the contents of the ``deploy``
directory, see the
-":ref:`overview-manual/overview-manual-concepts:images`" and
-":ref:`overview-manual/overview-manual-concepts:application development sdk`" sections in the Yocto
+":ref:`overview-manual/concepts:images`" and
+":ref:`overview-manual/concepts:application development sdk`" sections in the Yocto
Project Overview and Concepts Manual.
.. _structure-build-tmp-deploy-deb:
@@ -545,7 +545,7 @@ and timestamps for tracking purposes.
For information on how BitBake uses stamp files to determine if a task
should be rerun, see the
-":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
+":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
section in the Yocto Project Overview and Concepts Manual.
.. _structure-build-tmp-log:
diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/ref-system-requirements.rst
index d162c9bad..66afb0810 100644
--- a/documentation/ref-manual/ref-system-requirements.rst
+++ b/documentation/ref-manual/ref-system-requirements.rst
@@ -15,7 +15,7 @@ Yocto Project.
For introductory information on the Yocto Project, see the
:yocto_home:`Yocto Project Website <>` and the
-":ref:`overview-manual/overview-manual-development-environment:the yocto project development environment`"
+":ref:`overview-manual/development-environment:the yocto project development environment`"
chapter in the Yocto Project Overview and Concepts Manual.
If you want to use the Yocto Project to quickly build an image without
diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst
index 768c10eeb..8b9e0c2d8 100644
--- a/documentation/ref-manual/ref-tasks.rst
+++ b/documentation/ref-manual/ref-tasks.rst
@@ -140,7 +140,7 @@ The ``do_image`` task performs pre-processing on the image through the
:term:`IMAGE_PREPROCESS_COMMAND` and
dynamically generates supporting ``do_image_*`` tasks as needed.
-For more information on image creation, see the ":ref:`overview-manual/overview-manual-concepts:image generation`"
+For more information on image creation, see the ":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-image-complete:
@@ -159,7 +159,7 @@ through the
:term:`IMAGE_POSTPROCESS_COMMAND`.
For more information on image creation, see the
-":ref:`overview-manual/overview-manual-concepts:image generation`"
+":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-install:
@@ -174,7 +174,7 @@ compilation directory. The ``do_install`` task, as well as other tasks
that either directly or indirectly depend on the installed files (e.g.
:ref:`ref-tasks-package`, ``do_package_write_*``, and
:ref:`ref-tasks-rootfs`), run under
-:ref:`fakeroot <overview-manual/overview-manual-concepts:fakeroot and pseudo>`.
+:ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`.
.. note::
@@ -218,7 +218,7 @@ The ``do_package`` task, in conjunction with the
:ref:`ref-tasks-packagedata` task, also saves some
important package metadata. For additional information, see the
:term:`PKGDESTWORK` variable and the
-":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-package_qa:
@@ -237,7 +237,7 @@ see the :ref:`insane <ref-classes-insane>` class.
Creates Debian packages (i.e. ``*.deb`` files) and places them in the
``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory in
the package feeds area. For more information, see the
-":ref:`overview-manual/overview-manual-concepts:package feeds`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-package_write_ipk:
@@ -248,7 +248,7 @@ the Yocto Project Overview and Concepts Manual.
Creates IPK packages (i.e. ``*.ipk`` files) and places them in the
``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory in
the package feeds area. For more information, see the
-":ref:`overview-manual/overview-manual-concepts:package feeds`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-package_write_rpm:
@@ -259,7 +259,7 @@ the Yocto Project Overview and Concepts Manual.
Creates RPM packages (i.e. ``*.rpm`` files) and places them in the
``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory in
the package feeds area. For more information, see the
-":ref:`overview-manual/overview-manual-concepts:package feeds`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-package_write_tar:
@@ -270,7 +270,7 @@ the Yocto Project Overview and Concepts Manual.
Creates tarballs and places them in the
``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory in
the package feeds area. For more information, see the
-":ref:`overview-manual/overview-manual-concepts:package feeds`" section in
+":ref:`overview-manual/concepts:package feeds`" section in
the Yocto Project Overview and Concepts Manual.
.. _ref-tasks-packagedata:
@@ -349,7 +349,7 @@ patch files end with either ``.patch`` or ``.diff``, every file would be
applied as a patch by default except for the ``patch_file5`` patch.
You can find out more about the patching process in the
-":ref:`overview-manual/overview-manual-concepts:patching`" section in
+":ref:`overview-manual/concepts:patching`" section in
the Yocto Project Overview and Concepts Manual and the
":ref:`dev-manual/common-tasks:patching code`" section in the
Yocto Project Development Tasks Manual.
@@ -368,7 +368,7 @@ the image is constructed.
-------------------
Creates the file and directory structure for an installable SDK. See the
-":ref:`overview-manual/overview-manual-concepts:sdk generation`"
+":ref:`overview-manual/concepts:sdk generation`"
section in the Yocto Project Overview and Concepts Manual for more
information.
@@ -378,7 +378,7 @@ information.
-----------------------
Creates the file and directory structure for an installable extensible
-SDK (eSDK). See the ":ref:`overview-manual/overview-manual-concepts:sdk generation`"
+SDK (eSDK). See the ":ref:`overview-manual/concepts:sdk generation`"
section in the Yocto Project Overview and Concepts Manual for more
information.
@@ -434,7 +434,7 @@ Unpacks the source code into a working directory pointed to by
``${``\ :term:`WORKDIR`\ ``}``. The :term:`S`
variable also plays a role in where unpacked source files ultimately
reside. For more information on how source files are unpacked, see the
-":ref:`overview-manual/overview-manual-concepts:source fetching`"
+":ref:`overview-manual/concepts:source fetching`"
section in the Yocto Project Overview and Concepts Manual and also see
the ``WORKDIR`` and ``S`` variable descriptions.
@@ -500,7 +500,7 @@ You can run this task using BitBake as follows:
$ bitbake -c clean recipe
Running this task does not remove the
-:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>` cache files.
+:ref:`sstate <overview-manual/concepts:shared state cache>` cache files.
Consequently, if no changes have been made and the recipe is rebuilt
after cleaning, output files are simply restored from the sstate cache.
If you want to remove the sstate cache files for the recipe, you need to
@@ -513,7 +513,7 @@ use the :ref:`ref-tasks-cleansstate` task instead
---------------
Removes all output files, shared state
-(:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache, and
+(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, and
downloaded source files for a target (i.e. the contents of
:term:`DL_DIR`). Essentially, the ``do_cleanall`` task is
identical to the :ref:`ref-tasks-cleansstate` task
@@ -534,10 +534,10 @@ task.
------------------
Removes all output files and shared state
-(:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`) cache for a
+(:ref:`sstate <overview-manual/concepts:shared state cache>`) cache for a
target. Essentially, the ``do_cleansstate`` task is identical to the
:ref:`ref-tasks-clean` task with the added removal of
-shared state (:ref:`sstate <overview-manual/overview-manual-concepts:shared state cache>`)
+shared state (:ref:`sstate <overview-manual/concepts:shared state cache>`)
cache.
You can run this task using BitBake as follows:
@@ -593,7 +593,7 @@ Lists all defined tasks for a target.
``do_package_index``
--------------------
-Creates or updates the index in the :ref:`overview-manual/overview-manual-concepts:package feeds` area.
+Creates or updates the index in the :ref:`overview-manual/concepts:package feeds` area.
.. note::
@@ -631,7 +631,7 @@ has some more information about these types of images.
-------------
Creates the root filesystem (file and directory structure) for an image.
-See the ":ref:`overview-manual/overview-manual-concepts:image generation`"
+See the ":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual for more
information on how the root filesystem is created.
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index ba1930ebd..f41073602 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -160,7 +160,7 @@ universal, the list includes them just in case:
Creation of these toolchains is simple and automated. For information on
toolchain concepts as they apply to the Yocto Project, see the
- ":ref:`overview-manual/overview-manual-concepts:Cross-Development
+ ":ref:`overview-manual/concepts:Cross-Development
Toolchain Generation`" section in the Yocto Project Overview and Concepts
Manual. You can also find more information on using the relocatable
toolchain in the :doc:`/sdk-manual/index` manual.
@@ -189,7 +189,7 @@ universal, the list includes them just in case:
layers used within Yocto Project.
For introductory information on layers, see the
- ":ref:`overview-manual/overview-manual-yp-intro:The Yocto Project Layer
+ ":ref:`overview-manual/yp-intro:The Yocto Project Layer
Model`" section in the Yocto Project Overview and Concepts Manual. For
more detailed information on layers, see the
":ref:`dev-manual/common-tasks:Understanding and Creating
@@ -366,7 +366,7 @@ universal, the list includes them just in case:
For more information on concepts related to Git repositories,
branches, and tags, see the
- ":ref:`overview-manual/overview-manual-development-environment:repositories, tags, and branches`"
+ ":ref:`overview-manual/development-environment:repositories, tags, and branches`"
section in the Yocto Project Overview and Concepts Manual.
:term:`Task`
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index d98e35817..a8a949b92 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -1016,7 +1016,7 @@ system and gives an overview of their function and contents.
(SDK).
- *task:* Save output file signatures for
- :ref:`shared state <overview-manual/overview-manual-concepts:shared state cache>`
+ :ref:`shared state <overview-manual/concepts:shared state cache>`
(sstate) tasks.
This saves one file per task and lists the SHA-256 checksums for
each file staged (i.e. the output of the task).
@@ -1522,7 +1522,7 @@ system and gives an overview of their function and contents.
.. note::
Tasks that read from or write to this directory should run under
- :ref:`fakeroot <overview-manual/overview-manual-concepts:fakeroot and pseudo>`.
+ :ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`.
:term:`DATE`
The date the build was started. Dates appear using the year, month,
@@ -1641,7 +1641,7 @@ system and gives an overview of their function and contents.
- One recipe having another recipe in ``DEPENDS`` does not by
itself add any runtime dependencies between the packages
produced by the two recipes. However, as explained in the
- ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+ ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual,
runtime dependencies will often be added automatically, meaning
``DEPENDS`` alone is sufficient for most recipes.
@@ -1672,9 +1672,9 @@ system and gives an overview of their function and contents.
For more information on the structure of the Build Directory, see
":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
For more detail on the contents of the ``deploy`` directory, see the
- ":ref:`overview-manual/overview-manual-concepts:images`",
- ":ref:`overview-manual/overview-manual-concepts:package feeds`", and
- ":ref:`overview-manual/overview-manual-concepts:application development sdk`" sections all in the
+ ":ref:`overview-manual/concepts:images`",
+ ":ref:`overview-manual/concepts:package feeds`", and
+ ":ref:`overview-manual/concepts:application development sdk`" sections all in the
Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_DEB`
@@ -1696,7 +1696,7 @@ system and gives an overview of their function and contents.
:ref:`ref-tasks-package_write_deb` task
writes Debian packages into the appropriate folder. For more
information on how packaging works, see the
- ":ref:`overview-manual/overview-manual-concepts:package feeds`" section
+ ":ref:`overview-manual/concepts:package feeds`" section
in the Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_IMAGE`
@@ -1710,8 +1710,8 @@ system and gives an overview of their function and contents.
For more information on the structure of the Build Directory, see
":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
For more detail on the contents of the ``deploy`` directory, see the
- ":ref:`overview-manual/overview-manual-concepts:images`" and
- ":ref:`overview-manual/overview-manual-concepts:application development sdk`" sections both in
+ ":ref:`overview-manual/concepts:images`" and
+ ":ref:`overview-manual/concepts:application development sdk`" sections both in
the Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_IPK`
@@ -1732,7 +1732,7 @@ system and gives an overview of their function and contents.
:ref:`ref-tasks-package_write_ipk` task
writes IPK packages into the appropriate folder. For more information
on how packaging works, see the
- ":ref:`overview-manual/overview-manual-concepts:package feeds`" section
+ ":ref:`overview-manual/concepts:package feeds`" section
in the Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_RPM`
@@ -1753,7 +1753,7 @@ system and gives an overview of their function and contents.
:ref:`ref-tasks-package_write_rpm` task
writes RPM packages into the appropriate folder. For more information
on how packaging works, see the
- ":ref:`overview-manual/overview-manual-concepts:package feeds`" section
+ ":ref:`overview-manual/concepts:package feeds`" section
in the Yocto Project Overview and Concepts Manual.
:term:`DEPLOY_DIR_TAR`
@@ -1774,7 +1774,7 @@ system and gives an overview of their function and contents.
:ref:`ref-tasks-package_write_tar` task
writes TAR packages into the appropriate folder. For more information
on how packaging works, see the
- ":ref:`overview-manual/overview-manual-concepts:package feeds`" section
+ ":ref:`overview-manual/concepts:package feeds`" section
in the Yocto Project Overview and Concepts Manual.
:term:`DEPLOYDIR`
@@ -2419,7 +2419,7 @@ system and gives an overview of their function and contents.
The previous statement appears in the
``linux-yocto-dev.bbappend`` file, which is found in the
- :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in
+ :ref:`overview-manual/development-environment:yocto project source repositories` in
``meta-intel/common/recipes-kernel/linux``. Here, the machine
override is a special :term:`PACKAGE_ARCH`
definition for multiple ``meta-intel`` machines.
@@ -2509,7 +2509,7 @@ system and gives an overview of their function and contents.
build system uses files from ``files/defconfig``.
You can find out more about the patching process in the
- ":ref:`overview-manual/overview-manual-concepts:patching`" section
+ ":ref:`overview-manual/concepts:patching`" section
in the Yocto Project Overview and Concepts Manual and the
":ref:`dev-manual/common-tasks:patching code`" section in
the Yocto Project Development Tasks Manual. See the
@@ -3126,7 +3126,7 @@ system and gives an overview of their function and contents.
The location is
derived using the :term:`DEPLOY_DIR_IMAGE`
and :term:`IMAGE_NAME` variables. You can find
- information on how the image is created in the ":ref:`overview-manual/overview-manual-concepts:image generation`"
+ information on how the image is created in the ":ref:`overview-manual/concepts:image generation`"
section in the Yocto Project Overview and Concepts Manual.
:term:`IMAGE_NAME`
@@ -5578,7 +5578,7 @@ system and gives an overview of their function and contents.
${STAGING_DIR_HOST}/pkgdata
For examples of how this data is used, see the
- ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+ ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual and the
":ref:`dev-manual/common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``"
section in the Yocto Project Development Tasks Manual. For more
@@ -5691,9 +5691,9 @@ system and gives an overview of their function and contents.
The OpenEmbedded build system does not need the aid of ``PR``
to know when to rebuild a recipe. The build system uses the task
- :ref:`input checksums <overview-manual/overview-manual-concepts:checksums (signatures)>` along with the
+ :ref:`input checksums <overview-manual/concepts:checksums (signatures)>` along with the
:ref:`stamp <structure-build-tmp-stamps>` and
- :ref:`overview-manual/overview-manual-concepts:shared state cache`
+ :ref:`overview-manual/concepts:shared state cache`
mechanisms.
The ``PR`` variable primarily becomes significant when a package
@@ -5875,7 +5875,7 @@ system and gives an overview of their function and contents.
libplds4.so"
For more information, see the
- ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+ ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual.
:term:`PROVIDES`
@@ -6068,7 +6068,7 @@ system and gives an overview of their function and contents.
runtime dependencies are automatically detected and added. Therefore,
most recipes do not need to set ``RDEPENDS``. For more information,
see the
- ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`"
+ ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
section in the Yocto Project Overview and Concepts Manual.
The practical effect of the above ``RDEPENDS`` assignment is that
@@ -7023,7 +7023,7 @@ system and gives an overview of their function and contents.
- ``file://`` - Fetches files, which are usually files shipped
with the :term:`Metadata`, from the local machine (e.g.
- :ref:`patch <overview-manual/overview-manual-concepts:patching>` files).
+ :ref:`patch <overview-manual/concepts:patching>` files).
The path is relative to the :term:`FILESPATH`
variable. Thus, the build system searches, in order, from the
following directories, which are assumed to be a subdirectories of
@@ -7316,7 +7316,7 @@ system and gives an overview of their function and contents.
see the :ref:`ref-tasks-populate_sysroot`
task, the ":ref:`sdk-manual/sdk-extensible:sharing files between recipes`"
section in the Yocto Project Development Tasks Manual, the
- ":ref:`overview-manual/overview-manual-concepts:configuration, compilation, and staging`"
+ ":ref:`overview-manual/concepts:configuration, compilation, and staging`"
section in the Yocto Project Overview and Concepts Manual, and the
:term:`SYSROOT_DIRS` variable.
@@ -7437,7 +7437,7 @@ system and gives an overview of their function and contents.
For information on how BitBake uses stamp files to determine if a
task should be rerun, see the
- ":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`"
+ ":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
section in the Yocto Project Overview and Concepts Manual.
See :term:`STAMPS_DIR`,
diff --git a/documentation/sdk-manual/sdk-appendix-customizing.rst b/documentation/sdk-manual/sdk-appendix-customizing.rst
index 5a33f6385..97ade0801 100644
--- a/documentation/sdk-manual/sdk-appendix-customizing.rst
+++ b/documentation/sdk-manual/sdk-appendix-customizing.rst
@@ -87,7 +87,7 @@ adjustments:
following:
- After ensuring the tasks are :ref:`shared
- state <overview-manual/overview-manual-concepts:shared state cache>` tasks (i.e. the
+ state <overview-manual/concepts:shared state cache>` tasks (i.e. the
output of the task is saved to and can be restored from the shared
state cache) or ensuring the tasks are able to be produced quickly
from a task that is a shared state task, add the task name to the
diff --git a/documentation/sdk-manual/sdk-extensible.rst b/documentation/sdk-manual/sdk-extensible.rst
index 14ad23ba8..c94213d6c 100644
--- a/documentation/sdk-manual/sdk-extensible.rst
+++ b/documentation/sdk-manual/sdk-extensible.rst
@@ -183,7 +183,7 @@ system.
part of an image built using the build system.
The ``devtool`` command line is organized similarly to
-:ref:`overview-manual/overview-manual-development-environment:git` in that it has a number of
+:ref:`overview-manual/development-environment:git` in that it has a number of
sub-commands for each function. You can run ``devtool --help`` to see
all the commands.
diff --git a/documentation/toaster-manual/reference.rst b/documentation/toaster-manual/reference.rst
index 4da415d86..dfe51889e 100644
--- a/documentation/toaster-manual/reference.rst
+++ b/documentation/toaster-manual/reference.rst
@@ -65,7 +65,7 @@ set up the code for the web application that "hooks" into your set of
layers.
For general information on layers, see the
-":ref:`overview-manual/overview-manual-yp-intro:the yocto project layer model`"
+":ref:`overview-manual/yp-intro:the yocto project layer model`"
section in the Yocto Project Overview and Concepts Manual. For information on how
to create layers, see the ":ref:`dev-manual/common-tasks:understanding and creating layers`"
section in the Yocto Project Development Tasks Manual.
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 09/10] sdk-manual: remove 'sdk' from filenames
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
` (7 preceding siblings ...)
2020-12-03 21:38 ` [PATCH 08/10] overview-manual: remove 'overview-manual' " Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 10/10] ref-manual: remove 'ref' " Nicolas Dechesne
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
All filenames duplicate the 'manual name', which is not needed, and
make all references longer than they should. Rename all files to be as
consise as possible, and fix all references
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
documentation/dev-manual/common-tasks.rst | 8 ++++----
documentation/dev-manual/qemu.rst | 4 ++--
documentation/dev-manual/start.rst | 6 +++---
documentation/kernel-dev/common.rst | 2 +-
documentation/kernel-dev/intro.rst | 2 +-
documentation/overview-manual/concepts.rst | 8 ++++----
documentation/overview-manual/yp-intro.rst | 2 +-
documentation/ref-manual/migration-2.1.rst | 6 +++---
documentation/ref-manual/ref-classes.rst | 4 ++--
.../ref-manual/ref-devtool-reference.rst | 4 ++--
documentation/ref-manual/ref-features.rst | 2 +-
documentation/ref-manual/ref-structure.rst | 2 +-
documentation/ref-manual/ref-variables.rst | 20 +++++++++----------
....rst => appendix-customizing-standard.rst} | 0
...stomizing.rst => appendix-customizing.rst} | 0
...ppendix-obtain.rst => appendix-obtain.rst} | 2 +-
.../{sdk-extensible.rst => extensible.rst} | 0
documentation/sdk-manual/index.rst | 14 ++++++-------
.../sdk-manual/{sdk-intro.rst => intro.rst} | 0
.../sdk-manual/{sdk-using.rst => using.rst} | 0
...king-projects.rst => working-projects.rst} | 2 +-
.../transitioning-to-a-custom-environment.rst | 2 +-
documentation/what-i-wish-id-known.rst | 6 +++---
23 files changed, 48 insertions(+), 48 deletions(-)
rename documentation/sdk-manual/{sdk-appendix-customizing-standard.rst => appendix-customizing-standard.rst} (100%)
rename documentation/sdk-manual/{sdk-appendix-customizing.rst => appendix-customizing.rst} (100%)
rename documentation/sdk-manual/{sdk-appendix-obtain.rst => appendix-obtain.rst} (99%)
rename documentation/sdk-manual/{sdk-extensible.rst => extensible.rst} (100%)
rename documentation/sdk-manual/{sdk-intro.rst => intro.rst} (100%)
rename documentation/sdk-manual/{sdk-using.rst => using.rst} (100%)
rename documentation/sdk-manual/{sdk-working-projects.rst => working-projects.rst} (99%)
diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index abeb1ed9c..6c4220dd5 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -1119,7 +1119,7 @@ necessary when adding a recipe to build a new piece of software to be
included in a build.
You can find a complete description of the ``devtool add`` command in
-the ":ref:`sdk-manual/sdk-extensible:a closer look at \`\`devtool add\`\``" section
+the ":ref:`sdk-manual/extensible:a closer look at \`\`devtool add\`\``" section
in the Yocto Project Application Development and the Extensible Software
Development Kit (eSDK) manual.
@@ -3129,7 +3129,7 @@ As mentioned earlier, an alternative method for upgrading recipes to
newer versions is to use
:doc:`devtool upgrade </ref-manual/ref-devtool-reference>`.
You can read about ``devtool upgrade`` in general in the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
+":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) Manual.
@@ -3413,7 +3413,7 @@ form of a patch all using Quilt.
With regard to preserving changes to source files, if you clean a
recipe or have ``rm_work`` enabled, the
- :ref:`devtool workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
+ :ref:`devtool workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
as described in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual is a safer
development flow than the flow that uses Quilt.
@@ -3647,7 +3647,7 @@ build host running Linux.
:doc:`/toaster-manual/index`.
- For information on how to use ``devtool`` to build images, see the
- ":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
+ ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
diff --git a/documentation/dev-manual/qemu.rst b/documentation/dev-manual/qemu.rst
index 4e58fc1b6..766691b97 100644
--- a/documentation/dev-manual/qemu.rst
+++ b/documentation/dev-manual/qemu.rst
@@ -46,7 +46,7 @@ available. Follow these general steps to run QEMU:
1. *Install QEMU:* QEMU is made available with the Yocto Project a
number of ways. One method is to install a Software Development Kit
- (SDK). See ":ref:`sdk-manual/sdk-intro:the qemu emulator`" section in the
+ (SDK). See ":ref:`sdk-manual/intro:the qemu emulator`" section in the
Yocto Project Application Development and the Extensible Software
Development Kit (eSDK) manual for information on how to install QEMU.
@@ -81,7 +81,7 @@ available. Follow these general steps to run QEMU:
pre-built image that matches your architecture and can be run on
QEMU.
- See the ":ref:`sdk-manual/sdk-appendix-obtain:extracting the root filesystem`"
+ See the ":ref:`sdk-manual/appendix-obtain:extracting the root filesystem`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual for information on
how to extract a root filesystem.
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst
index a26d2a3ea..6fad4c9b4 100644
--- a/documentation/dev-manual/start.rst
+++ b/documentation/dev-manual/start.rst
@@ -342,7 +342,7 @@ using a given development path on your native Linux machine. If you are
going to use BitBake, see the
":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section. If you are going
-to use the Extensible SDK, see the ":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
+to use the Extensible SDK, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`/kernel-dev/index`. If you are going to use
Toaster, see the ":doc:`/toaster-manual/setup-and-use`"
@@ -442,7 +442,7 @@ as if you were running on a native Linux machine. If you are going to
use the Poky container, see the
":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
section. If you are going to use the Extensible SDK container, see the
-":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
+":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you are going to use the Toaster container, see
the ":doc:`/toaster-manual/setup-and-use`"
@@ -557,7 +557,7 @@ your Yocto Project build host:
Once you have WSLv2 set up, everything is in place to develop just as if
you were running on a native Linux machine. If you are going to use the
-Extensible SDK container, see the ":doc:`/sdk-manual/sdk-extensible`" Chapter in the Yocto
+Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual. If you are going to use the Toaster container, see
the ":doc:`/toaster-manual/setup-and-use`"
diff --git a/documentation/kernel-dev/common.rst b/documentation/kernel-dev/common.rst
index 67f8777c4..6691da448 100644
--- a/documentation/kernel-dev/common.rst
+++ b/documentation/kernel-dev/common.rst
@@ -39,7 +39,7 @@ Source Directory.
sections in the Yocto Project Development Tasks Manual for more information.
Kernel development is best accomplished using
-:ref:`devtool <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
+:ref:`devtool <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
and not through traditional kernel workflow methods. The remainder of
this section provides information for both scenarios.
diff --git a/documentation/kernel-dev/intro.rst b/documentation/kernel-dev/intro.rst
index 2b60616df..c95d2f7cb 100644
--- a/documentation/kernel-dev/intro.rst
+++ b/documentation/kernel-dev/intro.rst
@@ -84,7 +84,7 @@ understand the following documentation:
- :doc:`/overview-manual/index`.
- :ref:`devtool
- workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
+ workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
as described in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 8aa86c06e..019ead85c 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -830,7 +830,7 @@ processes patches, see the
":ref:`dev-manual/common-tasks:patching code`"
section in the
Yocto Project Development Tasks Manual. You can also see the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
+":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (SDK) manual and the
":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
@@ -1112,7 +1112,7 @@ the extensible SDK (eSDK):
see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
section. For information on advantages gained when building a
cross-development toolchain using the do_populate_sdk task, see the
- ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" section in
+ ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in
the Yocto Project Application Development and the Extensible Software
Development Kit (eSDK) manual.
@@ -1443,7 +1443,7 @@ Cross-Development Toolchain Generation
======================================
The Yocto Project does most of the work for you when it comes to
-creating :ref:`sdk-manual/sdk-intro:the cross-development toolchain`. This
+creating :ref:`sdk-manual/intro:the cross-development toolchain`. This
section provides some technical background on how cross-development
toolchains are created and used. For more information on toolchains, you
can also see the :doc:`/sdk-manual/index` manual.
@@ -1573,7 +1573,7 @@ Here is the bootstrap process for the relocatable toolchain:
For information on advantages gained when building a
cross-development toolchain installer, see the
- ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" appendix
+ ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" appendix
in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst
index 3afbb9378..c66b4b5da 100644
--- a/documentation/overview-manual/yp-intro.rst
+++ b/documentation/overview-manual/yp-intro.rst
@@ -327,7 +327,7 @@ applications using the Yocto Project:
You can read about the ``devtool`` workflow in the Yocto Project
Application Development and Extensible Software Development Kit
(eSDK) Manual in the
- ":ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`"
+ ":ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`"
section.
- *Extensible Software Development Kit (eSDK):* The eSDK provides a
diff --git a/documentation/ref-manual/migration-2.1.rst b/documentation/ref-manual/migration-2.1.rst
index 678a767e1..a1d7b9a2d 100644
--- a/documentation/ref-manual/migration-2.1.rst
+++ b/documentation/ref-manual/migration-2.1.rst
@@ -231,8 +231,8 @@ ADT Removed
The Application Development Toolkit (ADT) has been removed because its
functionality almost completely overlapped with the :ref:`standard
-SDK <sdk-manual/sdk-using:using the standard sdk>` and the
-:ref:`extensible SDK <sdk-manual/sdk-extensible:using the extensible sdk>`. For
+SDK <sdk-manual/using:using the standard sdk>` and the
+:ref:`extensible SDK <sdk-manual/extensible:using the extensible sdk>`. For
information on these SDKs and how to build and use them, see the
:doc:`/sdk-manual/index` manual.
@@ -386,7 +386,7 @@ These additional changes exist:
removed at runtime).
- The
- :ref:`devtool modify <sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`
+ :ref:`devtool modify <sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`
command now defaults to extracting the source since that is most
commonly expected. The "-x" or "--extract" options are now no-ops. If
you wish to provide your own existing source tree, you will now need
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst
index 900341e5a..37ab4992e 100644
--- a/documentation/ref-manual/ref-classes.rst
+++ b/documentation/ref-manual/ref-classes.rst
@@ -1986,7 +1986,7 @@ files.
The ``populate_sdk`` class provides support for SDK-only recipes. For
information on advantages gained when building a cross-development
toolchain using the :ref:`ref-tasks-populate_sdk`
-task, see the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
+task, see the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual.
@@ -2044,7 +2044,7 @@ section in the Yocto Project Overview and Concepts Manual. For
information on advantages gained when building a cross-development
toolchain using the :ref:`ref-tasks-populate_sdk`
task, see the
-":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
+":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual.
diff --git a/documentation/ref-manual/ref-devtool-reference.rst b/documentation/ref-manual/ref-devtool-reference.rst
index 11b4cb5d5..2b97bb460 100644
--- a/documentation/ref-manual/ref-devtool-reference.rst
+++ b/documentation/ref-manual/ref-devtool-reference.rst
@@ -11,7 +11,7 @@ is a key part of the extensible SDK.
This chapter provides a Quick Reference for the ``devtool`` command. For
more information on how to apply the command when using the extensible
-SDK, see the ":doc:`/sdk-manual/sdk-extensible`" chapter in the Yocto
+SDK, see the ":doc:`/sdk-manual/extensible`" chapter in the Yocto
Project Application Development and the Extensible Software Development
Kit (eSDK) manual.
@@ -438,7 +438,7 @@ revision to which you want to upgrade (i.e. the
forth.
You can read more on the ``devtool upgrade`` workflow in the
-":ref:`sdk-manual/sdk-extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
+":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual. You can also see an example of
how to use ``devtool upgrade`` in the ":ref:`dev-manual/common-tasks:using \`\`devtool upgrade\`\``"
diff --git a/documentation/ref-manual/ref-features.rst b/documentation/ref-manual/ref-features.rst
index cb4b57436..89c06eb65 100644
--- a/documentation/ref-manual/ref-features.rst
+++ b/documentation/ref-manual/ref-features.rst
@@ -118,7 +118,7 @@ metadata:
- *api-documentation:* Enables generation of API documentation during
recipe builds. The resulting documentation is added to SDK tarballs
when the ``bitbake -c populate_sdk`` command is used. See the
- ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding api documentation to the standard sdk`"
+ ":ref:`sdk-manual/appendix-customizing-standard:adding api documentation to the standard sdk`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst
index 606a77c7f..ab9075b9c 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/ref-structure.rst
@@ -477,7 +477,7 @@ the kernel files:
The OpenEmbedded build system creates this directory to hold toolchain
installer scripts which, when executed, install the sysroot that matches
your target hardware. You can find out more about these installers in
-the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`"
+the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
section in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual.
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst
index a8a949b92..865d17c1f 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/ref-variables.rst
@@ -6542,7 +6542,7 @@ system and gives an overview of their function and contents.
For additional information on how to customize the extensible SDK's
configuration, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
+ ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -6568,7 +6568,7 @@ system and gives an overview of their function and contents.
For additional information on how to customize the extensible SDK's
configuration, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
+ ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -6587,7 +6587,7 @@ system and gives an overview of their function and contents.
For additional information on how to customize the extensible SDK's
configuration, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`"
+ ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -6710,7 +6710,7 @@ system and gives an overview of their function and contents.
``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)".
For information on how to change this default title, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:changing the extensible sdk installer title`"
+ ":ref:`sdk-manual/appendix-customizing:changing the extensible sdk installer title`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -6748,7 +6748,7 @@ system and gives an overview of their function and contents.
default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk".
For information on how to change this default directory, see the
- ":ref:`sdk-manual/sdk-appendix-customizing:changing the default sdk installation directory`"
+ ":ref:`sdk-manual/appendix-customizing:changing the default sdk installation directory`"
section in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual.
@@ -7314,7 +7314,7 @@ system and gives an overview of their function and contents.
For information on how staging for recipe-specific sysroots occurs,
see the :ref:`ref-tasks-populate_sysroot`
- task, the ":ref:`sdk-manual/sdk-extensible:sharing files between recipes`"
+ task, the ":ref:`sdk-manual/extensible:sharing files between recipes`"
section in the Yocto Project Development Tasks Manual, the
":ref:`overview-manual/concepts:configuration, compilation, and staging`"
section in the Yocto Project Overview and Concepts Manual, and the
@@ -8145,13 +8145,13 @@ system and gives an overview of their function and contents.
In this case, a default list of packages is
set in this variable, but you can add additional packages to the
list. See the
- ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
+ ":ref:`sdk-manual/appendix-customizing-standard:adding individual packages to the standard sdk`" section
in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual for more information.
For background information on cross-development toolchains in the
Yocto Project development environment, see the
- ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
+ ":ref:`sdk-manual/intro:the cross-development toolchain`"
section in the Yocto Project Overview and Concepts Manual. For
information on setting up a cross-development environment, see the
:doc:`/sdk-manual/index` manual.
@@ -8175,13 +8175,13 @@ system and gives an overview of their function and contents.
target hardware), which includes libraries and headers. Use this
variable to add individual packages to the part of the SDK that runs
on the target. See the
- ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section
+ ":ref:`sdk-manual/appendix-customizing-standard:adding individual packages to the standard sdk`" section
in the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual for more information.
For background information on cross-development toolchains in the
Yocto Project development environment, see the
- ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`"
+ ":ref:`sdk-manual/intro:the cross-development toolchain`"
section in the Yocto Project Overview and Concepts Manual. For
information on setting up a cross-development environment, see the
:doc:`/sdk-manual/index` manual.
diff --git a/documentation/sdk-manual/sdk-appendix-customizing-standard.rst b/documentation/sdk-manual/appendix-customizing-standard.rst
similarity index 100%
rename from documentation/sdk-manual/sdk-appendix-customizing-standard.rst
rename to documentation/sdk-manual/appendix-customizing-standard.rst
diff --git a/documentation/sdk-manual/sdk-appendix-customizing.rst b/documentation/sdk-manual/appendix-customizing.rst
similarity index 100%
rename from documentation/sdk-manual/sdk-appendix-customizing.rst
rename to documentation/sdk-manual/appendix-customizing.rst
diff --git a/documentation/sdk-manual/sdk-appendix-obtain.rst b/documentation/sdk-manual/appendix-obtain.rst
similarity index 99%
rename from documentation/sdk-manual/sdk-appendix-obtain.rst
rename to documentation/sdk-manual/appendix-obtain.rst
index 8d4fe0964..cdfe2cc85 100644
--- a/documentation/sdk-manual/sdk-appendix-obtain.rst
+++ b/documentation/sdk-manual/appendix-obtain.rst
@@ -246,7 +246,7 @@ Follow these steps to extract the root filesystem:
installed the toolchain (e.g. ``poky_sdk``).
Following is an example based on the toolchain installed in the
- ":ref:`sdk-manual/sdk-appendix-obtain:locating pre-built sdk installers`" section:
+ ":ref:`sdk-manual/appendix-obtain:locating pre-built sdk installers`" section:
::
$ source ~/poky_sdk/environment-setup-core2-64-poky-linux
diff --git a/documentation/sdk-manual/sdk-extensible.rst b/documentation/sdk-manual/extensible.rst
similarity index 100%
rename from documentation/sdk-manual/sdk-extensible.rst
rename to documentation/sdk-manual/extensible.rst
diff --git a/documentation/sdk-manual/index.rst b/documentation/sdk-manual/index.rst
index 177826edf..fce2b199c 100644
--- a/documentation/sdk-manual/index.rst
+++ b/documentation/sdk-manual/index.rst
@@ -10,13 +10,13 @@ Yocto Project Application Development and the Extensible Software Development Ki
:caption: Table of Contents
:numbered:
- sdk-intro
- sdk-extensible
- sdk-using
- sdk-working-projects
- sdk-appendix-obtain
- sdk-appendix-customizing
- sdk-appendix-customizing-standard
+ intro
+ extensible
+ using
+ working-projects
+ appendix-obtain
+ appendix-customizing
+ appendix-customizing-standard
history
.. include:: /boilerplate.rst
diff --git a/documentation/sdk-manual/sdk-intro.rst b/documentation/sdk-manual/intro.rst
similarity index 100%
rename from documentation/sdk-manual/sdk-intro.rst
rename to documentation/sdk-manual/intro.rst
diff --git a/documentation/sdk-manual/sdk-using.rst b/documentation/sdk-manual/using.rst
similarity index 100%
rename from documentation/sdk-manual/sdk-using.rst
rename to documentation/sdk-manual/using.rst
diff --git a/documentation/sdk-manual/sdk-working-projects.rst b/documentation/sdk-manual/working-projects.rst
similarity index 99%
rename from documentation/sdk-manual/sdk-working-projects.rst
rename to documentation/sdk-manual/working-projects.rst
index 4f9764032..3e40936ff 100644
--- a/documentation/sdk-manual/sdk-working-projects.rst
+++ b/documentation/sdk-manual/working-projects.rst
@@ -10,7 +10,7 @@ projects.
Autotools-Based Projects
========================
-Once you have a suitable :ref:`sdk-manual/sdk-intro:the cross-development toolchain`
+Once you have a suitable :ref:`sdk-manual/intro:the cross-development toolchain`
installed, it is very easy to develop a project using the `GNU
Autotools-based <https://en.wikipedia.org/wiki/GNU_Build_System>`__
workflow, which is outside of the :term:`OpenEmbedded Build System`.
diff --git a/documentation/transitioning-to-a-custom-environment.rst b/documentation/transitioning-to-a-custom-environment.rst
index 997f599f5..415f295b3 100644
--- a/documentation/transitioning-to-a-custom-environment.rst
+++ b/documentation/transitioning-to-a-custom-environment.rst
@@ -90,7 +90,7 @@ Transitioning to a custom environment for systems development
#. **Build your image and refine it**.
Add what's missing and fix anything that's broken using your knowledge of the
- :ref:`workflow <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk
+ :ref:`workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk
workflow>` to identify where issues might be occurring.
#. **Consider creating your own distribution**.
diff --git a/documentation/what-i-wish-id-known.rst b/documentation/what-i-wish-id-known.rst
index a8902c0be..a051036bb 100644
--- a/documentation/what-i-wish-id-known.rst
+++ b/documentation/what-i-wish-id-known.rst
@@ -135,7 +135,7 @@ contact us with other suggestions.
valuable links: :ref:`dev-manual/common-tasks:Using a Development
Shell` for information on how to build and run a specific task using
devshell. Also, the :ref:`SDK manual shows how to build out a specific recipe
- <sdk-manual/sdk-extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`.
+ <sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing component>`.
#. **An ambiguous definition: Package vs Recipe:**
A recipe contains instructions the build system uses to create
@@ -195,9 +195,9 @@ contact us with other suggestions.
* **Look Through the Yocto Project Application Development and the Extensible
Software Development Kit (eSDK) manual**: This manual describes how to use
both the standard SDK and the extensible SDK, which are used primarily for
- application development. The :doc:`/sdk-manual/sdk-extensible` also provides
+ application development. The :doc:`/sdk-manual/extensible` also provides
example workflows that use devtool. See the section
- :ref:`sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow`
+ :ref:`sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow`
for more information.
* **Learn About Kernel Development**: If you want to see how to work with the
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 10/10] ref-manual: remove 'ref' from filenames
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
` (8 preceding siblings ...)
2020-12-03 21:38 ` [PATCH 09/10] sdk-manual: remove 'sdk' " Nicolas Dechesne
@ 2020-12-03 21:38 ` Nicolas Dechesne
9 siblings, 0 replies; 11+ messages in thread
From: Nicolas Dechesne @ 2020-12-03 21:38 UTC (permalink / raw)
To: docs; +Cc: Nicolas Dechesne
All filenames duplicate the 'manual name', which is not needed, and
make all references longer than they should. Rename all files to be as
consise as possible, and fix all references
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
documentation/brief-yoctoprojectqs/index.rst | 8 +++---
documentation/bsp-guide/bsp.rst | 10 +++----
documentation/dev-manual/common-tasks.rst | 24 ++++++++---------
documentation/dev-manual/start.rst | 4 +--
documentation/overview-manual/concepts.rst | 6 ++---
documentation/overview-manual/yp-intro.rst | 10 +++----
.../{ref-classes.rst => classes.rst} | 4 +--
...ol-reference.rst => devtool-reference.rst} | 6 ++---
documentation/ref-manual/faq.rst | 2 +-
.../{ref-features.rst => features.rst} | 0
.../ref-manual/{ref-images.rst => images.rst} | 0
documentation/ref-manual/index.rst | 26 +++++++++----------
.../{ref-kickstart.rst => kickstart.rst} | 0
documentation/ref-manual/migration-1.5.rst | 2 +-
documentation/ref-manual/migration-1.6.rst | 2 +-
documentation/ref-manual/migration-1.7.rst | 4 +--
documentation/ref-manual/migration-2.1.rst | 2 +-
documentation/ref-manual/migration-2.3.rst | 2 +-
.../{ref-qa-checks.rst => qa-checks.rst} | 0
...elease-process.rst => release-process.rst} | 2 +-
.../{ref-structure.rst => structure.rst} | 2 +-
...quirements.rst => system-requirements.rst} | 0
.../ref-manual/{ref-tasks.rst => tasks.rst} | 2 +-
.../ref-manual/{ref-terms.rst => terms.rst} | 8 +++---
.../{ref-variables.rst => variables.rst} | 14 +++++-----
.../{ref-varlocality.rst => varlocality.rst} | 0
documentation/test-manual/intro.rst | 6 ++---
27 files changed, 73 insertions(+), 73 deletions(-)
rename documentation/ref-manual/{ref-classes.rst => classes.rst} (99%)
rename documentation/ref-manual/{ref-devtool-reference.rst => devtool-reference.rst} (98%)
rename documentation/ref-manual/{ref-features.rst => features.rst} (100%)
rename documentation/ref-manual/{ref-images.rst => images.rst} (100%)
rename documentation/ref-manual/{ref-kickstart.rst => kickstart.rst} (100%)
rename documentation/ref-manual/{ref-qa-checks.rst => qa-checks.rst} (100%)
rename documentation/ref-manual/{ref-release-process.rst => release-process.rst} (98%)
rename documentation/ref-manual/{ref-structure.rst => structure.rst} (99%)
rename documentation/ref-manual/{ref-system-requirements.rst => system-requirements.rst} (100%)
rename documentation/ref-manual/{ref-tasks.rst => tasks.rst} (99%)
rename documentation/ref-manual/{ref-terms.rst => terms.rst} (98%)
rename documentation/ref-manual/{ref-variables.rst => variables.rst} (99%)
rename documentation/ref-manual/{ref-varlocality.rst => varlocality.rst} (100%)
diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst
index 5dc0bc792..f077ee843 100644
--- a/documentation/brief-yoctoprojectqs/index.rst
+++ b/documentation/brief-yoctoprojectqs/index.rst
@@ -52,7 +52,7 @@ following requirements:
- Runs a supported Linux distribution (i.e. recent releases of Fedora,
openSUSE, CentOS, Debian, or Ubuntu). For a list of Linux
distributions that support the Yocto Project, see the
- :ref:`ref-manual/ref-system-requirements:supported linux distributions`
+ :ref:`ref-manual/system-requirements:supported linux distributions`
section in the Yocto Project Reference Manual. For detailed
information on preparing your build host, see the
:ref:`dev-manual/start:preparing the build host`
@@ -68,7 +68,7 @@ following requirements:
If your build host does not meet any of these three listed version
requirements, you can take steps to prepare the system so that you
can still use the Yocto Project. See the
-:ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`
+:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
section in the Yocto Project Reference Manual for information.
Build Host Packages
@@ -85,7 +85,7 @@ distribution:
.. note::
For host package requirements on all supported Linux distributions,
- see the :ref:`ref-manual/ref-system-requirements:required packages for the build host`
+ see the :ref:`ref-manual/system-requirements:required packages for the build host`
section in the Yocto Project Reference Manual.
Use Git to Clone Poky
@@ -169,7 +169,7 @@ an entire Linux distribution, including the toolchain, from source.
page of the Yocto Project Wiki.
#. **Initialize the Build Environment:** From within the ``poky``
- directory, run the :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``
+ directory, run the :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``
environment
setup script to define Yocto Project's build environment on your
build host.
diff --git a/documentation/bsp-guide/bsp.rst b/documentation/bsp-guide/bsp.rst
index 48bff35fa..068ab6c80 100644
--- a/documentation/bsp-guide/bsp.rst
+++ b/documentation/bsp-guide/bsp.rst
@@ -81,7 +81,7 @@ directory of that Layer. This directory is what you add to the
``conf/bblayers.conf`` file found in your
:term:`Build Directory`, which is
established after you run the OpenEmbedded build environment setup
-script (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``).
+script (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``).
Adding the root directory allows the :term:`OpenEmbedded Build System`
to recognize the BSP
layer and from it build an image. Here is an example: ::
@@ -229,7 +229,7 @@ section.
#. *Initialize the Build Environment:* While in the root directory of
the Source Directory (i.e. ``poky``), run the
- :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\`` environment
+ :ref:`ref-manual/structure:\`\`oe-init-build-env\`\`` environment
setup script to define the OpenEmbedded build environment on your
build host. ::
@@ -826,7 +826,7 @@ workflow.
The build process supports several types of images to satisfy
different needs. See the
- ":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+ ":ref:`ref-manual/images:Images`" chapter in the Yocto
Project Reference Manual for information on supported images.
Requirements and Recommendations for Released BSPs
@@ -1305,7 +1305,7 @@ the example reference machine configuration file for the BeagleBone
development boards. Realize that much more can be defined as part of a
machine's configuration file. In general, you can learn about related
variables that this example does not have by locating the variables in
-the ":ref:`ref-manual/ref-variables:variables glossary`" in the Yocto
+the ":ref:`ref-manual/variables:variables glossary`" in the Yocto
Project Reference Manual.
- :term:`PREFERRED_PROVIDER_virtual/xserver <PREFERRED_PROVIDER>`:
@@ -1360,7 +1360,7 @@ Project Reference Manual.
`JFFS2 <https://en.wikipedia.org/wiki/JFFS2>`__ image.
- :term:`WKS_FILE`: The location of
- the :ref:`Wic kickstart <ref-manual/ref-kickstart:openembedded kickstart (\`\`.wks\`\`) reference>` file used
+ the :ref:`Wic kickstart <ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference>` file used
by the OpenEmbedded build system to create a partitioned image
(image.wic).
diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 6c4220dd5..ada3bac7e 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -935,7 +935,7 @@ configures the image you are working with to include
.. note::
- See the ":ref:`ref-manual/ref-features:image features`" section in the Yocto
+ See the ":ref:`ref-manual/features:image features`" section in the Yocto
Project Reference Manual for a complete list of image features that ship
with the Yocto Project.
@@ -1076,7 +1076,7 @@ how to create, write, and test a new recipe.
For information on variables that are useful for recipes and for
information about recipe naming issues, see the
- ":ref:`ref-manual/ref-varlocality:recipes`" section of the Yocto Project
+ ":ref:`ref-manual/varlocality:recipes`" section of the Yocto Project
Reference Manual.
Overview
@@ -1978,7 +1978,7 @@ take. The following list describes the process:
of common problems that show up during runtime. For information on
these checks, see the
:ref:`insane <ref-classes-insane>` class and
- the ":ref:`ref-manual/ref-qa-checks:qa error and warning messages`"
+ the ":ref:`ref-manual/qa-checks:qa error and warning messages`"
chapter in the Yocto Project Reference Manual.
- *Hand-Checking Your Packages*: After you build your software, you
@@ -3127,7 +3127,7 @@ Using ``devtool upgrade``
As mentioned earlier, an alternative method for upgrading recipes to
newer versions is to use
-:doc:`devtool upgrade </ref-manual/ref-devtool-reference>`.
+:doc:`devtool upgrade </ref-manual/devtool-reference>`.
You can read about ``devtool upgrade`` in general in the
":ref:`sdk-manual/extensible:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
section in the Yocto Project Application Development and the Extensible
@@ -3714,7 +3714,7 @@ The following figure and list overviews the build process:
can be the name of a recipe for a specific piece of software such as
BusyBox. For more details about the images the OpenEmbedded build
system supports, see the
- ":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+ ":ref:`ref-manual/images:Images`" chapter in the Yocto
Project Reference Manual.
As an example, the following command builds the
@@ -5234,7 +5234,7 @@ particular system.
.. note::
For a kickstart file reference, see the
- ":ref:`ref-manual/ref-kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
+ ":ref:`ref-manual/kickstart:openembedded kickstart (\`\`.wks\`\`) reference`"
Chapter in the Yocto Project Reference Manual.
The ``wic`` command and the infrastructure it is based on is by
@@ -7418,7 +7418,7 @@ Creating Node Package Manager (NPM) Packages
manager for the JavaScript programming language. The Yocto Project
supports the NPM :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`. You can
use this fetcher in combination with
-:doc:`devtool </ref-manual/ref-devtool-reference>` to create
+:doc:`devtool </ref-manual/devtool-reference>` to create
recipes that produce NPM packages.
Two workflows exist that allow you to create NPM packages using
@@ -7446,7 +7446,7 @@ NPM packages:
is NPM's public registry.
- Be familiar with
- :doc:`devtool </ref-manual/ref-devtool-reference>`.
+ :doc:`devtool </ref-manual/devtool-reference>`.
- The NPM host tools need the native ``nodejs-npm`` package, which is
part of the OpenEmbedded environment. You need to get the package by
@@ -8452,7 +8452,7 @@ you set up the environment to use these tests, run available tests, and
write and add your own tests.
For information on the test and QA infrastructure available within the
-Yocto Project, see the ":ref:`ref-manual/ref-release-process:testing and quality assurance`"
+Yocto Project, see the ":ref:`ref-manual/release-process:testing and quality assurance`"
section in the Yocto Project Reference Manual.
Enabling Tests
@@ -9224,7 +9224,7 @@ In addition to variable values, the output of the ``bitbake -e`` and
- The output starts with a tree listing all configuration files and
classes included globally, recursively listing the files they include
or inherit in turn. Much of the behavior of the OpenEmbedded build
- system (including the behavior of the :ref:`ref-manual/ref-tasks:normal recipe build tasks`) is
+ system (including the behavior of the :ref:`ref-manual/tasks:normal recipe build tasks`) is
implemented in the
:ref:`base <ref-classes-base>` class and the
classes it inherits, rather than being built into BitBake itself.
@@ -9564,7 +9564,7 @@ compile. BitBake recognizes that the ``do_compile`` task was rerun and
therefore understands that the other tasks also need to be run again.
Another, shorter way to rerun a task and all
-:ref:`ref-manual/ref-tasks:normal recipe build tasks`
+:ref:`ref-manual/tasks:normal recipe build tasks`
that depend on it is to use the ``-C`` option.
.. note::
@@ -9998,7 +9998,7 @@ GDB allows you to examine running programs, which in turn helps you to
understand and fix problems. It also allows you to perform post-mortem
style analysis of program crashes. GDB is available as a package within
the Yocto Project and is installed in SDK images by default. See the
-":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
+":ref:`ref-manual/images:Images`" chapter in the Yocto
Project Reference Manual for a description of these images. You can find
information on GDB at https://sourceware.org/gdb/.
diff --git a/documentation/dev-manual/start.rst b/documentation/dev-manual/start.rst
index 6fad4c9b4..03061a79f 100644
--- a/documentation/dev-manual/start.rst
+++ b/documentation/dev-manual/start.rst
@@ -325,7 +325,7 @@ Project Build Host:
If your build host does not meet any of these three listed version
requirements, you can take steps to prepare the system so that you
can still use the Yocto Project. See the
- ":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+ ":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
section in the Yocto Project Reference Manual for information.
4. *Install Development Host Packages:* Required development host
@@ -334,7 +334,7 @@ Project Build Host:
is large if you want to be able to cover all cases.
For lists of required packages for all scenarios, see the
- ":ref:`ref-manual/ref-system-requirements:required packages for the build host`"
+ ":ref:`ref-manual/system-requirements:required packages for the build host`"
section in the Yocto Project Reference Manual.
Once you have completed the previous steps, you are ready to continue
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 019ead85c..8fbbabbac 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -112,7 +112,7 @@ Class files (``.bbclass``) contain information that is useful to share
between recipes files. An example is the
:ref:`autotools <ref-classes-autotools>` class,
which contains common settings for any application that Autotools uses.
-The ":ref:`ref-manual/ref-classes:Classes`" chapter in the
+The ":ref:`ref-manual/classes:Classes`" chapter in the
Yocto Project Reference Manual provides details about classes and how to
use them.
@@ -456,7 +456,7 @@ typically find in the distribution layer:
can be shared among recipes in the distribution. When your recipes
inherit a class, they take on the settings and functions for that
class. You can read more about class files in the
- ":ref:`ref-manual/ref-classes:Classes`" chapter of the Yocto
+ ":ref:`ref-manual/classes:Classes`" chapter of the Yocto
Reference Manual.
- *conf:* This area holds configuration files for the layer
@@ -1285,7 +1285,7 @@ this output:
.. note::
For a list of example images that the Yocto Project provides, see the
- ":doc:`/ref-manual/ref-images`" chapter in the Yocto Project Reference
+ ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference
Manual.
The build process writes images out to the :term:`Build Directory`
diff --git a/documentation/overview-manual/yp-intro.rst b/documentation/overview-manual/yp-intro.rst
index c66b4b5da..66a88c952 100644
--- a/documentation/overview-manual/yp-intro.rst
+++ b/documentation/overview-manual/yp-intro.rst
@@ -111,7 +111,7 @@ Project:
development.
- *Releases According to a Strict Schedule:* Major releases occur on a
- :doc:`six-month cycle </ref-manual/ref-release-process>`
+ :doc:`six-month cycle </ref-manual/release-process>`
predictably in October and April. The most recent two releases
support point releases to address common vulnerabilities and
exposures. This predictability is crucial for projects based on the
@@ -676,7 +676,7 @@ these items that make up the Poky repository in the
If you are interested in all the contents of the
poky
- Git repository, see the ":ref:`ref-manual/ref-structure:top-level core components`"
+ Git repository, see the ":ref:`ref-manual/structure:top-level core components`"
section in the Yocto Project Reference Manual.
The following figure illustrates what generally comprises Poky:
@@ -720,7 +720,7 @@ Poky has a regular, well established, six-month release cycle under its
own version. Major releases occur at the same time major releases (point
releases) occur for the Yocto Project, which are typically in the Spring
and Fall. For more information on the Yocto Project release schedule and
-cadence, see the ":doc:`/ref-manual/ref-release-process`" chapter in the
+cadence, see the ":doc:`/ref-manual/release-process`" chapter in the
Yocto Project Reference Manual.
Much has been said about Poky being a "default configuration". A default
@@ -798,7 +798,7 @@ Some Basic Terms
It helps to understand some basic fundamental terms when learning the
Yocto Project. Although a list of terms exists in the ":doc:`Yocto Project
-Terms </ref-manual/ref-terms>`" section of the Yocto Project
+Terms </ref-manual/terms>`" section of the Yocto Project
Reference Manual, this section provides the definitions of some terms
helpful for getting started:
@@ -879,7 +879,7 @@ helpful for getting started:
It is worth noting that the term "package" can, in general, have
subtle meanings. For example, the packages referred to in the
- ":ref:`ref-manual/ref-system-requirements:required packages for the build host`"
+ ":ref:`ref-manual/system-requirements:required packages for the build host`"
section in the Yocto Project Reference Manual are compiled binaries
that, when installed, add functionality to your Linux distribution.
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/classes.rst
similarity index 99%
rename from documentation/ref-manual/ref-classes.rst
rename to documentation/ref-manual/classes.rst
index 37ab4992e..5a30ce379 100644
--- a/documentation/ref-manual/ref-classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -1033,7 +1033,7 @@ You can configure the sanity checks so that specific test failures
either raise a warning or an error message. Typically, failures for new
tests generate a warning. Subsequent failures for the same test would
then generate an error message once the metadata is in a known and good
-condition. See the ":doc:`ref-qa-checks`" Chapter for a list of all the warning
+condition. See the ":doc:`/ref-manual/qa-checks`" Chapter for a list of all the warning
and error messages you might encounter using a default configuration.
Use the :term:`WARN_QA` and
@@ -1276,7 +1276,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and
- ``textrel:`` Checks for ELF binaries that contain relocations in
their ``.text`` sections, which can result in a performance impact at
runtime. See the explanation for the ``ELF binary`` message in
- ":doc:`ref-qa-checks`" for more information regarding runtime performance
+ ":doc:`/ref-manual/qa-checks`" for more information regarding runtime performance
issues.
- ``unlisted-pkg-lics:`` Checks that all declared licenses applying
diff --git a/documentation/ref-manual/ref-devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst
similarity index 98%
rename from documentation/ref-manual/ref-devtool-reference.rst
rename to documentation/ref-manual/devtool-reference.rst
index 2b97bb460..cc5848fd4 100644
--- a/documentation/ref-manual/ref-devtool-reference.rst
+++ b/documentation/ref-manual/devtool-reference.rst
@@ -193,7 +193,7 @@ external source tree.
run your application. If dependent packages (e.g. libraries) do not
exist on the target, your application, when run, will fail to find
those functions. For more information, see the
- ":ref:`ref-manual/ref-devtool-reference:deploying your software on the target machine`"
+ ":ref:`ref-manual/devtool-reference:deploying your software on the target machine`"
section.
By default, ``devtool add`` uses the latest revision (i.e. master) when
@@ -561,7 +561,7 @@ Removing Your Software from the Target Machine
Use the ``devtool undeploy-target`` command to remove deployed build
output from the target machine. For the ``devtool undeploy-target``
command to work, you must have previously used the
-":ref:`devtool deploy-target <ref-manual/ref-devtool-reference:deploying your software on the target machine>`"
+":ref:`devtool deploy-target <ref-manual/devtool-reference:deploying your software on the target machine>`"
command.
::
@@ -609,7 +609,7 @@ The ``devtool status`` command has no command-line options:
$ devtool status
Following is sample output after using
-:ref:`devtool add <ref-manual/ref-devtool-reference:adding a new recipe to the workspace layer>`
+:ref:`devtool add <ref-manual/devtool-reference:adding a new recipe to the workspace layer>`
to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory:
::
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index cc6b3aee1..f67c53824 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -22,7 +22,7 @@ Can I still use the Yocto Project?
**A:** You can get the required tools on your host development system a
couple different ways (i.e. building a tarball or downloading a
tarball). See the
-":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
section for steps on how to update your build tools.
**Q:** How can you claim Poky / OpenEmbedded-Core is stable?
diff --git a/documentation/ref-manual/ref-features.rst b/documentation/ref-manual/features.rst
similarity index 100%
rename from documentation/ref-manual/ref-features.rst
rename to documentation/ref-manual/features.rst
diff --git a/documentation/ref-manual/ref-images.rst b/documentation/ref-manual/images.rst
similarity index 100%
rename from documentation/ref-manual/ref-images.rst
rename to documentation/ref-manual/images.rst
diff --git a/documentation/ref-manual/index.rst b/documentation/ref-manual/index.rst
index 033f4ba28..deb0383cf 100644
--- a/documentation/ref-manual/index.rst
+++ b/documentation/ref-manual/index.rst
@@ -10,20 +10,20 @@ Yocto Project Reference Manual
:caption: Table of Contents
:numbered:
- ref-system-requirements
- ref-terms
- ref-release-process
+ system-requirements
+ terms
+ release-process
migration
- ref-structure
- ref-classes
- ref-tasks
- ref-devtool-reference
- ref-kickstart
- ref-qa-checks
- ref-images
- ref-features
- ref-variables
- ref-varlocality
+ structure
+ classes
+ tasks
+ devtool-reference
+ kickstart
+ qa-checks
+ images
+ features
+ variables
+ varlocality
faq
resources
history
diff --git a/documentation/ref-manual/ref-kickstart.rst b/documentation/ref-manual/kickstart.rst
similarity index 100%
rename from documentation/ref-manual/ref-kickstart.rst
rename to documentation/ref-manual/kickstart.rst
diff --git a/documentation/ref-manual/migration-1.5.rst b/documentation/ref-manual/migration-1.5.rst
index b5e4bb1fd..2716bc9cf 100644
--- a/documentation/ref-manual/migration-1.5.rst
+++ b/documentation/ref-manual/migration-1.5.rst
@@ -26,7 +26,7 @@ provide packages for these, you can install and use the Buildtools
tarball, which provides an SDK-like environment containing them.
For more information on this requirement, see the
-":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
section.
.. _migration-1.5-atom-pc-bsp:
diff --git a/documentation/ref-manual/migration-1.6.rst b/documentation/ref-manual/migration-1.6.rst
index f95f45ec9..ed155d0df 100644
--- a/documentation/ref-manual/migration-1.6.rst
+++ b/documentation/ref-manual/migration-1.6.rst
@@ -126,7 +126,7 @@ Changes to Variables
--------------------
The following variables have changed. For information on the
-OpenEmbedded build system variables, see the ":doc:`ref-variables`" Chapter.
+OpenEmbedded build system variables, see the ":doc:`/ref-manual/variables`" Chapter.
.. _migration-1.6-variable-changes-TMPDIR:
diff --git a/documentation/ref-manual/migration-1.7.rst b/documentation/ref-manual/migration-1.7.rst
index 177d40900..19275b3cd 100644
--- a/documentation/ref-manual/migration-1.7.rst
+++ b/documentation/ref-manual/migration-1.7.rst
@@ -32,7 +32,7 @@ build host is now 1.7.8 because the ``--list`` option is now required by
BitBake's Git fetcher. As always, if your host distribution does not
provide a version of Git that meets this requirement, you can use the
``buildtools-tarball`` that does. See the
-":ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
section for more information.
.. _migration-1.7-autotools-class-changes:
@@ -157,7 +157,7 @@ The following changes have occurred to the QA check process:
added in order to verify that file dependencies are satisfied (e.g.
package contains a script requiring ``/bin/bash``) and build-time
dependencies are declared, respectively. For more information, please
- see the ":doc:`ref-qa-checks`" chapter.
+ see the ":doc:`/ref-manual/qa-checks`" chapter.
- Package QA checks are now performed during a new
:ref:`ref-tasks-package_qa` task rather than being
diff --git a/documentation/ref-manual/migration-2.1.rst b/documentation/ref-manual/migration-2.1.rst
index a1d7b9a2d..e8b3ada26 100644
--- a/documentation/ref-manual/migration-2.1.rst
+++ b/documentation/ref-manual/migration-2.1.rst
@@ -360,7 +360,7 @@ These additional changes exist:
- The minimum Git version has been increased to 1.8.3.1. If your host
distribution does not provide a sufficiently recent version, you can
install the buildtools, which will provide it. See the
- :ref:`ref-manual/ref-system-requirements:required git, tar, python and gcc versions`
+ :ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
section for more information on the buildtools tarball.
- The buggy and incomplete support for the RPM version 4 package
diff --git a/documentation/ref-manual/migration-2.3.rst b/documentation/ref-manual/migration-2.3.rst
index 6984ff91e..3e9758119 100644
--- a/documentation/ref-manual/migration-2.3.rst
+++ b/documentation/ref-manual/migration-2.3.rst
@@ -404,7 +404,7 @@ The following QA checks have changed:
For additional information, see the
:ref:`insane <ref-classes-insane>` class and the
- ":ref:`ref-manual/ref-qa-checks:errors and warnings`" section.
+ ":ref:`ref-manual/qa-checks:errors and warnings`" section.
.. _migration-2.3-miscellaneous-changes:
diff --git a/documentation/ref-manual/ref-qa-checks.rst b/documentation/ref-manual/qa-checks.rst
similarity index 100%
rename from documentation/ref-manual/ref-qa-checks.rst
rename to documentation/ref-manual/qa-checks.rst
diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/release-process.rst
similarity index 98%
rename from documentation/ref-manual/ref-release-process.rst
rename to documentation/ref-manual/release-process.rst
index 20be09a4f..d8d362282 100644
--- a/documentation/ref-manual/ref-release-process.rst
+++ b/documentation/ref-manual/release-process.rst
@@ -146,7 +146,7 @@ consists of the following pieces:
.. note::
Running ``oe-selftest`` requires host packages beyond the "Essential"
- grouping. See the :ref:`ref-manual/ref-system-requirements:required packages for the build host`
+ grouping. See the :ref:`ref-manual/system-requirements:required packages for the build host`
section for more information.
Originally, much of this testing was done manually. However, significant
diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/structure.rst
similarity index 99%
rename from documentation/ref-manual/ref-structure.rst
rename to documentation/ref-manual/structure.rst
index ab9075b9c..ad3f4ab44 100644
--- a/documentation/ref-manual/ref-structure.rst
+++ b/documentation/ref-manual/structure.rst
@@ -682,7 +682,7 @@ generation or packaging also have their specific class files such as
``image.bbclass``, ``rootfs_*.bbclass`` and ``package*.bbclass``.
For reference information on classes, see the
-":ref:`ref-manual/ref-classes:Classes`" chapter.
+":ref:`ref-manual/classes:Classes`" chapter.
.. _structure-meta-conf:
diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/system-requirements.rst
similarity index 100%
rename from documentation/ref-manual/ref-system-requirements.rst
rename to documentation/ref-manual/system-requirements.rst
diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/tasks.rst
similarity index 99%
rename from documentation/ref-manual/ref-tasks.rst
rename to documentation/ref-manual/tasks.rst
index 8b9e0c2d8..9fe1c296a 100644
--- a/documentation/ref-manual/ref-tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -461,7 +461,7 @@ devtool commands:
$ devtool latest-version
$ devtool check-upgrade-status
-See the ":ref:`ref-manual/ref-devtool-reference:\`\`devtool\`\` quick reference`"
+See the ":ref:`ref-manual/devtool-reference:\`\`devtool\`\` quick reference`"
chapter for more information on
``devtool``. See the ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`"
section for information on checking the upgrade status of a recipe.
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/terms.rst
similarity index 98%
rename from documentation/ref-manual/ref-terms.rst
rename to documentation/ref-manual/terms.rst
index f41073602..c07dd4b12 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/terms.rst
@@ -64,7 +64,7 @@ universal, the list includes them just in case:
This term refers to the area used by the OpenEmbedded build system for
builds. The area is created when you ``source`` the setup environment
script that is found in the Source Directory
- (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``). The
+ (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). The
:term:`TOPDIR` variable points to the Build Directory.
You have a lot of flexibility when creating the Build Directory.
@@ -117,7 +117,7 @@ universal, the list includes them just in case:
Files that provide for logic encapsulation and inheritance so that
commonly used patterns can be defined once and then easily used in
multiple recipes. For reference information on the Yocto Project classes,
- see the ":ref:`ref-manual/ref-classes:Classes`" chapter. Class files end with the
+ see the ":ref:`ref-manual/classes:Classes`" chapter. Class files end with the
``.bbclass`` filename extension.
:term:`Configuration File`
@@ -177,7 +177,7 @@ universal, the list includes them just in case:
recipes and related Metadata. Images are the binary output that run on
specific hardware or QEMU and are used for specific use-cases. For a list
of the supported image types that the Yocto Project provides, see the
- ":ref:`ref-manual/ref-images:Images`" chapter.
+ ":ref:`ref-manual/images:Images`" chapter.
:term:`Layer`
A collection of related recipes. Layers allow you to consolidate related
@@ -252,7 +252,7 @@ universal, the list includes them just in case:
It is worth noting that the term "package" can, in general, have
subtle meanings. For example, the packages referred to in the
- ":ref:`ref-manual/ref-system-requirements:required packages for the build host`"
+ ":ref:`ref-manual/system-requirements:required packages for the build host`"
section are compiled binaries that, when installed, add functionality to
your Linux distribution.
diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/variables.rst
similarity index 99%
rename from documentation/ref-manual/ref-variables.rst
rename to documentation/ref-manual/variables.rst
index 865d17c1f..8c6cc46b6 100644
--- a/documentation/ref-manual/ref-variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -1670,7 +1670,7 @@ system and gives an overview of their function and contents.
``${TMPDIR}/deploy``.
For more information on the structure of the Build Directory, see
- ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
+ ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
For more detail on the contents of the ``deploy`` directory, see the
":ref:`overview-manual/concepts:images`",
":ref:`overview-manual/concepts:package feeds`", and
@@ -1708,7 +1708,7 @@ system and gives an overview of their function and contents.
``${DEPLOY_DIR}/images/${MACHINE}/``.
For more information on the structure of the Build Directory, see
- ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section.
+ ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
For more detail on the contents of the ``deploy`` directory, see the
":ref:`overview-manual/concepts:images`" and
":ref:`overview-manual/concepts:application development sdk`" sections both in
@@ -2907,7 +2907,7 @@ system and gives an overview of their function and contents.
":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section of the Yocto Project Development Tasks Manual. Reference
material for Wic is located in the
- ":doc:`/ref-manual/ref-kickstart`" chapter.
+ ":doc:`/ref-manual/kickstart`" chapter.
:term:`IMAGE_BOOT_FILES`
A space-separated list of files installed into the boot partition
@@ -2943,7 +2943,7 @@ system and gives an overview of their function and contents.
":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section of the Yocto Project Development Tasks Manual. Reference
material for Wic is located in the
- ":doc:`/ref-manual/ref-kickstart`" chapter.
+ ":doc:`/ref-manual/kickstart`" chapter.
:term:`IMAGE_CLASSES`
A list of classes that all images should inherit. You typically use
@@ -3051,7 +3051,7 @@ system and gives an overview of their function and contents.
.. note::
- When working with a
- :ref:`core-image-minimal-initramfs <ref-manual/ref-images:images>`
+ :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
image, do not use the ``IMAGE_INSTALL`` variable to specify
packages for installation. Instead, use the
:term:`PACKAGE_INSTALL` variable, which
@@ -5240,7 +5240,7 @@ system and gives an overview of their function and contents.
general, you should use the
:term:`IMAGE_INSTALL` variable to specify
packages for installation. The exception to this is when working with
- the :ref:`core-image-minimal-initramfs <ref-manual/ref-images:images>`
+ the :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
image. When working with an initial RAM filesystem (initramfs) image,
use the ``PACKAGE_INSTALL`` variable. For information on creating an
initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
@@ -8737,7 +8737,7 @@ system and gives an overview of their function and contents.
image, see the
":ref:`dev-manual/common-tasks:creating partitioned images using wic`"
section in the Yocto Project Development Tasks Manual. For details on
- the kickstart file format, see the ":doc:`/ref-manual/ref-kickstart`" Chapter.
+ the kickstart file format, see the ":doc:`/ref-manual/kickstart`" Chapter.
:term:`WKS_FILE_DEPENDS`
When placed in the recipe that builds your image, this variable lists
diff --git a/documentation/ref-manual/ref-varlocality.rst b/documentation/ref-manual/varlocality.rst
similarity index 100%
rename from documentation/ref-manual/ref-varlocality.rst
rename to documentation/ref-manual/varlocality.rst
diff --git a/documentation/test-manual/intro.rst b/documentation/test-manual/intro.rst
index 3dc64bcd4..81c24a8c3 100644
--- a/documentation/test-manual/intro.rst
+++ b/documentation/test-manual/intro.rst
@@ -124,7 +124,7 @@ thefollowing types of tests:
The tests utilize the ``testsdkext`` class and the ``do_testsdkext`` task.
- *Feature Testing:* Various scenario-based tests are run through the
- :ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/ref-release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distrubutions
+ :ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distrubutions
we support.
- *Image Testing:* Image tests initiated through the following command::
@@ -155,8 +155,8 @@ thefollowing types of tests:
the ``do_testsdk`` task.
- *Unit Testing:* Unit tests on various components of the system run
- through :ref:`bitbake-selftest <ref-manual/ref-release-process:Testing and Quality Assurance>` and
- :ref:`oe-selftest <ref-manual/ref-release-process:Testing and Quality Assurance>`.
+ through :ref:`bitbake-selftest <ref-manual/release-process:Testing and Quality Assurance>` and
+ :ref:`oe-selftest <ref-manual/release-process:Testing and Quality Assurance>`.
- *Automatic Upgrade Helper:* This target tests whether new versions of
software are available and whether we can automatically upgrade to
--
2.29.2
^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-12-03 21:39 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-03 21:38 [PATCH 00/10] Simplify file names Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 01/10] sphinx: rename top level document in each manual Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 02/10] sphinx: use absolute paths for :doc: references Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 03/10] test-manual: remove 'test-manual' from filenames Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 04/10] toaster-manual: remove 'toaster-manual' " Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 05/10] dev-manual: remove 'dev-manual' " Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 06/10] kernel-dev: remove 'kernel-dev' " Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 07/10] profile-manual: remove 'profile-manual' " Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 08/10] overview-manual: remove 'overview-manual' " Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 09/10] sdk-manual: remove 'sdk' " Nicolas Dechesne
2020-12-03 21:38 ` [PATCH 10/10] ref-manual: remove 'ref' " Nicolas Dechesne
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.