diff options
Diffstat (limited to 'documentation/ref-manual/ref-classes.rst')
| -rw-r--r-- | documentation/ref-manual/ref-classes.rst | 34 |
1 files changed, 17 insertions, 17 deletions
diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst index e0cdbe87fa..4147044ea3 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: |