From d21c35bd81ffb806e5157a43231f8af92c0ba90a Mon Sep 17 00:00:00 2001 From: Michael Opdenacker Date: Tue, 23 Nov 2021 18:49:18 +0100 Subject: misc manuals: add further class references (From yocto-docs rev: 0693f1f8466a118dc707a9c17d5ca528b4ea368a) Signed-off-by: Michael Opdenacker Signed-off-by: Richard Purdie --- documentation/dev-manual/common-tasks.rst | 32 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 17 deletions(-) (limited to 'documentation/dev-manual') diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst index e870cdb545..0c267d5f48 100644 --- a/documentation/dev-manual/common-tasks.rst +++ b/documentation/dev-manual/common-tasks.rst @@ -938,7 +938,8 @@ a recipe and using :term:`EXTRA_IMAGE_FEATURES` from within your :term:`Build Directory`. To understand how these features work, the best reference is -``meta/classes/image.bbclass``. This class lists out the available +:ref:`meta/classes/image.bbclass `. +This class lists out the available :term:`IMAGE_FEATURES` of which most map to package groups while some, such as ``debug-tweaks`` and ``read-only-rootfs``, resolve as general configuration settings. @@ -2113,7 +2114,7 @@ statement that essentially identifies itself as being able to provide PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") == "kernel") else "" }" -Any recipe that inherits the ``kernel`` class is +Any recipe that inherits the :ref:`kernel ` class is going to utilize a :term:`PROVIDES` statement that identifies that recipe as being able to provide the ``virtual/kernel`` item. @@ -2459,7 +2460,7 @@ sometimes you have no choice. The easiest solution is to create a recipe that uses the :ref:`bin_package ` class and to be sure that you are using default locations for build artifacts. -In most cases, the ``bin_package`` class handles "skipping" the +In most cases, the :ref:`bin_package ` class handles "skipping" the configure and compile steps as well as sets things up to grab packages from the appropriate area. In particular, this class sets ``noexec`` on both the :ref:`ref-tasks-configure` @@ -2467,7 +2468,7 @@ and :ref:`ref-tasks-compile` tasks, sets ``FILES:${PN}`` to "/" so that it picks up all files, and sets up a :ref:`ref-tasks-install` task, which effectively copies all files from ``${S}`` to ``${D}``. The -``bin_package`` class works well when the files extracted into ``${S}`` +:ref:`bin_package ` class works well when the files extracted into ``${S}`` are already laid out in the way they should be laid out on the target. For more information on these variables, see the :term:`FILES`, @@ -2492,7 +2493,7 @@ Reference Manual's variable glossary. section in the Yocto Project Overview and Concepts Manual for more information. -If you cannot use the ``bin_package`` class, you need to be sure you are +If you cannot use the :ref:`bin_package ` class, you need to be sure you are doing the following: - Create a recipe where the @@ -2532,7 +2533,7 @@ doing the following: .. note:: - If image prelinking is enabled (e.g. "image-prelink" is in :term:`USER_CLASSES` + If image prelinking is enabled (e.g. :ref:`image-prelink ` is in :term:`USER_CLASSES` which it is by default), prelink will change the binaries in the generated images and this often catches people out. Remove that class to ensure binaries are preserved exactly if that is necessary. @@ -4454,19 +4455,16 @@ Follow these steps to build your target using the files in the downloads directory: 1. *Using Local Files Only:* Inside your ``local.conf`` file, add the - :term:`SOURCE_MIRROR_URL` - variable, inherit the - :ref:`own-mirrors ` - class, and use the - :term:`BB_NO_NETWORK` - variable to your ``local.conf``. + :term:`SOURCE_MIRROR_URL` variable, inherit the + :ref:`own-mirrors ` class, and use the + :term:`BB_NO_NETWORK` variable to your ``local.conf``. :: SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/" INHERIT += "own-mirrors" BB_NO_NETWORK = "1" - The :term:`SOURCE_MIRROR_URL` and ``own-mirror`` + The :term:`SOURCE_MIRROR_URL` and :ref:`own-mirrors ` class set up the system to use the downloads directory as your "own mirror". Using the :term:`BB_NO_NETWORK` variable makes sure that BitBake's fetching process in step 3 stays local, which means files @@ -4751,7 +4749,8 @@ done using the Eventually, all recipes will be covered and this list will not be needed. -For the most part, the Multilib class extension works automatically to +For the most part, the :ref:`Multilib ` +class extension works automatically to extend the package name from ``${PN}`` to ``${MLPREFIX}${PN}``, where :term:`MLPREFIX` is the particular multilib (e.g. "lib32-" or "lib64-"). Standard variables such as @@ -4763,8 +4762,7 @@ Standard variables such as :term:`PACKAGES_DYNAMIC` are automatically extended by the system. If you are extending any manual code in the recipe, you can use the ``${MLPREFIX}`` variable to ensure -those names are extended correctly. This automatic extension code -resides in ``multilib.bbclass``. +those names are extended correctly. Using Multilib ~~~~~~~~~~~~~~ @@ -10993,7 +10991,7 @@ accidental release of proprietary software. The Yocto Project provides an :ref:`archiver ` class to help avoid some of these concerns. -Before you employ :term:`DL_DIR` or the ``archiver`` class, you need to +Before you employ :term:`DL_DIR` or the :ref:`archiver ` class, you need to decide how you choose to provide source. The source ``archiver`` class can generate tarballs and SRPMs and can create them with various levels of compliance in mind. -- cgit v1.2.3-54-g00ecf