mirror of
https://git.yoctoproject.org/poky
synced 2026-05-09 17:39:31 +00:00
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 <michael.opdenacker@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker
committed by
Richard Purdie
Richard Purdie
parent
0d1d3afa8a
commit
d9adf28c10
@@ -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:
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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 <recipe>
|
||||
|
||||
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::
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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.
|
||||
<ref-classes-image>` 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
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user