From 8b1909aa6f7a51a878dc3d4a9223403ad3e164a9 Mon Sep 17 00:00:00 2001 From: Michael Opdenacker Date: Thu, 5 Jan 2023 08:34:26 +0100 Subject: manuals: simplify references to classes Now that .bbclass is removed from class section titles. We can now have, for example, :ref:`ref-classes-insane` instead of :ref:`insane `. Then, when necessary, rework paragraphs so that they have lines of even length, not exceeding 80 characters. (From yocto-docs rev: e76190e3be78c1e483bec0469f1e437dbf8f3791) Signed-off-by: Michael Opdenacker Suggested-by: Quentin Schulz Signed-off-by: Richard Purdie --- documentation/overview-manual/concepts.rst | 58 +++++++++++++----------------- 1 file changed, 24 insertions(+), 34 deletions(-) (limited to 'documentation/overview-manual') diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst index d2edfc3427..4cee4bb169 100644 --- a/documentation/overview-manual/concepts.rst +++ b/documentation/overview-manual/concepts.rst @@ -107,8 +107,7 @@ Classes ------- Class files (``.bbclass``) contain information that is useful to share -between recipes files. An example is the -:ref:`autotools ` class, +between recipes files. An example is the :ref:`ref-classes-autotools` class, which contains common settings for any application that is built with the :wikipedia:`GNU Autotools `. The ":ref:`ref-manual/classes:Classes`" chapter in the Yocto Project @@ -561,11 +560,11 @@ reside somewhere local to a project --- perhaps a directory into which the user checks in items (e.g. a local directory containing a development source tree used by the group). -The canonical method through which to include a local project is to use -the :ref:`externalsrc ` -class to include that local project. You use either the ``local.conf`` -or a recipe's append file to override or set the recipe to point to the -local directory on your disk to pull in the whole source tree. +The canonical method through which to include a local project is to use the +:ref:`ref-classes-externalsrc` class to include that local project. You use +either the ``local.conf`` or a recipe's append file to override or set the +recipe to point to the local directory on your disk to pull in the whole +source tree. Source Control Managers (Optional) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -628,8 +627,7 @@ types, and you specify which classes to enable through the :term:`PACKAGE_CLASSES` variable. Before placing the packages into package feeds, the build process validates them with generated output quality assurance checks -through the :ref:`insane ` -class. +through the :ref:`ref-classes-insane` class. The package feed area resides in the :term:`Build Directory`. The directory the build system uses to temporarily store packages is determined by a @@ -840,14 +838,12 @@ This step in the build process consists of the following tasks: are specific to configurations for the source code being built by the recipe. - If you are using the - :ref:`autotools ` class, + If you are using the :ref:`ref-classes-autotools` class, you can add additional configuration options by using the :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS` variables. For information on how this variable works within that - class, see the - :ref:`autotools ` class + class, see the :ref:`ref-classes-autotools` class :yocto_git:`here `. - *do_compile*: Once a configuration task has been satisfied, @@ -920,7 +916,7 @@ the analysis and package splitting process use several areas: - :term:`STAGING_DIR_TARGET`: The path for the sysroot used when a component that is built to execute on a system and it generates code for yet another machine - (e.g. :ref:`cross-canadian ` recipes). + (e.g. :ref:`ref-classes-cross-canadian` recipes). The :term:`FILES` variable defines the files that go into each package in @@ -1006,13 +1002,11 @@ is read-only. The final stages of the :ref:`ref-tasks-rootfs` task handle post processing. Post processing includes creation of a manifest file and optimizations. -The manifest file (``.manifest``) resides in the same directory as the -root filesystem image. This file lists out, line-by-line, the installed -packages. The manifest file is useful for the -:ref:`testimage ` class, +The manifest file (``.manifest``) resides in the same directory as the root +filesystem image. This file lists out, line-by-line, the installed packages. +The manifest file is useful for the :ref:`ref-classes-testimage` class, for example, to determine whether or not to run specific tests. See the -:term:`IMAGE_MANIFEST` -variable for additional information. +:term:`IMAGE_MANIFEST` variable for additional information. Optimizing processes that are run across the image include ``mklibs`` and any other post-processing commands as defined by the @@ -1751,12 +1745,11 @@ half the problem of supporting a shared state. The other half of the problem is being able to use checksum information during the build and being able to reuse or rebuild specific components. -The :ref:`sstate ` class is a -relatively generic implementation of how to "capture" a snapshot of a -given task. The idea is that the build process does not care about the -source of a task's output. Output could be freshly built or it could be -downloaded and unpacked from somewhere. In other words, the build -process does not need to worry about its origin. +The :ref:`ref-classes-sstate` class is a relatively generic implementation of +how to "capture" a snapshot of a given task. The idea is that the build process +does not care about the source of a task's output. Output could be freshly +built or it could be downloaded and unpacked from somewhere. In other words, +the build process does not need to worry about its origin. Two types of output exist. One type is just about creating a directory in :term:`WORKDIR`. A good example is @@ -1767,10 +1760,9 @@ type of output occurs when a set of data is merged into a shared directory tree such as the sysroot. The Yocto Project team has tried to keep the details of the -implementation hidden in the :ref:`sstate ` class. From a user's perspective, +implementation hidden in the :ref:`ref-classes-sstate` class. From a user's perspective, adding shared state wrapping to a task is as simple as this -:ref:`ref-tasks-deploy` example taken -from the :ref:`deploy ` class:: +:ref:`ref-tasks-deploy` example taken from the :ref:`ref-classes-deploy` class:: DEPLOYDIR = "${WORKDIR}/deploy-${PN}" SSTATETASKS += "do_deploy" @@ -1786,11 +1778,9 @@ from the :ref:`deploy ` class:: The following list explains the previous example: -- Adding ``do_deploy`` to ``SSTATETASKS`` adds some required - sstate-related processing, which is implemented in the - :ref:`sstate ` class, to - before and after the - :ref:`ref-tasks-deploy` task. +- Adding ``do_deploy`` to ``SSTATETASKS`` adds some required sstate-related + processing, which is implemented in the :ref:`ref-classes-sstate` class, to + before and after the :ref:`ref-tasks-deploy` task. - The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that :ref:`ref-tasks-deploy` places its output in ``${DEPLOYDIR}`` when run normally -- cgit v1.2.3-54-g00ecf