diff options
Diffstat (limited to 'poky/documentation/ref-manual')
| -rw-r--r-- | poky/documentation/ref-manual/classes.rst | 18 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/devtool-reference.rst | 10 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/faq.rst | 2 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/features.rst | 2 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/kickstart.rst | 2 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/migration-2.2.rst | 2 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/qa-checks.rst | 8 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/release-process.rst | 4 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/resources.rst | 12 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/structure.rst | 22 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/system-requirements.rst | 20 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/tasks.rst | 3 | ||||
| -rw-r--r-- | poky/documentation/ref-manual/variables.rst | 128 |
13 files changed, 128 insertions, 105 deletions
diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst index 9a1fc2c93f..6dd0cbbd41 100644 --- a/poky/documentation/ref-manual/classes.rst +++ b/poky/documentation/ref-manual/classes.rst @@ -1006,10 +1006,10 @@ package name override, in this example ``${PN}``, must be used:: INSANE_SKIP_${PN} += "dev-so" Please keep in mind that the QA checks -exist in order to detect real or potential problems in the packaged +are meant to detect real or potential problems in the packaged output. So exercise caution when disabling these checks. -The following list shows the tests you can list with the ``WARN_QA`` and +Here are the tests you can list with the ``WARN_QA`` and ``ERROR_QA`` variables: - ``already-stripped:`` Checks that produced binaries have not @@ -1085,8 +1085,8 @@ The following list shows the tests you can list with the ``WARN_QA`` and - ``dev-so:`` Checks that the ``.so`` symbolic links are in the ``-dev`` package and not in any of the other packages. In general, these symlinks are only useful for development purposes. Thus, the - ``-dev`` package is the correct location for them. Some very rare - cases do exist for dynamically loaded modules where these symlinks + ``-dev`` package is the correct location for them. In very rare + cases, such as dynamically loaded modules, these symlinks are needed instead in the main package. - ``file-rdeps:`` Checks that file-level dependencies identified by @@ -1260,8 +1260,8 @@ The following list shows the tests you can list with the ``WARN_QA`` and .. note:: - If you are not using runtime package management on your target - system, then you do not need to worry about this situation. + This is only relevant when you are using runtime package management + on your target system. - ``xorg-driver-abi:`` Checks that all packages containing Xorg drivers have ABI dependencies. The ``xserver-xorg`` recipe provides @@ -1676,7 +1676,7 @@ couple different ways: nativesdk-myrecipe.bb - Not doing so can lead to subtle problems because code exists that + Not doing so can lead to subtle problems because there is code that depends on the naming convention. Although applied differently, the ``nativesdk`` class is used with both @@ -1714,10 +1714,10 @@ section in the Yocto Project Development Tasks Manual. ``oelint.bbclass`` ================== -The ``oelint`` class is an obsolete lint checking tool that exists in +The ``oelint`` class is an obsolete lint checking tool available in ``meta/classes`` in the :term:`Source Directory`. -A number of classes exist that could be generally useful in OE-Core but +There are some classes that could be generally useful in OE-Core but are never actually used within OE-Core itself. The ``oelint`` class is one such example. However, being aware of this class can reduce the proliferation of different versions of similar classes across multiple diff --git a/poky/documentation/ref-manual/devtool-reference.rst b/poky/documentation/ref-manual/devtool-reference.rst index 0ce3219831..1862c481df 100644 --- a/poky/documentation/ref-manual/devtool-reference.rst +++ b/poky/documentation/ref-manual/devtool-reference.rst @@ -403,8 +403,8 @@ Upgrading a Recipe As software matures, upstream recipes are upgraded to newer versions. As a developer, you need to keep your local recipes up-to-date with the -upstream version releases. Several methods exist by which you can -upgrade recipes. You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`" +upstream version releases. There are several ways of upgrading recipes. +You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`" section of the Yocto Project Development Tasks Manual. This section overviews the ``devtool upgrade`` command. @@ -516,8 +516,8 @@ you do, the package manager is bypassed. should never use it to update an image that will be used in production. -Some conditions exist that could prevent a deployed application from -behaving as expected. When both of the following conditions exist, your +Some conditions could prevent a deployed application from +behaving as expected. When both of the following conditions are met, your application has the potential to not behave correctly when run on the target: @@ -528,7 +528,7 @@ target: - The target does not physically have the packages on which the application depends installed. -If both of these conditions exist, your application will not behave as +If both of these conditions are met, your application will not behave as expected. The reason for this misbehavior is because the ``devtool deploy-target`` command does not deploy the packages (e.g. libraries) on which your new application depends. The assumption is that diff --git a/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst index e7bca829a3..f1b564a60e 100644 --- a/poky/documentation/ref-manual/faq.rst +++ b/poky/documentation/ref-manual/faq.rst @@ -312,7 +312,7 @@ HTTPS requests and direct them to the ``http://`` sources mirror. You can use ``file://`` URLs to point to local directories or network shares as well. -Aside from the previous technique, these options also exist:: +Here are other options:: BB_NO_NETWORK = "1" diff --git a/poky/documentation/ref-manual/features.rst b/poky/documentation/ref-manual/features.rst index eb4947d594..31d24b8c28 100644 --- a/poky/documentation/ref-manual/features.rst +++ b/poky/documentation/ref-manual/features.rst @@ -196,7 +196,7 @@ you can add several different predefined packages such as development utilities or packages with debug information needed to investigate application problems or profile applications. -The following image features are available for all images: +Here are the image features available for all images: - *allow-empty-password:* Allows Dropbear and OpenSSH to accept root logins and logins from accounts having an empty password string. diff --git a/poky/documentation/ref-manual/kickstart.rst b/poky/documentation/ref-manual/kickstart.rst index 843292b528..8308ffff5b 100644 --- a/poky/documentation/ref-manual/kickstart.rst +++ b/poky/documentation/ref-manual/kickstart.rst @@ -210,5 +210,5 @@ supports the following options: - ``--configfile``: Specifies a user-defined configuration file for the bootloader. You can provide a full pathname for the file or a - file that exists in the ``canned-wks`` folder. This option overrides + file located in the ``canned-wks`` folder. This option overrides all other bootloader options. diff --git a/poky/documentation/ref-manual/migration-2.2.rst b/poky/documentation/ref-manual/migration-2.2.rst index a9d3cde7b7..a60ce8d52b 100644 --- a/poky/documentation/ref-manual/migration-2.2.rst +++ b/poky/documentation/ref-manual/migration-2.2.rst @@ -422,7 +422,7 @@ The following miscellaneous changes have occurred: :term:`SRCREV` by default when fetching from a Git repository. You can override this in either case to use ``${``\ :term:`AUTOREV`\ ``}`` instead by using the - ``-a`` or ``DASHDASHautorev`` command-line option + ``-a`` or ``--autorev`` command-line option - ``distcc``: GTK+ UI is now disabled by default. diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst index 9cc4c577c7..2e98713a27 100644 --- a/poky/documentation/ref-manual/qa-checks.rst +++ b/poky/documentation/ref-manual/qa-checks.rst @@ -97,7 +97,7 @@ Errors and Warnings - ``<packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]`` - A runtime dependency exists between the two specified packages, but + There is a runtime dependency between the two specified packages, but there is nothing explicit within the recipe to enable the OpenEmbedded build system to ensure that dependency is satisfied. This condition is usually triggered by an @@ -303,7 +303,7 @@ Errors and Warnings - ``<packagename> rdepends on <debug_packagename> [debug-deps]`` - A dependency exists between the specified non-dbg package (i.e. a + There is a dependency between the specified non-dbg package (i.e. a package whose name does not end in ``-dbg``) and a package that is a ``dbg`` package. The ``dbg`` packages contain debug symbols and are brought in using several different methods: @@ -326,7 +326,7 @@ Errors and Warnings - ``<packagename> rdepends on <dev_packagename> [dev-deps]`` - A dependency exists between the specified non-dev package (a package + There is a dependency between the specified non-dev package (a package whose name does not end in ``-dev``) and a package that is a ``dev`` package. The ``dev`` packages contain development headers and are usually brought in using several different methods: @@ -753,6 +753,6 @@ how to work with the QA checks, see the .. note:: - Please keep in mind that the QA checks exist in order to detect real + Please keep in mind that the QA checks are meant to detect real or potential problems in the packaged output. So exercise caution when disabling these checks. diff --git a/poky/documentation/ref-manual/release-process.rst b/poky/documentation/ref-manual/release-process.rst index 93ab6ed08a..935a2e39bb 100644 --- a/poky/documentation/ref-manual/release-process.rst +++ b/poky/documentation/ref-manual/release-process.rst @@ -82,14 +82,14 @@ stable release. bug fixes and security fixes only. Policy dictates that features are not backported to a stable release. This policy means generic recipe version upgrades are unlikely to be accepted for backporting. The - exception to this policy occurs when a strong reason exists such as + exception to this policy occurs when there is a strong reason such as the fix happens to also be the preferred upstream approach. Stable release branches have strong maintenance for about a year after their initial release. Should significant issues be found for any release regardless of its age, fixes could be backported to older releases. For issues that are not backported given an older release, -Community LTS trees and branches exist where community members share +Community LTS trees and branches allow community members to share patches for older releases. However, these types of patches do not go through the same release process as do point releases. You can find more information about stable branch maintenance at diff --git a/poky/documentation/ref-manual/resources.rst b/poky/documentation/ref-manual/resources.rst index 663f0d96d5..5ffd2b3991 100644 --- a/poky/documentation/ref-manual/resources.rst +++ b/poky/documentation/ref-manual/resources.rst @@ -10,7 +10,7 @@ Introduction ============ The Yocto Project team is happy for people to experiment with the Yocto -Project. A number of places exist to find help if you run into +Project. There is a number of places where you can find help if you run into difficulties or find bugs. This presents information about contributing and participating in the Yocto Project. @@ -43,8 +43,7 @@ the Yocto Project itself (e.g. when discovering an issue with some component of the build system that acts contrary to the documentation or your expectations). -A general procedure and guidelines exist for when you use Bugzilla to -submit a bug. For information on how to use Bugzilla to submit a bug +For a general procedure and guidelines on how to use Bugzilla to submit a bug against the Yocto Project, see the following: - The ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`" @@ -59,7 +58,7 @@ For information on Bugzilla in general, see https://www.bugzilla.org/about/. Mailing lists ============= -A number of mailing lists maintained by the Yocto Project exist as well +There are multiple mailing lists maintained by the Yocto Project as well as related OpenEmbedded mailing lists for discussion, patch submission and announcements. To subscribe to one of the following mailing lists, click on the appropriate URL in the following list and follow the @@ -156,9 +155,8 @@ Here is a list of resources you might find helpful: - :yocto_docs:`Yocto Project Mega-Manual </singleindex.html>`\ *:* This manual is simply a single HTML file comprised of the bulk of the Yocto - Project manuals. The Mega-Manual primarily exists as a vehicle by - which you can easily search for phrases and terms used in the Yocto - Project documentation set. + Project manuals. It makes it easy to search for phrases and terms used + in the Yocto Project documentation set. - :doc:`/profile-manual/index` *:* This manual presents a set of common and generally useful tracing and profiling schemes along with diff --git a/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst index f8dc7d2821..36c9efc1e2 100644 --- a/poky/documentation/ref-manual/structure.rst +++ b/poky/documentation/ref-manual/structure.rst @@ -38,7 +38,7 @@ usually matches the current stable BitBake release from the BitBake project. BitBake, a :term:`Metadata` interpreter, reads the Yocto Project Metadata and runs the tasks defined by that data. Failures are usually caused by errors in your Metadata and not from BitBake -itself; consequently, most users do not need to worry about BitBake. +itself. When you run the ``bitbake`` command, the main BitBake executable (which resides in the ``bitbake/bin/`` directory) starts. Sourcing the @@ -279,7 +279,7 @@ file, it uses ``sed`` to substitute final .. note:: You can see how the ``TEMPLATECONF`` variable is used by looking at the - ``scripts/oe-setup-builddir``` script in the :term:`Source Directory`. + ``scripts/oe-setup-builddir`` script in the :term:`Source Directory`. You can find the Yocto Project version of the ``local.conf.sample`` file in the ``meta-poky/conf`` directory. @@ -510,8 +510,8 @@ should be automatic, and recipes should not directly reference ----------------------- Previous versions of the OpenEmbedded build system used to create a -global shared sysroot per machine along with a native sysroot. Beginning -with the 2.3 version of the Yocto Project, sysroots exist in +global shared sysroot per machine along with a native sysroot. Since +the 2.3 version of the Yocto Project, there are sysroots in recipe-specific :term:`WORKDIR` directories. Thus, the ``build/tmp/sysroots/`` directory is unused. @@ -601,7 +601,7 @@ constructed using the architecture of the given build (e.g. name, and the version of the recipe (i.e. :term:`PE`\ ``:``\ :term:`PV`\ ``-``\ :term:`PR`). -A number of key subdirectories exist within each recipe work directory: +Here are key subdirectories within each recipe work directory: - ``${WORKDIR}/temp``: Contains the log files of each task executed for this recipe, the "run" files for each executed task, which contain @@ -624,7 +624,7 @@ A number of key subdirectories exist within each recipe work directory: - ``${WORKDIR}/packages-split``: Contains the output of the ``do_package`` task after the output has been split into individual - packages. Subdirectories exist for each individual package created by + packages. There are subdirectories for each individual package created by the recipe. - ``${WORKDIR}/recipe-sysroot``: A directory populated with the target @@ -783,7 +783,7 @@ system. The tools, however, can also be used on targets. This directory contains non-essential applications that add features compared to the alternatives in core. You might need this directory for -full tool functionality or for Linux Standard Base (LSB) compliance. +full tool functionality. .. _structure-meta-recipes-gnome: @@ -809,14 +809,6 @@ libraries. This directory contains the kernel and generic applications and libraries that have strong kernel dependencies. -.. _structure-meta-recipes-lsb4: - -``meta/recipes-lsb4/`` ----------------------- - -This directory contains recipes specifically added to support the Linux -Standard Base (LSB) version 4.x. - .. _structure-meta-recipes-multimedia: ``meta/recipes-multimedia/`` diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst index 4fa4d3ef52..e9d995c61b 100644 --- a/poky/documentation/ref-manual/system-requirements.rst +++ b/poky/documentation/ref-manual/system-requirements.rst @@ -41,7 +41,7 @@ distributions: - Ubuntu 18.04 (LTS) -- Ubuntu 20.04 +- Ubuntu 20.04 (LTS) - Fedora 30 @@ -66,9 +66,8 @@ distributions: - While the Yocto Project Team attempts to ensure all Yocto Project releases are one hundred percent compatible with each officially - supported Linux distribution, instances might exist where you - encounter a problem while using the Yocto Project on a specific - distribution. + supported Linux distribution, you may still encounter problems + that happen only with a specific distribution. - Yocto Project releases are tested against the stable Linux distributions in the above list. The Yocto Project should work @@ -111,7 +110,7 @@ function. Ubuntu and Debian ----------------- -The following list shows the required packages by function given a +Here are the required packages by function given a supported Ubuntu or Debian Linux distribution: .. note:: @@ -119,8 +118,7 @@ supported Ubuntu or Debian Linux distribution: - If your build system has the ``oss4-dev`` package installed, you might experience QEMU build failures due to the package installing its own custom ``/usr/include/linux/soundcard.h`` on the Debian - system. If you run into this situation, either of the following - solutions exist:: + system. If you run into this situation, try either of these solutions:: $ sudo apt-get build-dep qemu $ sudo apt-get remove oss4-dev @@ -150,7 +148,7 @@ supported Ubuntu or Debian Linux distribution: Fedora Packages --------------- -The following list shows the required packages by function given a +Here are the required packages by function given a supported Fedora Linux distribution: - *Essentials:* Packages needed to build an image for a headless @@ -167,7 +165,7 @@ supported Fedora Linux distribution: openSUSE Packages ----------------- -The following list shows the required packages by function given a +Here are the required packages by function given a supported openSUSE Linux distribution: - *Essentials:* Packages needed to build an image for a headless @@ -185,7 +183,7 @@ supported openSUSE Linux distribution: CentOS-7 Packages ----------------- -The following list shows the required packages by function given a +Here are the required packages by function given a supported CentOS-7 Linux distribution: - *Essentials:* Packages needed to build an image for a headless @@ -212,7 +210,7 @@ supported CentOS-7 Linux distribution: CentOS-8 Packages ----------------- -The following list shows the required packages by function given a +Here are the required packages by function given a supported CentOS-8 Linux distribution: - *Essentials:* Packages needed to build an image for a headless diff --git a/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst index 001edf6bb3..5bceb79b8d 100644 --- a/poky/documentation/ref-manual/tasks.rst +++ b/poky/documentation/ref-manual/tasks.rst @@ -823,6 +823,5 @@ sections from a size-sensitive configuration. After the kernel is unpacked but before it is patched, this task makes sure that the machine and metadata branches as specified by the :term:`SRCREV` variables actually exist on the specified -branches. If these branches do not exist and -:term:`AUTOREV` is not being used, the +branches. Otherwise, if :term:`AUTOREV` is not being used, the ``do_validate_branches`` task fails during the build. diff --git a/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst index c339d45e18..df6413b68a 100644 --- a/poky/documentation/ref-manual/variables.rst +++ b/poky/documentation/ref-manual/variables.rst @@ -49,10 +49,9 @@ system and gives an overview of their function and contents. alternatives system to create a different binary naming scheme so the commands can co-exist. - To use the variable, list out the package's commands that also exist - as part of another package. For example, if the ``busybox`` package - has four commands that also exist as part of another package, you - identify them as follows:: + To use the variable, list out the package's commands that are also + provided by another package. For example, if the ``busybox`` package + has four such commands, you identify them as follows:: ALTERNATIVE_busybox = "sh sed test bracket" @@ -306,8 +305,8 @@ system and gives an overview of their function and contents. variable), the OpenEmbedded build system ignores your request and will install the packages to avoid dependency errors. - Support for this variable exists only when using the IPK and RPM - packaging backend. Support does not exist for DEB. + This variable is supported only when using the IPK and RPM + packaging backends. DEB is not supported. See the :term:`NO_RECOMMENDATIONS` and the :term:`PACKAGE_EXCLUDE` variables for related @@ -336,8 +335,8 @@ system and gives an overview of their function and contents. - This host list is only used if ``BB_NO_NETWORK`` is either not set or set to "0". - - Limited support for wildcard matching against the beginning of - host names exists. For example, the following setting matches + - There is limited support for wildcard matching against the beginning of + host names. For example, the following setting matches ``git.gnu.org``, ``ftp.gnu.org``, and ``foo.git.gnu.org``. :: @@ -558,7 +557,7 @@ system and gives an overview of their function and contents. :term:`BBCLASSEXTEND` Allows you to extend a recipe so that it builds variants of the - software. Common variants for recipes exist such as "natives" like + software. There are common variants for recipes as "natives" like ``quilt-native``, which is a copy of Quilt built to run on the build system; "crosses" such as ``gcc-cross``, which is a compiler built to run on the build machine but produces binaries that run on the target @@ -1237,7 +1236,7 @@ system and gives an overview of their function and contents. CONFFILES_${PN} += "${sysconfdir}/file1 \ ${sysconfdir}/file2 ${sysconfdir}/file3" - A relationship exists between the ``CONFFILES`` and ``FILES`` + There is a relationship between the ``CONFFILES`` and ``FILES`` variables. The files listed within ``CONFFILES`` must be a subset of the files listed within ``FILES``. Because the configuration files you provide with ``CONFFILES`` are simply being identified so that @@ -1417,8 +1416,8 @@ system and gives an overview of their function and contents. :term:`COREBASE_FILES` Lists files from the :term:`COREBASE` directory that should be copied other than the layers listed in the - ``bblayers.conf`` file. The ``COREBASE_FILES`` variable exists for - the purpose of copying metadata from the OpenEmbedded build system + ``bblayers.conf`` file. The ``COREBASE_FILES`` variable allows + to copy metadata from the OpenEmbedded build system into the extensible SDK. Explicitly listing files in ``COREBASE`` is needed because it @@ -1525,10 +1524,10 @@ system and gives an overview of their function and contents. :term:`DEBUG_BUILD` Specifies to build packages with debugging information. This - influences the value of the ``SELECTED_OPTIMIZATION`` variable. + influences the value of the :term:`SELECTED_OPTIMIZATION` variable. :term:`DEBUG_OPTIMIZATION` - The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when + The options to pass in :term:`TARGET_CFLAGS` and :term:`CFLAGS` when compiling a system for debugging. This variable defaults to "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe". @@ -1538,7 +1537,7 @@ system and gives an overview of their function and contents. The most common usage of this is variable is to set it to "-1" within a recipe for a development version of a piece of software. Using the variable in this way causes the stable version of the recipe to build - by default in the absence of ``PREFERRED_VERSION`` being used to + by default in the absence of :term:`PREFERRED_VERSION` being used to build the development version. .. note:: @@ -2460,8 +2459,8 @@ system and gives an overview of their function and contents. ``FILESEXTRAPATHS`` variable. You can take advantage of this searching behavior in useful ways. For - example, consider a case where the following directory structure - exists for general and machine-specific configurations:: + example, consider a case where there is the following directory structure + for general and machine-specific configurations:: files/defconfig files/MACHINEA/defconfig @@ -2579,7 +2578,7 @@ system and gives an overview of their function and contents. Set the variable to "1" to force the removal of these packages. :term:`FULL_OPTIMIZATION` - The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when + The options to pass in :term:`TARGET_CFLAGS` and :term:`CFLAGS` when compiling an optimized system. This variable defaults to "-O2 -pipe ${DEBUG_FLAGS}". @@ -3013,8 +3012,8 @@ system and gives an overview of their function and contents. Image recipes set ``IMAGE_INSTALL`` to specify the packages to install into an image through ``image.bbclass``. Additionally, - "helper" classes such as the - :ref:`core-image <ref-classes-core-image>` class exist that can + there are "helper" classes such as the + :ref:`core-image <ref-classes-core-image>` class which can take lists used with ``IMAGE_FEATURES`` and turn them into auto-generated entries in ``IMAGE_INSTALL`` in addition to its default contents. @@ -3465,8 +3464,8 @@ system and gives an overview of their function and contents. Use of the ``INHIBIT_SYSROOT_STRIP`` variable occurs in rare and special circumstances. For example, suppose you are building bare-metal firmware by using an external GCC toolchain. Furthermore, - even if the toolchain's binaries are strippable, other files exist - that are needed for the build that are not strippable. + even if the toolchain's binaries are strippable, there are other files + needed for the build that are not strippable. :term:`INITRAMFS_FSTYPES` Defines the format for the output image of an initial RAM filesystem @@ -3745,6 +3744,44 @@ system and gives an overview of their function and contents. ":ref:`kernel-dev/common:using an "in-tree" \`\`defconfig\`\` file`" section in the Yocto Project Linux Kernel Development Manual. + :term:`KCONFIG_MODE` + When used with the :ref:`kernel-yocto <ref-classes-kernel-yocto>` + class, specifies the kernel configuration values to use for options + not specified in the provided ``defconfig`` file. Valid options are:: + + KCONFIG_MODE = "alldefconfig" + KCONFIG_MODE = "allnoconfig" + + In ``alldefconfig`` mode the options not explicitly specified will be + assigned their Kconfig default value. In ``allnoconfig`` mode the + options not explicitly specified will be disabled in the kernel + config. + + In case ``KCONFIG_MODE`` is not set the behaviour will depend on where + the ``defconfig`` file is coming from. An "in-tree" ``defconfig`` file + will be handled in ``alldefconfig`` mode, a ``defconfig`` file placed + in ``${WORKDIR}`` through a meta-layer will be handled in + ``allnoconfig`` mode. + + An "in-tree" ``defconfig`` file can be selected via the + :term:`KBUILD_DEFCONFIG` variable. ``KCONFIG_MODE`` does not need to + be explicitly set. + + A ``defconfig`` file compatible with ``allnoconfig`` mode can be + generated by copying the ``.config`` file from a working Linux kernel + build, renaming it to ``defconfig`` and placing it into the Linux + kernel ``${WORKDIR}`` through your meta-layer. ``KCONFIG_MODE`` does + not need to be explicitly set. + + A ``defconfig`` file compatible with ``alldefconfig`` mode can be + generated using the + :ref:`ref-tasks-savedefconfig` + task and placed into the Linux kernel ``${WORKDIR}`` through your + meta-layer. Explicitely set ``KCONFIG_MODE``:: + + KCONFIG_MODE = "alldefconfig" + + :term:`KERNEL_ALT_IMAGETYPE` Specifies an alternate kernel image type for creation in addition to the kernel image type specified using the @@ -3779,7 +3816,7 @@ system and gives an overview of their function and contents. .. note:: - Legacy support exists for specifying the full path to the device + There is legacy support for specifying the full path to the device tree. However, providing just the ``.dtb`` file is preferred. In order to use this variable, the @@ -4004,7 +4041,7 @@ system and gives an overview of their function and contents. :term:`KERNELDEPMODDEPEND` Specifies whether the data referenced through - :term:`PKGDATA_DIR` is needed or not. The + :term:`PKGDATA_DIR` is needed or not. ``KERNELDEPMODDEPEND`` does not control whether or not that data exists, but simply whether or not it is used. If you do not need to use the data, set the ``KERNELDEPMODDEPEND`` variable in your @@ -4189,8 +4226,8 @@ system and gives an overview of their function and contents. - Separate license names using \| (pipe) when there is a choice between licenses. - - Separate license names using & (ampersand) when multiple licenses - exist that cover different parts of the source. + - Separate license names using & (ampersand) when there are + multiple licenses for different parts of the source. - You can use spaces between license names. @@ -4338,8 +4375,8 @@ system and gives an overview of their function and contents. The variable corresponds to a machine configuration file of the same name, through which machine-specific configurations are set. Thus, - when ``MACHINE`` is set to "qemux86" there exists the corresponding - ``qemux86.conf`` machine configuration file, which can be found in + when ``MACHINE`` is set to "qemux86", the corresponding + ``qemux86.conf`` machine configuration file can be found in the :term:`Source Directory` in ``meta/conf/machine``. @@ -4704,7 +4741,7 @@ system and gives an overview of their function and contents. :term:`NO_GENERIC_LICENSE` Avoids QA errors when you use a non-common, non-CLOSED license in a - recipe. Packages exist, such as the linux-firmware package, with many + recipe. There are packages, such as the linux-firmware package, with many licenses that are not in any way common. Also, new licenses are added occasionally to avoid introducing a lot of common license files, which are only applicable to a specific package. @@ -4716,7 +4753,7 @@ system and gives an overview of their function and contents. NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source" - The following is an example that + Here is an example that uses the ``LICENSE.Abilis.txt`` file as the license from the fetched source:: @@ -4748,8 +4785,8 @@ system and gives an overview of their function and contents. functionality, such as kernel modules. It is up to you to add packages with the :term:`IMAGE_INSTALL` variable. - Support for this variable exists only when using the IPK and RPM - packaging backend. Support does not exist for DEB. + This variable is only supported when using the IPK and RPM + packaging backends. DEB is not supported. See the :term:`BAD_RECOMMENDATIONS` and the :term:`PACKAGE_EXCLUDE` variables for @@ -5026,8 +5063,8 @@ system and gives an overview of their function and contents. an iterative development process to remove specific components from a system. - Support for this variable exists only when using the IPK and RPM - packaging backend. Support does not exist for DEB. + This variable is supported only when using the IPK and RPM + packaging backends. DEB is not supported. See the :term:`NO_RECOMMENDATIONS` and the :term:`BAD_RECOMMENDATIONS` variables for @@ -6173,7 +6210,7 @@ system and gives an overview of their function and contents. :term:`PACKAGE_EXCLUDE` variables. Packages specified in ``RRECOMMENDS`` need not actually be produced. - However, a recipe must exist that provides each package, either + However, there must be a recipe providing each package, either through the :term:`PACKAGES` or :term:`PACKAGES_DYNAMIC` variables or the :term:`RPROVIDES` variable, or an error will occur @@ -6653,8 +6690,8 @@ system and gives an overview of their function and contents. value of the :term:`TARGET_CFLAGS` variable. The ``SELECTED_OPTIMIZATION`` variable takes the value of - ``FULL_OPTIMIZATION`` unless ``DEBUG_BUILD`` = "1". If that is the - case, the value of ``DEBUG_OPTIMIZATION`` is used. + :term:`FULL_OPTIMIZATION` unless :term:`DEBUG_BUILD` = "1", in which + case the value of :term:`DEBUG_OPTIMIZATION` is used. :term:`SERIAL_CONSOLE` Defines a serial console (TTY) to enable using @@ -6941,8 +6978,8 @@ system and gives an overview of their function and contents. - ``az://`` - Fetches files from an Azure Storage account. - Standard and recipe-specific options for ``SRC_URI`` exist. Here are - standard options: + There are standard and recipe-specific options for ``SRC_URI``. Here are + standard ones: - ``apply`` - Whether to apply the patch or not. The default action is to apply the patch. @@ -7629,8 +7666,8 @@ system and gives an overview of their function and contents. :term:`TARGET_OS` Specifies the target's operating system. The variable can be set to "linux" for glibc-based systems (GNU C Library) and to "linux-musl" - for musl libc. For ARM/EABI targets, "linux-gnueabi" and - "linux-musleabi" possible values exist. + for musl libc. For ARM/EABI targets, the possible values are + "linux-gnueabi" and "linux-musleabi". :term:`TARGET_PREFIX` Specifies the prefix used for the toolchain binary target tools. @@ -8331,11 +8368,10 @@ system and gives an overview of their function and contents. configure options are simply not passed to the configure script (e.g. should be removed from :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS`). - However, common options, for example, exist that are passed to all - configure scripts at a class level that might not be valid for some - configure scripts. It follows that no benefit exists in seeing a - warning about these options. For these cases, the options are added - to ``UNKNOWN_CONFIGURE_WHITELIST``. + However, there are common options that are passed to all + configure scripts at a class level, but might not be valid for some + configure scripts. Therefore warnings about these options are useless. + For these cases, the options are added to ``UNKNOWN_CONFIGURE_WHITELIST``. The configure arguments check that uses ``UNKNOWN_CONFIGURE_WHITELIST`` is part of the |