From d9adf28c10d4a28538e2f90b97dd8949f28815a6 Mon Sep 17 00:00:00 2001 From: Michael Opdenacker Date: Tue, 29 Mar 2022 08:46:15 +0200 Subject: manuals: replace hyphens with em dashes Fix some hyphens being improperly used as em dashes. See https://www.grammarly.com/blog/hyphens-and-dashes/ Using em dashes may also allow Sphinx to hyphenate and break lines in the best way. Note that the first character after an em dash not supposed to be capitalized, unless a specific rule applies, typically when what follows is a proper noun. Fix a few misuses of parentheses in following text. (From yocto-docs rev: 5918f019f63f6e820b1168f4cc001faa1d1cdc6f) Signed-off-by: Michael Opdenacker Signed-off-by: Richard Purdie --- documentation/ref-manual/classes.rst | 6 ++-- documentation/ref-manual/devtool-reference.rst | 2 +- documentation/ref-manual/faq.rst | 4 +-- documentation/ref-manual/qa-checks.rst | 4 +-- documentation/ref-manual/resources.rst | 12 +++---- documentation/ref-manual/structure.rst | 10 +++--- documentation/ref-manual/terms.rst | 4 +-- documentation/ref-manual/variables.rst | 48 +++++++++++++------------- documentation/ref-manual/varlocality.rst | 2 +- 9 files changed, 46 insertions(+), 46 deletions(-) (limited to 'documentation/ref-manual') diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst index 729aa259e0..d0ed539229 100644 --- a/documentation/ref-manual/classes.rst +++ b/documentation/ref-manual/classes.rst @@ -108,18 +108,18 @@ support is either not present or is broken. It's useful to have some idea of how the tasks defined by the ``autotools*`` classes work and what they do behind the scenes. -- :ref:`ref-tasks-configure` - Regenerates the +- :ref:`ref-tasks-configure` --- regenerates the configure script (using ``autoreconf``) and then launches it with a standard set of arguments used during cross-compilation. You can pass additional parameters to ``configure`` through the :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS` variables. -- :ref:`ref-tasks-compile` - Runs ``make`` with +- :ref:`ref-tasks-compile` --- runs ``make`` with arguments that specify the compiler and linker. You can pass additional arguments through the :term:`EXTRA_OEMAKE` variable. -- :ref:`ref-tasks-install` - Runs ``make install`` and +- :ref:`ref-tasks-install` --- runs ``make install`` and passes in ``${``\ :term:`D`\ ``}`` as ``DESTDIR``. .. _ref-classes-base: diff --git a/documentation/ref-manual/devtool-reference.rst b/documentation/ref-manual/devtool-reference.rst index 10ca70a2b3..997ec0351c 100644 --- a/documentation/ref-manual/devtool-reference.rst +++ b/documentation/ref-manual/devtool-reference.rst @@ -164,7 +164,7 @@ Adding a New Recipe to the Workspace Layer ========================================== Use the ``devtool add`` command to add a new recipe to the workspace -layer. The recipe you add should not exist - ``devtool`` creates it for +layer. The recipe you add should not exist --- ``devtool`` creates it for you. The source files the recipe uses should exist in an external area. The following example creates and adds a new recipe named ``jackson`` to diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst index 3eee9e1be5..2fcbf7da96 100644 --- a/documentation/ref-manual/faq.rst +++ b/documentation/ref-manual/faq.rst @@ -364,7 +364,7 @@ redirect requests through proxy servers. **Q:** Can I get rid of build output so I can start over? -**A:** Yes - you can easily do this. When you use BitBake to build an +**A:** Yes --- you can easily do this. When you use BitBake to build an image, all the build output goes into the directory created when you run the build environment setup script (i.e. :ref:`structure-core-script`). By default, this :term:`Build Directory` @@ -428,7 +428,7 @@ relatively normal and the second is not: build/tmp/sysroots/x86_64-linux/usr/bin Even if the paths look unusual, -they both are correct - the first for a target and the second for a +they both are correct --- the first for a target and the second for a native recipe. These paths are a consequence of the ``DESTDIR`` mechanism and while they appear strange, they are correct and in practice very effective. diff --git a/documentation/ref-manual/qa-checks.rst b/documentation/ref-manual/qa-checks.rst index 8c475d0f72..fbab1dc92e 100644 --- a/documentation/ref-manual/qa-checks.rst +++ b/documentation/ref-manual/qa-checks.rst @@ -613,7 +613,7 @@ Errors and Warnings so using ${:term:`BPN`} rather than ${:term:`PN`} as the latter will change for different variants of the same recipe e.g. when :term:`BBCLASSEXTEND` or multilib are being used. This check will fail if a reference to ``${PN}`` - is found within the :term:`SRC_URI` value - change it to ``${BPN}`` instead. + is found within the :term:`SRC_URI` value --- change it to ``${BPN}`` instead. .. _qa-check-unhandled-features-check: @@ -727,7 +727,7 @@ Errors and Warnings devtool modify This will apply all of the patches, and create new commits out of them in - the workspace - with the patch context updated. + the workspace --- with the patch context updated. Then, replace the patches in the recipe layer:: diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst index c942384662..292a9d6f61 100644 --- a/documentation/ref-manual/resources.rst +++ b/documentation/ref-manual/resources.rst @@ -64,22 +64,22 @@ and announcements. To subscribe to one of the following mailing lists, click on the appropriate URL in the following list and follow the instructions: -- :yocto_lists:`/g/yocto` - General Yocto Project +- :yocto_lists:`/g/yocto` --- general Yocto Project discussion mailing list. -- :oe_lists:`/g/openembedded-core` - Discussion mailing +- :oe_lists:`/g/openembedded-core` --- discussion mailing list about OpenEmbedded-Core (the core metadata). -- :oe_lists:`/g/openembedded-devel` - Discussion +- :oe_lists:`/g/openembedded-devel` --- discussion mailing list about OpenEmbedded. -- :oe_lists:`/g/bitbake-devel` - Discussion mailing +- :oe_lists:`/g/bitbake-devel` --- discussion mailing list about the :term:`BitBake` build tool. -- :yocto_lists:`/g/poky` - Discussion mailing list +- :yocto_lists:`/g/poky` --- discussion mailing list about :term:`Poky`. -- :yocto_lists:`/g/yocto-announce` - Mailing list to +- :yocto_lists:`/g/yocto-announce` --- mailing list to receive official Yocto Project release and milestone announcements. For more Yocto Project-related mailing lists, see the diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst index 12a085552f..bdcffc1947 100644 --- a/documentation/ref-manual/structure.rst +++ b/documentation/ref-manual/structure.rst @@ -213,8 +213,8 @@ These files are standard top-level files. .. _structure-build: -The Build Directory - ``build/`` -================================ +The Build Directory --- ``build/`` +================================== The OpenEmbedded build system creates the :term:`Build Directory` when you run the build environment setup @@ -589,7 +589,7 @@ install" places its output that is then split into sub-packages within ``build/tmp/work/tunearch/recipename/version/`` ----------------------------------------------- -The recipe work directory - ``${WORKDIR}``. +The recipe work directory --- ``${WORKDIR}``. As described earlier in the ":ref:`structure-build-tmp-sysroots`" section, @@ -654,8 +654,8 @@ recipes. In practice, this is only used for ``gcc`` and its variants .. _structure-meta: -The Metadata - ``meta/`` -======================== +The Metadata --- ``meta/`` +========================== As mentioned previously, :term:`Metadata` is the core of the Yocto Project. Metadata has several important subdivisions: diff --git a/documentation/ref-manual/terms.rst b/documentation/ref-manual/terms.rst index 512032a67e..1e3f718a8f 100644 --- a/documentation/ref-manual/terms.rst +++ b/documentation/ref-manual/terms.rst @@ -270,7 +270,7 @@ universal, the list includes them just in case: your Linux distribution. Another point worth noting is that historically within the Yocto - Project, recipes were referred to as packages - thus, the existence + Project, recipes were referred to as packages --- thus, the existence of several BitBake variables that are seemingly mis-named, (e.g. :term:`PR`, :term:`PV`, and :term:`PE`). @@ -369,7 +369,7 @@ universal, the list includes them just in case: Directory created by unpacking a released tarball as compared to cloning ``git://git.yoctoproject.org/poky``. When you unpack a tarball, you have an exact copy of the files based on the time of - release - a fixed release point. Any changes you make to your local + release --- a fixed release point. Any changes you make to your local files in the Source Directory are on top of the release and will remain local only. On the other hand, when you clone the ``poky`` Git repository, you have an active development repository with access to diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst index f723e38d1a..b42854caaa 100644 --- a/documentation/ref-manual/variables.rst +++ b/documentation/ref-manual/variables.rst @@ -591,7 +591,7 @@ system and gives an overview of their function and contents. This variable is useful in situations where the same recipe appears in more than one layer. Setting this variable allows you to prioritize a layer against other layers that contain the same recipe - - effectively letting you control the precedence for the multiple + --- effectively letting you control the precedence for the multiple layers. The precedence established through this variable stands regardless of a recipe's version (:term:`PV` variable). For example, a layer that has a recipe with a higher :term:`PV` value but for @@ -889,7 +889,7 @@ system and gives an overview of their function and contents. :term:`BUILD_OS` Specifies the operating system in use on the build host (e.g. "linux"). The OpenEmbedded build system sets the value of - :term:`BUILD_OS` from the OS reported by the ``uname`` command - the + :term:`BUILD_OS` from the OS reported by the ``uname`` command --- the first word, converted to lower-case characters. :term:`BUILD_PREFIX` @@ -1689,7 +1689,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/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 @@ -1733,7 +1733,7 @@ system and gives an overview of their function and contents. ` class. For more information on the structure of the Build Directory, see - ":ref:`ref-manual/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 @@ -2248,24 +2248,24 @@ system and gives an overview of their function and contents. Here are some examples of features you can add: - - "dbg-pkgs" - Adds -dbg packages for all installed packages including + - "dbg-pkgs" --- adds -dbg packages for all installed packages including symbol information for debugging and profiling. - - "debug-tweaks" - Makes an image suitable for debugging. For example, allows root logins without passwords and + - "debug-tweaks" --- makes an image suitable for debugging. For example, allows root logins without passwords and enables post-installation logging. See the 'allow-empty-password' and 'post-install-logging' features in the ":ref:`ref-features-image`" section for more information. - - "dev-pkgs" - Adds -dev packages for all installed packages. This is + - "dev-pkgs" --- adds -dev packages for all installed packages. This is useful if you want to develop against the libraries in the image. - - "read-only-rootfs" - Creates an image whose root filesystem is + - "read-only-rootfs" --- creates an image whose root filesystem is read-only. See the ":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. - - "tools-sdk" - Adds development tools such as gcc, make, + - "tools-debug" --- adds debugging tools such as gdb and strace. + - "tools-sdk" --- adds development tools such as gcc, make, pkgconfig and so forth. - - "tools-testapps" - Adds useful testing tools + - "tools-testapps" --- adds useful testing tools such as ts_print, aplay, arecord and so forth. For a complete list of image features that ships with the Yocto @@ -3259,7 +3259,7 @@ system and gives an overview of their function and contents. IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}" :term:`IMAGE_NAME_SUFFIX` - Suffix used for the image output filename - defaults to ``".rootfs"`` + Suffix used for the image output filename --- defaults to ``".rootfs"`` to distinguish the image file from other files created during image building; however if this suffix is redundant or not desired you can clear the value of this variable (set the value to ""). For example, @@ -6217,7 +6217,7 @@ system and gives an overview of their function and contents. ``baz``. The names of the packages you list within :term:`RDEPENDS` must be the - names of other packages - they cannot be recipe names. Although + names of other packages --- they cannot be recipe names. Although package names and recipe names usually match, the important point here is that you are providing package names within the :term:`RDEPENDS` variable. For an example of the default list of packages created from @@ -7120,35 +7120,35 @@ system and gives an overview of their function and contents. There are standard and recipe-specific options. Here are standard ones: - - ``apply`` - Whether to apply the patch or not. The default + - ``apply`` --- whether to apply the patch or not. The default action is to apply the patch. - - ``striplevel`` - Which striplevel to use when applying the + - ``striplevel`` --- which striplevel to use when applying the patch. The default level is 1. - - ``patchdir`` - Specifies the directory in which the patch should + - ``patchdir`` --- specifies the directory in which the patch should be applied. The default is ``${``\ :term:`S`\ ``}``. Here are options specific to recipes building code from a revision control system: - - ``mindate`` - Apply the patch only if + - ``mindate`` --- apply the patch only if :term:`SRCDATE` is equal to or greater than ``mindate``. - - ``maxdate`` - Apply the patch only if :term:`SRCDATE` is not later + - ``maxdate`` --- apply the patch only if :term:`SRCDATE` is not later than ``maxdate``. - - ``minrev`` - Apply the patch only if :term:`SRCREV` is equal to or + - ``minrev`` --- apply the patch only if :term:`SRCREV` is equal to or greater than ``minrev``. - - ``maxrev`` - Apply the patch only if :term:`SRCREV` is not later + - ``maxrev`` --- apply the patch only if :term:`SRCREV` is not later than ``maxrev``. - - ``rev`` - Apply the patch only if :term:`SRCREV` is equal to + - ``rev`` --- apply the patch only if :term:`SRCREV` is equal to ``rev``. - - ``notrev`` - Apply the patch only if :term:`SRCREV` is not equal to + - ``notrev`` --- apply the patch only if :term:`SRCREV` is not equal to ``rev``. .. note:: @@ -8857,8 +8857,8 @@ system and gives an overview of their function and contents. - :term:`TMPDIR`: The top-level build output directory - :term:`MULTIMACH_TARGET_SYS`: The target system identifier - :term:`PN`: The recipe name - - :term:`EXTENDPE`: The epoch - (if :term:`PE` is not specified, which - is usually the case for most recipes, then `EXTENDPE` is blank) + - :term:`EXTENDPE`: The epoch --- if :term:`PE` is not specified, which + is usually the case for most recipes, then `EXTENDPE` is blank. - :term:`PV`: The recipe version - :term:`PR`: The recipe revision diff --git a/documentation/ref-manual/varlocality.rst b/documentation/ref-manual/varlocality.rst index 5f7dba8775..e2c086ffa0 100644 --- a/documentation/ref-manual/varlocality.rst +++ b/documentation/ref-manual/varlocality.rst @@ -113,7 +113,7 @@ This section lists variables that are required for recipes. - :term:`LIC_FILES_CHKSUM` -- :term:`SRC_URI` - used in recipes that fetch local or remote files. +- :term:`SRC_URI` --- used in recipes that fetch local or remote files. .. _ref-varlocality-recipe-dependencies: -- cgit v1.2.3-54-g00ecf