MIRRORS/poky
1
0
Fork 0
mirror of git://git.yoctoproject.org/poky.git synced 2025-07-19 12:59:02 +02:00
Code Issues Actions Packages Projects Releases Wiki Activity

manuals: simplify references to classes

Browse Source 
Now that .bbclass is removed from class section titles.
We can now have, for example, :ref:`ref-classes-insane`
instead of :ref:`insane <ref-classes-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 <michael.opdenacker@bootlin.com>
Suggested-by: Quentin Schulz <foss+yocto@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Michael Opdenacker 2023-01-05 08:34:26 +01:00 committed by Richard Purdie
parent ae280972ff
commit 8b1909aa6f
54 changed files with 929 additions and 1035 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/bsp-guide/bsp.rst
View File

@ -1365,7 +1365,7 @@ Project Reference Manual.
- :term:`IMAGE_INSTALL`:
Specifies packages to install into an image through the
:ref:`image <ref-classes-image>` class. Recipes
:ref:`ref-classes-image` class. Recipes
use the :term:`IMAGE_INSTALL` variable.
- ``do_image_wic[depends]``: A task that is constructed during the

12
documentation/dev-manual/build-quality.rst
View File

@ -14,13 +14,11 @@ has already been built when the software is building, the software will
link to the built library and that library will be pulled into your
image along with the new software even if you did not want the library.
The :ref:`buildhistory <ref-classes-buildhistory>`
class helps you maintain the quality of your build output. You
can use the class to highlight unexpected and possibly unwanted changes
in the build output. When you enable build history, it records
information about the contents of each package and image and then
commits that information to a local Git repository where you can examine
the information.
The :ref:`ref-classes-buildhistory` class helps you maintain the quality of
your build output. You can use the class to highlight unexpected and possibly
unwanted changes in the build output. When you enable build history, it records
information about the contents of each package and image and then commits that
information to a local Git repository where you can examine the information.
The remainder of this section describes the following:

15
documentation/dev-manual/building.rst
View File

@ -295,8 +295,8 @@ Follow these steps to create an :term:`Initramfs` image:
recipe, you should use :term:`PACKAGE_INSTALL` rather than
:term:`IMAGE_INSTALL`. :term:`PACKAGE_INSTALL` gives more direct control of
what is added to the image as compared to the defaults you might not
necessarily want that are set by the :ref:`image <ref-classes-image>`
or :ref:`core-image <ref-classes-core-image>` classes.
necessarily want that are set by the :ref:`ref-classes-image`
or :ref:`ref-classes-core-image` classes.
#. *Build the Kernel Image and the Initramfs Image:* Build your kernel
image using BitBake. Because the :term:`Initramfs` image recipe is a
@ -683,7 +683,7 @@ your tunings to best consider build times and package feed maintenance.
A recipe that just generates scripts can enable "all" architecture
because there are no binaries to build. To specifically enable "all"
architecture, be sure your recipe inherits the
:ref:`allarch <ref-classes-allarch>` class.
:ref:`ref-classes-allarch` class.
This class is useful for "all" architectures because it configures
many variables so packages can be used across multiple architectures.
@ -796,7 +796,7 @@ where the development occurs. You want the recipe's
the external directory and use it as is, not copy it.
To build from software that comes from an external source, all you need to do
is inherit the :ref:`externalsrc <ref-classes-externalsrc>` class and then set
is inherit the :ref:`ref-classes-externalsrc` class and then set
the :term:`EXTERNALSRC` variable to point to your external source code. Here
are the statements to put in your ``local.conf`` file::
@ -812,8 +812,7 @@ This next example shows how to accomplish the same thing by setting
.. note::
In order for these settings to take effect, you must globally or
locally inherit the :ref:`externalsrc <ref-classes-externalsrc>`
class.
locally inherit the :ref:`ref-classes-externalsrc` class.
By default, :ref:`ref-classes-externalsrc` builds the source code in a
directory separate from the external source directory as specified by
@ -881,14 +880,14 @@ directory:
#. *Using Local Files Only:* Inside your ``local.conf`` file, add the
:term:`SOURCE_MIRROR_URL` variable, inherit the
:ref:`own-mirrors <ref-classes-own-mirrors>` class, and use the
:ref:`ref-classes-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 :ref:`own-mirrors <ref-classes-own-mirrors>`
The :term:`SOURCE_MIRROR_URL` and :ref:`ref-classes-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

8
documentation/dev-manual/debugging.rst
View File

@ -153,7 +153,7 @@ In addition to variable values, the output of the ``bitbake -e`` and
classes included globally, recursively listing the files they include
or inherit in turn. Much of the behavior of the OpenEmbedded build
system (including the behavior of the :ref:`ref-manual/tasks:normal recipe build tasks`) is
implemented in the :ref:`base <ref-classes-base>` class and the
implemented in the :ref:`ref-classes-base` class and the
classes it inherits, rather than being built into BitBake itself.
- After the variable values, all functions appear in the output. For
@ -196,8 +196,7 @@ Following are a few of the available ``oe-pkgdata-util`` subcommands.
which contains the files stored in that package.
If you want to inspect the ``${WORKDIR}/packages-split``
directory, make sure that
:ref:`rm_work <ref-classes-rm-work>` is not
directory, make sure that :ref:`ref-classes-rm-work` is not
enabled when you build the recipe.
- ``oe-pkgdata-util find-path path ...``: Lists the names of
@ -598,8 +597,7 @@ log to ``${T}/log.do_``\ `task`, and can also log to standard output
The same logging functions are also available in shell functions, under
the names ``bbplain``, ``bbnote``, ``bbdebug``, ``bbwarn``, ``bberror``,
and ``bbfatal``. The
:ref:`logging <ref-classes-logging>` class
and ``bbfatal``. The :ref:`ref-classes-logging` class
implements these functions. See that class in the ``meta/classes``
folder of the :term:`Source Directory` for information.

3
documentation/dev-manual/disk-space.rst
View File

@ -14,8 +14,7 @@ the :term:`Build Directory`::
Adding this statement deletes the work directory used for
building a recipe once the recipe is built. For more information on
"rm_work", see the
:ref:`rm_work <ref-classes-rm-work>` class in the
"rm_work", see the :ref:`ref-classes-rm-work` class in the
Yocto Project Reference Manual.
Purging Duplicate Shared State Cache Files

6
documentation/dev-manual/error-reporting-tool.rst
View File

@ -27,9 +27,9 @@ Enabling and Using the Tool
===========================
By default, the error reporting tool is disabled. You can enable it by
inheriting the :ref:`report-error <ref-classes-report-error>`
class by adding the following statement to the end of your
``local.conf`` file in your :term:`Build Directory`::
inheriting the :ref:`ref-classes-report-error` class by adding the
following statement to the end of your ``local.conf`` file in your
:term:`Build Directory`::
INHERIT += "report-error"

4
documentation/dev-manual/gobject-introspection.rst
View File

@ -39,9 +39,7 @@ Enabling the Generation of Introspection Data
Enabling the generation of introspection data (GIR files) in your
library package involves the following:
#. Inherit the
:ref:`gobject-introspection <ref-classes-gobject-introspection>`
class.
#. Inherit the :ref:`ref-classes-gobject-introspection` class.
#. Make sure introspection is not disabled anywhere in the recipe or
from anything the recipe includes. Also, make sure that

19
documentation/dev-manual/licenses.rst
View File

@ -325,13 +325,12 @@ and not just the source used in the released image. It will include
toolchain source, and other artifacts, which you would not generally
release. However, the more serious issue for most companies is
accidental release of proprietary software. The Yocto Project provides
an :ref:`archiver <ref-classes-archiver>` class to
help avoid some of these concerns.
an :ref:`ref-classes-archiver` class to help avoid some of these concerns.
Before you employ :term:`DL_DIR` or the :ref:`archiver <ref-classes-archiver>` class, you need to
decide how you choose to provide source. The source :ref:`archiver <ref-classes-archiver>` class
can generate tarballs and SRPMs and can create them with various levels
of compliance in mind.
Before you employ :term:`DL_DIR` or the :ref:`ref-classes-archiver` class, you
need to decide how you choose to provide source. The source
:ref:`ref-classes-archiver` class can generate tarballs and SRPMs and can
create them with various levels of compliance in mind.
One way of doing this (but certainly not the only way) is to release
just the source as a tarball. You can do this by adding the following to
@ -417,8 +416,8 @@ generation are included on your image.
adds a separate package and an upgrade path for adding licenses to an
image.
As the source :ref:`archiver <ref-classes-archiver>` class has already archived the original
unmodified source that contains the license files, you would have
As the source :ref:`ref-classes-archiver` class has already archived the
original unmodified source that contains the license files, you would have
already met the requirements for inclusion of the license information
with source as defined by the GPL and other open source licenses.
@ -488,8 +487,8 @@ mechanisms as well as explicitly included in the image recipe with
:term:`IMAGE_INSTALL`, and depends on a static linked library recipe B
(``DEPENDS += "B"``), package B will neither appear in the generated license
manifest nor in the generated source tarballs. This occurs as the
:ref:`license <ref-classes-license>` and :ref:`archiver <ref-classes-archiver>`
classes assume that only packages included via :term:`RDEPENDS` or :term:`RRECOMMENDS`
:ref:`ref-classes-license` and :ref:`ref-classes-archiver` classes assume that
only packages included via :term:`RDEPENDS` or :term:`RRECOMMENDS`
end up in the image.
As a result, potential obligations regarding license compliance for package B

85
documentation/dev-manual/new-recipe.rst
View File

@ -565,7 +565,7 @@ your software is built:
need to modify the configuration.
When using Autotools, your recipe needs to inherit the
:ref:`autotools <ref-classes-autotools>` class and it does not have to
:ref:`ref-classes-autotools` class and it does not have to
contain a :ref:`ref-tasks-configure` task. However, you might still want to
make some adjustments. For example, you can set :term:`EXTRA_OECONF` or
:term:`PACKAGECONFIG_CONFARGS` to pass any needed configure options that
@ -576,7 +576,7 @@ your software is built:
need to modify the configuration.
When you use CMake, your recipe needs to inherit the
:ref:`cmake <ref-classes-cmake>` class and it does not have to contain a
:ref:`ref-classes-cmake` class and it does not have to contain a
:ref:`ref-tasks-configure` task. You can make some adjustments by setting
:term:`EXTRA_OECMAKE` to pass any needed configure options that are
specific to the recipe.
@ -712,7 +712,7 @@ Here are some common issues that cause failures.
":ref:`dev-manual/debugging:debugging parallel make races`" section.
- *Improper host path usage:* This failure applies to recipes building
for the target or ":ref:`nativesdk <ref-classes-nativesdk>`" only. The
for the target or ":ref:`ref-classes-nativesdk`" only. The
failure occurs when the compilation process uses improper headers,
libraries, or other files from the host system when cross-compiling for
the target.
@ -807,14 +807,13 @@ installed correctly.
re-execute :ref:`ref-tasks-install` if needed.
- ``oe_runmake install``, which can be run directly or can be run
indirectly by the
:ref:`autotools <ref-classes-autotools>` and
:ref:`cmake <ref-classes-cmake>` classes,
runs ``make install`` in parallel. Sometimes, a Makefile can have
missing dependencies between targets that can result in race
conditions. If you experience intermittent failures during
:ref:`ref-tasks-install`, you might be able to work around them by disabling
parallel Makefile installs by adding the following to the recipe::
indirectly by the :ref:`ref-classes-autotools` and
:ref:`ref-classes-cmake` classes, runs ``make install`` in parallel.
Sometimes, a Makefile can have missing dependencies between targets that
can result in race conditions. If you experience intermittent failures
during :ref:`ref-tasks-install`, you might be able to work around them by
disabling parallel Makefile installs by adding the following to the
recipe::
PARALLEL_MAKEINST = ""
@ -854,7 +853,7 @@ different ways:
shutdown of all other programs.
To enable a service using SysVinit, your recipe needs to inherit the
:ref:`update-rc.d <ref-classes-update-rc.d>` class. The class helps
:ref:`ref-classes-update-rc.d` class. The class helps
facilitate safely installing the package on the target.
You will need to set the
@ -870,7 +869,7 @@ different ways:
https://freedesktop.org/wiki/Software/systemd/.
To enable a service using systemd, your recipe needs to inherit the
:ref:`systemd <ref-classes-systemd>` class. See the ``systemd.bbclass`` file
:ref:`ref-classes-systemd` class. See the ``systemd.bbclass`` file
located in your :term:`Source Directory` section for more information.
Packaging
@ -886,14 +885,12 @@ take. The following list describes the process:
other logical components that should be split out. The :ref:`ref-tasks-package`
task ensures that files are split up and packaged correctly.
- *Running QA Checks*: The
:ref:`insane <ref-classes-insane>` class adds a
- *Running QA Checks*: The :ref:`ref-classes-insane` class adds a
step to the package generation process so that output quality
assurance checks are generated by the OpenEmbedded build system. This
step performs a range of checks to be sure the build's output is free
of common problems that show up during runtime. For information on
these checks, see the
:ref:`insane <ref-classes-insane>` class and
these checks, see the :ref:`ref-classes-insane` class and
the ":ref:`ref-manual/qa-checks:qa error and warning messages`"
chapter in the Yocto Project Reference Manual.
@ -934,8 +931,7 @@ take. The following list describes the process:
On the other hand, if the recipe produces packages that do not
contain anything specific to the target machine or architecture at
all (e.g. recipes that simply package script files or configuration
files), you should use the
:ref:`allarch <ref-classes-allarch>` class to
files), you should use the :ref:`ref-classes-allarch` class to
do this for you by adding this to your recipe::
inherit allarch
@ -1002,18 +998,16 @@ same functionality, you can use a virtual provider (i.e. ``virtual/*``)
as a placeholder for the actual provider. The actual provider is
determined at build-time.
A common scenario where a virtual provider is used would be for the
kernel recipe. Suppose you have three kernel recipes whose
:term:`PN` values map to ``kernel-big``,
``kernel-mid``, and ``kernel-small``. Furthermore, each of these recipes
in some way uses a :term:`PROVIDES`
statement that essentially identifies itself as being able to provide
``virtual/kernel``. Here is one way through the
:ref:`kernel <ref-classes-kernel>` class::
A common scenario where a virtual provider is used would be for the kernel
recipe. Suppose you have three kernel recipes whose :term:`PN` values map to
``kernel-big``, ``kernel-mid``, and ``kernel-small``. Furthermore, each of
these recipes in some way uses a :term:`PROVIDES` statement that essentially
identifies itself as being able to provide ``virtual/kernel``. Here is one way
through the :ref:`ref-classes-kernel` class::
PROVIDES += "virtual/kernel"
Any recipe that inherits the :ref:`kernel <ref-classes-kernel>` class is
Any recipe that inherits the :ref:`ref-classes-kernel` class is
going to utilize a :term:`PROVIDES` statement that identifies that recipe as
being able to provide the ``virtual/kernel`` item.
@ -1223,7 +1217,7 @@ Autotooled Package
Applications that use Autotools such as ``autoconf`` and ``automake``
require a recipe that has a source archive listed in :term:`SRC_URI` and
also inherit the :ref:`autotools <ref-classes-autotools>` class,
also inherit the :ref:`ref-classes-autotools` class,
which contains the definitions of all the steps needed to build an
Autotool-based application. The result of the build is automatically
packaged. And, if the application uses NLS for localization, packages
@ -1353,24 +1347,19 @@ could lead to compatibility problems with ABI in the future. However,
sometimes you have no choice.
The easiest solution is to create a recipe that uses the
:ref:`bin_package <ref-classes-bin-package>` class
and to be sure that you are using default locations for build artifacts.
In most cases, the :ref:`bin_package <ref-classes-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`
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
:ref:`bin_package <ref-classes-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`,
:term:`PN`,
:term:`S`, and
:term:`D` variables in the Yocto Project
Reference Manual's variable glossary.
:ref:`ref-classes-bin-package` class and to be sure that you are using default
locations for build artifacts. In most cases, the
:ref:`ref-classes-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` 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 :ref:`ref-classes-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`,
:term:`PN`, :term:`S`, and :term:`D` variables in the Yocto Project Reference
Manual's variable glossary.
.. note::
@ -1388,7 +1377,7 @@ Reference Manual's variable glossary.
section in the Yocto Project Overview and Concepts Manual for more
information.
If you cannot use the :ref:`bin_package <ref-classes-bin-package>` class, you need to be sure you are
If you cannot use the :ref:`ref-classes-bin-package` class, you need to be sure you are
doing the following:
- Create a recipe where the

16
documentation/dev-manual/packages.rst
View File

@ -643,8 +643,7 @@ Lighttpd, or Nginx), take the appropriate steps to do so.
From within the :term:`Build Directory` where you have built an image based on
your packaging choice (i.e. the :term:`PACKAGE_CLASSES` setting), simply start
the server. The following example assumes a :term:`Build Directory` of ``poky/build``
and a :term:`PACKAGE_CLASSES` setting of
":ref:`package_rpm <ref-classes-package_rpm>`"::
and a :term:`PACKAGE_CLASSES` setting of ":ref:`ref-classes-package_rpm`"::
$ cd poky/build/tmp/deploy/rpm
$ python3 -m http.server
@ -909,8 +908,8 @@ see the :yocto_wiki:`Ptest </Ptest>` wiki page.
.. note::
A recipe is "ptest-enabled" if it inherits the
:ref:`ptest <ref-classes-ptest>` class.
A recipe is "ptest-enabled" if it inherits the :ref:`ref-classes-ptest`
class.
Adding ptest to Your Build
--------------------------
@ -940,7 +939,7 @@ In order to enable a recipe to run installed ptests on target hardware,
you need to prepare the recipes that build the packages you want to
test. Here is what you have to do for each recipe:
- *Be sure the recipe inherits the* :ref:`ptest <ref-classes-ptest>` *class:*
- *Be sure the recipe inherits the* :ref:`ref-classes-ptest` *class:*
Include the following line in each recipe::
inherit ptest
@ -991,7 +990,7 @@ test. Here is what you have to do for each recipe:
special configurations prior to compiling the test code, you must
insert a ``do_configure_ptest`` function into the recipe.
- *Install the test suite:* The :ref:`ptest <ref-classes-ptest>` class
- *Install the test suite:* The :ref:`ref-classes-ptest` class
automatically copies the file ``run-ptest`` to the target and then runs make
``install-ptest`` to run the tests. If this is not enough, you need
to create a ``do_install_ptest`` function and make sure it gets
@ -1145,9 +1144,8 @@ Here are three key points in the previous example:
sub-module's license is unavailable, the sub-module's name appears in
the comments.
- The ``inherit npm`` statement causes the
:ref:`npm <ref-classes-npm>` class to package
up all the modules.
- The ``inherit npm`` statement causes the :ref:`ref-classes-npm` class to
package up all the modules.
You can run the following command to build the ``cute-files`` package::

4
documentation/dev-manual/quilt.rst
View File

@ -12,7 +12,7 @@ form of a patch all using Quilt.
.. note::
With regard to preserving changes to source files, if you clean a
recipe or have :ref:`rm_work <ref-classes-rm-work>` enabled, the
recipe or have :ref:`ref-classes-rm-work` enabled, the
:ref:`devtool workflow <sdk-manual/extensible:using \`\`devtool\`\` in your sdk workflow>`
as described in the Yocto Project Application Development and the
Extensible Software Development Kit (eSDK) manual is a safer
@ -61,7 +61,7 @@ Follow these general steps:
once you run the :ref:`ref-tasks-clean` or :ref:`ref-tasks-cleanall`
tasks using BitBake (i.e. ``bitbake -c clean package`` and
``bitbake -c cleanall package``). Modifications will also disappear if
you use the :ref:`rm_work <ref-classes-rm-work>` feature as described in
you use the :ref:`ref-classes-rm-work` feature as described in
the ":ref:`dev-manual/disk-space:conserving disk space during builds`"
section.

2
documentation/dev-manual/read-only-rootfs.rst
View File

@ -76,7 +76,7 @@ from running during root filesystem creation:
native tools, which run on the host system, to accomplish the same
tasks, or by alternatively running the processes under QEMU, which
has the ``qemu_run_binary`` function. For more information, see the
:ref:`qemu <ref-classes-qemu>` class.
:ref:`ref-classes-qemu` class.
Areas With Write Access
=======================

4
documentation/dev-manual/runtime-testing.rst
View File

@ -332,8 +332,8 @@ You can start the tests automatically or manually:
bitbake core-image-sato
- *Manually running tests:* To manually run the tests, first globally
inherit the :ref:`testimage <ref-classes-testimage>` class
by editing your ``local.conf`` file::
inherit the :ref:`ref-classes-testimage` class by editing your
``local.conf`` file::
INHERIT += "testimage"

4
documentation/dev-manual/sbom.rst
View File

@ -26,7 +26,7 @@ assessments, as all the components used in the Software Supply Chain are listed.
The OpenEmbedded build system doesn't generate such information by default.
To make this happen, you must inherit the
:ref:`create-spdx <ref-classes-create-spdx>` class from a configuration file::
:ref:`ref-classes-create-spdx` class from a configuration file::
INHERIT += "create-spdx"
@ -39,7 +39,7 @@ containing an index of JSON :term:`SPDX` files for individual recipes, together
with an ``IMAGE-MACHINE.spdx.tar.zst`` compressed archive containing all such
files.
The :ref:`create-spdx <ref-classes-create-spdx>` class offers options to include
The :ref:`ref-classes-create-spdx` class offers options to include
more information in the output :term:`SPDX` data, such as making the generated
files more human readable (:term:`SPDX_PRETTY`), adding compressed archives of
the files in the generated target packages (:term:`SPDX_ARCHIVE_PACKAGED`),

8
documentation/dev-manual/securing-images.rst
View File

@ -128,11 +128,9 @@ system to make your images more secure:
service type users). When you set up passwords for multiple images or
users, you should not duplicate passwords.
To set up passwords, use the
:ref:`extrausers <ref-classes-extrausers>`
class, which is the preferred method. For an example on how to set up
both root and user passwords, see the
":ref:`ref-classes-extrausers`" section.
To set up passwords, use the :ref:`ref-classes-extrausers` class, which
is the preferred method. For an example on how to set up both root and
user passwords, see the ":ref:`ref-classes-extrausers`" section.
.. note::

3
documentation/dev-manual/speeding-up-build.rst
View File

@ -61,8 +61,7 @@ Following are additional factors that can affect build speed:
file system on the principle that if there was a significant failure,
the :term:`Build Directory` contents could easily be rebuilt.
- Inheriting the
:ref:`rm_work <ref-classes-rm-work>` class:
- Inheriting the :ref:`ref-classes-rm-work` class:
Inheriting this class has shown to speed up builds due to
significantly lower amounts of data stored in the data cache as well
as on disk. Inheriting this class also makes cleanup of

3
documentation/dev-manual/upgrading-recipes.rst
View File

@ -113,8 +113,7 @@ The following steps describe how to set up the AUH utility:
``upgrade-helper/work/recipe/buildhistory-diff.txt`` file found in
your :term:`Build Directory`.
- If you want to enable testing through the
:ref:`testimage <ref-classes-testimage>`
- If you want to enable testing through the :ref:`ref-classes-testimage`
class, which is optional, you need to have the following set in
your ``conf/local.conf`` file::

10
documentation/dev-manual/vulnerabilities.rst
View File

@ -27,8 +27,9 @@ patches to fix them, see ":ref:`dev-manual/changes:submitting a change to the yo
Vulnerability check at build time
=================================
To enable a check for CVE security vulnerabilities using :ref:`cve-check <ref-classes-cve-check>` in the specific image
or target you are building, add the following setting to your configuration::
To enable a check for CVE security vulnerabilities using
:ref:`ref-classes-cve-check` in the specific image or target you are building,
add the following setting to your configuration::
INHERIT += "cve-check"
@ -100,7 +101,7 @@ It is also possible to check the CVE status of individual packages as follows::
Fixing CVE product name and version mappings
============================================
By default, :ref:`cve-check <ref-classes-cve-check>` uses the recipe name :term:`BPN` as CVE
By default, :ref:`ref-classes-cve-check` uses the recipe name :term:`BPN` as CVE
product name when querying the CVE database. If this mapping contains false positives, e.g.
some reported CVEs are not for the software component in question, or false negatives like
some CVEs are not found to impact the recipe when they should, then the problems can be
@ -167,8 +168,7 @@ the :term:`CVE_CHECK_SKIP_RECIPE` variable.
Implementation details
======================
Here's what the :ref:`cve-check <ref-classes-cve-check>` class does to
find unpatched CVE IDs.
Here's what the :ref:`ref-classes-cve-check` class does to find unpatched CVE IDs.
First the code goes through each patch file provided by a recipe. If a valid CVE ID
is found in the name of the file, the corresponding CVE is considered as patched.

3
documentation/dev-manual/wic.rst
View File

@ -59,8 +59,7 @@ this information is required to use Wic, you might find it interesting.
- Wic is a completely independent standalone utility that initially
provides easier-to-use and more flexible replacements for an existing
functionality in OE-Core's
:ref:`image-live <ref-classes-image-live>`
functionality in OE-Core's :ref:`ref-classes-image-live`
class. The difference between Wic and those examples is that with Wic
the functionality of those scripts is implemented by a
general-purpose partitioning language, which is based on Redhat

10
documentation/kernel-dev/common.rst
View File

@ -1685,12 +1685,10 @@ looks much like the one provided with the ``hello-mod`` template::
...
The important point to note here is the :term:`KERNEL_SRC` variable. The
:ref:`module <ref-classes-module>` class sets this variable and the
:term:`KERNEL_PATH` variable to
``${STAGING_KERNEL_DIR}`` with the necessary Linux kernel build
information to build modules. If your module ``Makefile`` uses a
different variable, you might want to override the
:ref:`ref-tasks-compile` step, or
:ref:`ref-classes-module` class sets this variable and the :term:`KERNEL_PATH`
variable to ``${STAGING_KERNEL_DIR}`` with the necessary Linux kernel build
information to build modules. If your module ``Makefile`` uses a different
variable, you might want to override the :ref:`ref-tasks-compile` step, or
create a patch to the ``Makefile`` to work with the more typical
:term:`KERNEL_SRC` or :term:`KERNEL_PATH` variables.

12
documentation/migration-guides/migration-1.3.rst
View File

@ -91,11 +91,11 @@ consistency.
nativesdk
~~~~~~~~~
The suffix ``nativesdk`` is now implemented as a prefix, which simplifies a
lot of the packaging code for :ref:`nativesdk <ref-classes-nativesdk>` recipes.
All custom :ref:`nativesdk <ref-classes-nativesdk>` recipes, which are
relocatable packages that are native to :term:`SDK_ARCH`, and any references
need to be updated to use ``nativesdk-*`` instead of ``*-nativesdk``.
The suffix ``nativesdk`` is now implemented as a prefix, which simplifies a lot
of the packaging code for :ref:`ref-classes-nativesdk` recipes. All custom
:ref:`ref-classes-nativesdk` recipes, which are relocatable packages that are
native to :term:`SDK_ARCH`, and any references need to be updated to use
``nativesdk-*`` instead of ``*-nativesdk``.
.. _migration-1.3-task-recipes:
@ -109,7 +109,7 @@ automatic upgrade path for most packages. However, you should update
references in your own recipes and configurations as they could be
removed in future releases. You should also rename any custom ``task-*``
recipes to ``packagegroup-*``, and change them to inherit
:ref:`packagegroup <ref-classes-packagegroup>` instead of ``task``, as well
:ref:`ref-classes-packagegroup` instead of ``task``, as well
as taking the opportunity to remove anything now handled by
:ref:`ref-classes-packagegroup`, such as providing ``-dev`` and ``-dbg``
packages, setting :term:`LIC_FILES_CHKSUM`, and so forth. See the

9
documentation/migration-guides/migration-1.5.rst
View File

@ -95,9 +95,8 @@ The following changes have been made to the package QA checks:
this file within :ref:`ref-tasks-install` if "make
install" is installing it.
- If you are using the :ref:`buildhistory <ref-classes-buildhistory>` class,
the check for the package
version going backwards is now controlled using a standard QA check.
- If you are using the :ref:`ref-classes-buildhistory` class, the check for the
package version going backwards is now controlled using a standard QA check.
Thus, if you have customized your :term:`ERROR_QA` or :term:`WARN_QA` values
and still wish to have this check performed, you should add
"version-going-backwards" to your value for one or the other
@ -131,7 +130,7 @@ The following directory changes exist:
it easier to delete :term:`TMPDIR` and preserve the build history.
Additionally, data for produced SDKs is now split by :term:`IMAGE_NAME`.
- When :ref:`buildhistory <ref-classes-buildhistory>` is enabled, its output
- When :ref:`ref-classes-buildhistory` is enabled, its output
is now written under the :term:`Build Directory` rather than :term:`TMPDIR`.
Doing so makes it easier to delete :term:`TMPDIR` and preserve the build
history. Additionally, data for produced SDKs is now split by :term:`IMAGE_NAME`.
@ -223,7 +222,7 @@ Task Recipes
The previously deprecated ``task.bbclass`` has now been dropped. For
recipes that previously inherited from this class, you should rename
them from ``task-*`` to ``packagegroup-*`` and inherit
:ref:`packagegroup <ref-classes-packagegroup>` instead.
:ref:`ref-classes-packagegroup` instead.
For more information, see the ":ref:`ref-classes-packagegroup`" section.

13
documentation/migration-guides/migration-1.6.rst
View File

@ -11,9 +11,8 @@ Project 1.6 Release (codename "daisy") from the prior release.
``archiver`` Class
------------------
The :ref:`archiver <ref-classes-archiver>` class has been rewritten
and its configuration has been simplified. For more details on the
source archiver, see the
The :ref:`ref-classes-archiver` class has been rewritten and its configuration
has been simplified. For more details on the source archiver, see the
":ref:`dev-manual/licenses:maintaining open source license compliance during your product's lifecycle`"
section in the Yocto Project Development Tasks Manual.
@ -224,7 +223,7 @@ Package Tests (ptest) are built but not installed by default. For
information on using Package Tests, see the
":ref:`dev-manual/packages:testing packages with ptest`" section in the
Yocto Project Development Tasks Manual. For information on the
:ref:`ptest <ref-classes-ptest>` class, see the ":ref:`ref-classes-ptest`"
:ref:`ref-classes-ptest` class, see the ":ref:`ref-classes-ptest`"
section.
.. _migration-1.6-build-changes:
@ -234,13 +233,13 @@ Build Changes
Separate build and source directories have been enabled by default for
selected recipes where it is known to work and for all
recipes that inherit the :ref:`cmake <ref-classes-cmake>` class. In
future releases the :ref:`autotools <ref-classes-autotools>` class
recipes that inherit the :ref:`ref-classes-cmake` class. In
future releases the :ref:`ref-classes-autotools` class
will enable a separate :term:`Build Directory` by default as well. Recipes
building Autotools-based software that fails to build with a separate
:term:`Build Directory` should be changed to inherit from the
:ref:`autotools-brokensep <ref-classes-autotools>` class instead of
the :ref:`autotools <ref-classes-autotools>` or ``autotools_stage`` classes.
the :ref:`ref-classes-autotools` or ``autotools_stage`` classes.
.. _migration-1.6-building-qemu-native:

13
documentation/migration-guides/migration-1.7.rst
View File

@ -41,13 +41,11 @@ section for more information.
Autotools Class Changes
-----------------------
The following :ref:`autotools <ref-classes-autotools>` class changes
occurred:
The following :ref:`ref-classes-autotools` class changes occurred:
- *A separate :term:`Build Directory` is now used by default:* The
:ref:`autotools <ref-classes-autotools>` class has been
changed to use a directory for building
(:term:`B`), which is separate from the source directory
:ref:`ref-classes-autotools` class has been changed to use a directory for
building (:term:`B`), which is separate from the source directory
(:term:`S`). This is commonly referred to as ``B != S``, or
an out-of-tree build.
@ -56,9 +54,8 @@ occurred:
However, if the software is not capable of being built in this
manner, you will need to either patch the software so that it can
build separately, or you will need to change the recipe to inherit
the :ref:`autotools-brokensep <ref-classes-autotools>` class
instead of the :ref:`autotools <ref-classes-autotools>`
or ``autotools_stage`` classes.
the :ref:`autotools-brokensep <ref-classes-autotools>` class instead
of the :ref:`ref-classes-autotools` or ``autotools_stage`` classes.
- The ``--foreign`` option is no longer passed to ``automake`` when
running ``autoconf``: This option tells ``automake`` that a

28
documentation/migration-guides/migration-1.8.rst
View File

@ -70,17 +70,16 @@ the following::
Kernel Build Changes
--------------------
The kernel build process was changed to place the source in a common
shared work area and to place build artifacts separately in the source
code tree. In theory, migration paths have been provided for most common
usages in kernel recipes but this might not work in all cases. In
particular, users need to ensure that ``${S}`` (source files) and
``${B}`` (build artifacts) are used correctly in functions such as
:ref:`ref-tasks-configure` and
:ref:`ref-tasks-install`. For kernel recipes that do not
inherit from :ref:`kernel-yocto <ref-classes-kernel-yocto>` or include ``linux-yocto.inc``, you might
wish to refer to the ``linux.inc`` file in the ``meta-oe`` layer for the
kinds of changes you need to make. For reference, here is the
The kernel build process was changed to place the source in a common shared work
area and to place build artifacts separately in the source code tree. In theory,
migration paths have been provided for most common usages in kernel recipes but
this might not work in all cases. In particular, users need to ensure that
``${S}`` (source files) and ``${B}`` (build artifacts) are used correctly in
functions such as :ref:`ref-tasks-configure` and :ref:`ref-tasks-install`. For
kernel recipes that do not inherit from :ref:`ref-classes-kernel-yocto` or
include ``linux-yocto.inc``, you might wish to refer to the ``linux.inc`` file
in the ``meta-oe`` layer for the kinds of changes you need to make. For reference,
here is the
:oe_git:`commit </meta-openembedded/commit/meta-oe/recipes-kernel/linux/linux.inc?id=fc7132ede27ac67669448d3d2845ce7d46c6a1ee>`
where the ``linux.inc`` file in ``meta-oe`` was updated.
@ -123,10 +122,9 @@ need to take corrective steps.
Rebuild Improvements
--------------------
Changes have been made to the :ref:`base <ref-classes-base>`,
:ref:`autotools <ref-classes-autotools>`, and
:ref:`cmake <ref-classes-cmake>` classes to clean out generated files
when the :ref:`ref-tasks-configure` task needs to be
Changes have been made to the :ref:`ref-classes-base`,
:ref:`ref-classes-autotools`, and :ref:`ref-classes-cmake` classes to clean out
generated files when the :ref:`ref-tasks-configure` task needs to be
re-executed.
One of the improvements is to attempt to run "make clean" during the

2
documentation/migration-guides/migration-2.0.rst
View File

@ -216,7 +216,7 @@ modifications synchronized, it is not always obvious to developers how
to manipulate the Metadata as compared to the source.
Metadata processing has now been removed from the
:ref:`kernel-yocto <ref-classes-kernel-yocto>` class and the external
:ref:`ref-classes-kernel-yocto` class and the external
Metadata repository ``yocto-kernel-cache``, which has always been used
to seed the ``linux-yocto`` "meta" branch. This separate ``linux-yocto``
cache repository is now the primary location for this data. Due to this

32
documentation/migration-guides/migration-2.1.rst
View File

@ -66,7 +66,7 @@ Makefile Environment Changes
:term:`EXTRA_OEMAKE` now defaults to "" instead of
"-e MAKEFLAGS=". Setting :term:`EXTRA_OEMAKE` to "-e MAKEFLAGS=" by default
was a historical accident that has required many classes (e.g.
:ref:`autotools <ref-classes-autotools>`, ``module``) and recipes to override this default in order
:ref:`ref-classes-autotools`, ``module``) and recipes to override this default in order
to work with sensible build systems. When upgrading to the release, you
must edit any recipe that relies upon this old default by either setting
:term:`EXTRA_OEMAKE` back to "-e MAKEFLAGS=" or by explicitly setting any
@ -100,7 +100,7 @@ breaking FHS.
``ac_cv_sizeof_off_t`` is No Longer Cached in Site Files
--------------------------------------------------------
For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
For recipes inheriting the :ref:`ref-classes-autotools`
class, ``ac_cv_sizeof_off_t`` is no longer cached in the site files for
``autoconf``. The reason for this change is because the
``ac_cv_sizeof_off_t`` value is not necessarily static per architecture
@ -108,12 +108,12 @@ as was previously assumed. Rather, the value changes based on whether
large file support is enabled. For most software that uses ``autoconf``,
this change should not be a problem. However, if you have a recipe that
bypasses the standard :ref:`ref-tasks-configure` task
from the :ref:`autotools <ref-classes-autotools>` class and the software the recipe is building
from the :ref:`ref-classes-autotools` class and the software the recipe is building
uses a very old version of ``autoconf``, the recipe might be incapable
of determining the correct size of ``off_t`` during :ref:`ref-tasks-configure`.
The best course of action is to patch the software as necessary to allow
the default implementation from the :ref:`autotools <ref-classes-autotools>` class to work such
the default implementation from the :ref:`ref-classes-autotools` class to work such
that ``autoreconf`` succeeds and produces a working configure script,
and to remove the overridden :ref:`ref-tasks-configure` task such that the default
implementation does get used.
@ -138,9 +138,8 @@ should make edits so that those tasks are after the
after :ref:`ref-tasks-rootfs` so that your added tasks run at the correct
time.
A minor part of this restructuring is that the post-processing
definitions and functions have been moved from the
:ref:`image <ref-classes-image>` class to the
A minor part of this restructuring is that the post-processing definitions and
functions have been moved from the :ref:`ref-classes-image` class to the
:ref:`rootfs-postcommands <ref-classes-rootfs*>` class. Functionally,
however, they remain unchanged.
@ -191,18 +190,17 @@ Class Changes
The following classes have changed:
- ``autotools_stage``: Removed because the
:ref:`autotools <ref-classes-autotools>` class now provides its
:ref:`ref-classes-autotools` class now provides its
functionality. Recipes that inherited from ``autotools_stage`` should
now inherit from :ref:`autotools <ref-classes-autotools>` instead.
now inherit from :ref:`ref-classes-autotools` instead.
- ``boot-directdisk``: Merged into the ``image-vm`` class. The
``boot-directdisk`` class was rarely directly used. Consequently,
this change should not cause any issues.
- ``bootimg``: Merged into the
:ref:`image-live <ref-classes-image-live>` class. The ``bootimg``
class was rarely directly used. Consequently, this change should not
cause any issues.
- ``bootimg``: Merged into the :ref:`ref-classes-image-live` class. The
``bootimg`` class was rarely directly used. Consequently, this change should
not cause any issues.
- ``packageinfo``: Removed due to its limited use by the Hob UI, which
has itself been removed.
@ -257,14 +255,14 @@ The following changes have been made for the Poky distribution:
not need to change anything unless you are relying on this naming
elsewhere.
- The :ref:`uninative <ref-classes-uninative>` class is now enabled
- The :ref:`ref-classes-uninative` class is now enabled
by default in Poky. This class attempts to isolate the build system
from the host distribution's C library and makes re-use of native
shared state artifacts across different host distributions practical.
With this class enabled, a tarball containing a pre-built C library
is downloaded at the start of the build.
The :ref:`uninative <ref-classes-uninative>` class is enabled through the
The :ref:`ref-classes-uninative` class is enabled through the
``meta/conf/distro/include/yocto-uninative.inc`` file, which for
those not using the Poky distribution, can include to easily enable
the same functionality.
@ -403,9 +401,9 @@ These additional changes exist:
as these directories are automatically found and added.
- Inaccurate disk and CPU percentage data has been dropped from
:ref:`buildstats <ref-classes-buildstats>` output. This data has been replaced with
:ref:`ref-classes-buildstats` output. This data has been replaced with
``getrusage()`` data and corrected IO statistics. You will probably
need to update any custom code that reads the :ref:`buildstats <ref-classes-buildstats>` data.
need to update any custom code that reads the :ref:`ref-classes-buildstats` data.
- The ``meta/conf/distro/include/package_regex.inc`` is now deprecated.
The contents of this file have been moved to individual recipes.

22
documentation/migration-guides/migration-2.3.rst
View File

@ -52,7 +52,7 @@ Consider the following:
post-installation script that is installed by a function added to
:term:`SYSROOT_PREPROCESS_FUNCS`.
For an example, see the :ref:`pixbufcache <ref-classes-pixbufcache>` class in ``meta/classes/`` in
For an example, see the :ref:`ref-classes-pixbufcache` class in ``meta/classes/`` in
the :ref:`overview-manual/development-environment:yocto project source repositories`.
.. note::
@ -402,7 +402,7 @@ The following QA checks have changed:
warning, you need to address missing runtime dependencies.
For additional information, see the
:ref:`insane <ref-classes-insane>` class and the
:ref:`ref-classes-insane` class and the
":ref:`ref-manual/qa-checks:errors and warnings`" section.
.. _migration-2.3-miscellaneous-changes:
@ -446,7 +446,7 @@ The following miscellaneous changes have occurred:
RSA keys only, and with recent versions of OpenSSH, which deprecates
DSA host keys.
- The :ref:`buildhistory <ref-classes-buildhistory>` class now
- The :ref:`ref-classes-buildhistory` class now
correctly uses tabs as separators between all columns in
``installed-package-sizes.txt`` in order to aid import into other
tools.
@ -484,26 +484,24 @@ The following miscellaneous changes have occurred:
If you need to preserve these ``.la`` files (e.g. in a custom
distribution), you must change :term:`INHERIT_DISTRO` such that
":ref:`remove-libtool <ref-classes-remove-libtool>`" is not included
":ref:`ref-classes-remove-libtool`" is not included
in the value.
- Extensible SDKs built for GCC 5+ now refuse to install on a
distribution where the host GCC version is 4.8 or 4.9. This change
resulted from the fact that the installation is known to fail due to
the way the ``uninative`` shared state (sstate) package is built. See
the :ref:`uninative <ref-classes-uninative>` class for additional
information.
the :ref:`ref-classes-uninative` class for additional information.
- All :ref:`native <ref-classes-native>` and
:ref:`nativesdk <ref-classes-nativesdk>` recipes now use a separate
:term:`DISTRO_FEATURES` value instead of sharing the value used by
recipes for the target, in order to avoid unnecessary rebuilds.
- All :ref:`ref-classes-native` and :ref:`ref-classes-nativesdk` recipes now
use a separate :term:`DISTRO_FEATURES` value instead of sharing the value
used by recipes for the target, in order to avoid unnecessary rebuilds.
The :term:`DISTRO_FEATURES` for :ref:`native <ref-classes-native>` recipes
The :term:`DISTRO_FEATURES` for :ref:`ref-classes-native` recipes
is :term:`DISTRO_FEATURES_NATIVE` added to an intersection of
:term:`DISTRO_FEATURES` and :term:`DISTRO_FEATURES_FILTER_NATIVE`.
For :ref:`nativesdk <ref-classes-nativesdk>` recipes, the corresponding
For :ref:`ref-classes-nativesdk` recipes, the corresponding
variables are :term:`DISTRO_FEATURES_NATIVESDK` and
:term:`DISTRO_FEATURES_FILTER_NATIVESDK`.

12
documentation/migration-guides/migration-2.4.rst
View File

@ -197,12 +197,10 @@ Kernel Device Tree Move
-----------------------
Kernel Device Tree support is now easier to enable in a kernel recipe.
The Device Tree code has moved to a
:ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class.
The Device Tree code has moved to a :ref:`ref-classes-kernel-devicetree` class.
Functionality is automatically enabled for any recipe that inherits the
:ref:`kernel <ref-classes-kernel>` class and sets the
:term:`KERNEL_DEVICETREE` variable. The
previous mechanism for doing this,
:ref:`kernel <ref-classes-kernel>` class and sets the :term:`KERNEL_DEVICETREE`
variable. The previous mechanism for doing this,
``meta/recipes-kernel/linux/linux-dtb.inc``, is still available to avoid
breakage, but triggers a deprecation warning. Future releases of the
Yocto Project will remove ``meta/recipes-kernel/linux/linux-dtb.inc``.
@ -271,11 +269,11 @@ The following are additional changes:
from ``meta-poky`` to OE-Core (i.e. from
``meta-poky/conf/distro/include`` to ``meta/conf/distro/include``).
- The :ref:`buildhistory <ref-classes-buildhistory>` class now makes
- The :ref:`ref-classes-buildhistory` class now makes
a single commit per build rather than one commit per subdirectory in
the repository. This behavior assumes the commits are enabled with
:term:`BUILDHISTORY_COMMIT` = "1", which
is typical. Previously, the :ref:`buildhistory <ref-classes-buildhistory>` class made one commit
is typical. Previously, the :ref:`ref-classes-buildhistory` class made one commit
per subdirectory in the repository in order to make it easier to see
the changes for a particular subdirectory. To view a particular
change, specify that subdirectory as the last parameter on the

10
documentation/migration-guides/migration-2.5.rst
View File

@ -139,7 +139,7 @@ The following are BitBake changes:
- Several explicit "run this task for all recipes in the dependency
tree" tasks have been removed (e.g. ``fetchall``, ``checkuriall``,
and the ``*all`` tasks provided by the ``distrodata`` and
:ref:`archiver <ref-classes-archiver>` classes). There is a BitBake option to complete this for
:ref:`ref-classes-archiver` classes). There is a BitBake option to complete this for
any arbitrary task. For example::
bitbake <target> -c fetchall
@ -189,7 +189,7 @@ Miscellaneous Changes
The following are additional changes:
- The :ref:`kernel <ref-classes-kernel>` class supports building packages for multiple kernels.
- The :ref:`ref-classes-kernel` class supports building packages for multiple kernels.
If your kernel recipe or ``.bbappend`` file mentions packaging at
all, you should replace references to the kernel in package names
with ``${KERNEL_PACKAGE_NAME}``. For example, if you disable
@ -197,7 +197,7 @@ The following are additional changes:
``RDEPENDS_kernel-base = ""`` you can avoid warnings using
``RDEPENDS_${KERNEL_PACKAGE_NAME}-base = ""`` instead.
- The :ref:`buildhistory <ref-classes-buildhistory>` class commits changes to the repository by
- The :ref:`ref-classes-buildhistory` class commits changes to the repository by
default so you no longer need to set ``BUILDHISTORY_COMMIT = "1"``.
If you want to disable commits you need to set
``BUILDHISTORY_COMMIT = "0"`` in your configuration.
@ -209,12 +209,12 @@ The following are additional changes:
maintains a full-featured BSP in the ``meta-ti`` layer. This rename
avoids the previous name clash that existed between the two BSPs.
- The :ref:`update-alternatives <ref-classes-update-alternatives>` class no longer works with SysV ``init``
- The :ref:`ref-classes-update-alternatives` class no longer works with SysV ``init``
scripts because this usage has been problematic. Also, the
``sysklogd`` recipe no longer uses ``update-alternatives`` because it
is incompatible with other implementations.
- By default, the :ref:`cmake <ref-classes-cmake>` class uses
- By default, the :ref:`ref-classes-cmake` class uses
``ninja`` instead of ``make`` for building. This improves build
performance. If a recipe is broken with ``ninja``, then the recipe
can set ``OECMAKE_GENERATOR = "Unix Makefiles"`` to change back to

18
documentation/migration-guides/migration-2.6.rst
View File

@ -128,10 +128,9 @@ missing from :term:`DEPENDS`).
.. note::
This change affects classes beyond just the two mentioned (i.e.
``distutils`` and ``distutils3``). Any recipe that inherits ``distutils*``
classes are affected. For example, the ``setuptools`` and
:ref:`setuptools3 <ref-classes-setuptools3>`
This change affects classes beyond just the two mentioned (i.e. ``distutils``
and ``distutils3``). Any recipe that inherits ``distutils*`` classes are
affected. For example, the ``setuptools`` and :ref:`ref-classes-setuptools3`
recipes are affected since they inherit the ``distutils*`` classes.
Fetching these types of dependencies that are not provided in the
@ -315,12 +314,11 @@ This section provides information about automatic testing changes:
exists and has been replaced by the
:term:`TESTIMAGE_AUTO` variable.
- Inheriting the :ref:`testimage <ref-classes-testimage>` and
:ref:`testsdk <ref-classes-testsdk>` classes: best practices now dictate
that you use the :term:`IMAGE_CLASSES` variable rather than the
:term:`INHERIT` variable when you inherit the
:ref:`testimage <ref-classes-testimage>` and
:ref:`testsdk <ref-classes-testsdk>` classes used for automatic testing.
- Inheriting the :ref:`ref-classes-testimage` and :ref:`ref-classes-testsdk`
classes: best practices now dictate that you use the :term:`IMAGE_CLASSES`
variable rather than the :term:`INHERIT` variable when you inherit the
:ref:`ref-classes-testimage` and :ref:`ref-classes-testsdk` classes used
for automatic testing.
.. _migration-2.6-openssl-changes:

3
documentation/migration-guides/migration-2.7.rst
View File

@ -174,8 +174,7 @@ The following miscellaneous changes occurred:
- ``base/pixbufcache``: Obsolete ``sstatecompletions`` code has been
removed.
- :ref:`native <ref-classes-native>` class:
:term:`RDEPENDS` handling has been enabled.
- :ref:`ref-classes-native` class: :term:`RDEPENDS` handling has been enabled.
- ``inetutils``: This recipe has rsh disabled.

6
documentation/migration-guides/migration-3.0.rst
View File

@ -49,7 +49,7 @@ The following recipes have been removed.
- ``core-image-lsb-sdk``: Part of removed LSB support.
- ``cve-check-tool``: Functionally replaced by the ``cve-update-db``
recipe and :ref:`cve-check <ref-classes-cve-check>` class.
recipe and :ref:`ref-classes-cve-check` class.
- ``eglinfo``: No longer maintained. ``eglinfo`` from ``mesa-demos`` is
an adequate and maintained alternative.
@ -144,7 +144,7 @@ CVE Checking
------------
``cve-check-tool`` has been functionally replaced by a new
``cve-update-db`` recipe and functionality built into the :ref:`cve-check <ref-classes-cve-check>`
``cve-update-db`` recipe and functionality built into the :ref:`ref-classes-cve-check`
class. The result uses NVD JSON data feeds rather than the deprecated
XML feeds that ``cve-check-tool`` was using, supports CVSSv3 scoring,
and makes other improvements.
@ -287,7 +287,7 @@ The following miscellaneous changes have occurred.
:term:`NATIVELSBSTRING` to use all lowercase
characters even if it does not contain a version number. This change
is necessary only if you are not using
:ref:`uninative <ref-classes-uninative>` and :term:`SANITY_TESTED_DISTROS`.
:ref:`ref-classes-uninative` and :term:`SANITY_TESTED_DISTROS`.
- In the ``base-files`` recipe, writing the hostname into
``/etc/hosts`` and ``/etc/hostname`` is now done within the main

6
documentation/migration-guides/migration-3.1.rst
View File

@ -127,7 +127,7 @@ renamed to ``features_check``; the ``distro_features_check`` class still
exists but generates a warning and redirects to the new class. In
preparation for a future removal of the old class it is recommended that
you update recipes currently inheriting ``distro_features_check`` to
inherit :ref:`features_check <ref-classes-features_check>` instead.
inherit :ref:`ref-classes-features_check` instead.
.. _migration-3.1-removed-classes:
@ -240,10 +240,10 @@ Warnings will now be shown at :ref:`ref-tasks-package_qa` time in the following
circumstances:
- A recipe installs ``.desktop`` files containing ``MimeType`` keys but
does not inherit the new :ref:`mime-xdg <ref-classes-mime-xdg>` class
does not inherit the new :ref:`ref-classes-mime-xdg` class
- A recipe installs ``.xml`` files into ``${datadir}/mime/packages``
but does not inherit the :ref:`mime <ref-classes-mime>` class
but does not inherit the :ref:`ref-classes-mime` class
.. _migration-3.1-x86-live-wic:

33
documentation/migration-guides/migration-3.2.rst
View File

@ -177,13 +177,23 @@ errors:
In addition, the following new checks were added and default to triggering an error:
- :ref:`shebang-size <qa-check-shebang-size>`: Check for shebang (#!) lines longer than 128 characters, which can give an error at runtime depending on the operating system.
- :ref:`shebang-size <qa-check-shebang-size>`: Check for shebang (#!) lines
longer than 128 characters, which can give an error at runtime depending on
the operating system.
- :ref:`unhandled-features-check <qa-check-unhandled-features-check>`: Check if any of the variables supported by the :ref:`features_check <ref-classes-features_check>` class is set while not inheriting the class itself.
- :ref:`unhandled-features-check <qa-check-unhandled-features-check>`: Check
if any of the variables supported by the :ref:`ref-classes-features_check`
class is set while not inheriting the class itself.
- :ref:`missing-update-alternatives <qa-check-missing-update-alternatives>`: Check if the recipe sets the :term:`ALTERNATIVE` variable for any of its packages, and does not inherit the :ref:`update-alternatives <ref-classes-update-alternatives>` class.
- :ref:`missing-update-alternatives <qa-check-missing-update-alternatives>`:
Check if the recipe sets the :term:`ALTERNATIVE` variable for any of its
packages, and does not inherit the :ref:`ref-classes-update-alternatives`
class.
- A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B` will now trigger a warning so that they can be removed and path comparisons can be more reliable --- remove any instances of these in your recipes if the warning is displayed.
- A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B`
will now trigger a warning so that they can be removed and path comparisons
can be more reliable --- remove any instances of these in your recipes if the
warning is displayed.
.. _migration-3.2-src-uri-file-globbing:
@ -209,9 +219,18 @@ files into a subdirectory and reference that instead.
deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
----------------------------------------------------------
:ref:`ref-tasks-deploy` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
:ref:`ref-tasks-deploy` as implemented in the :ref:`ref-classes-deploy` class
now cleans up ${:term:`DEPLOYDIR`} before running, just as
:ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces
the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from
previous runs, possibly even with different config, in case of incremental
builds.
Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with :ref:`ref-tasks-deploy` are unlikely to be affected by this unless they add ``prefuncs`` to :ref:`ref-tasks-deploy` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
Most recipes and classes that inherit the :ref:`ref-classes-deploy` class or
interact with :ref:`ref-tasks-deploy` are unlikely to be affected by this
unless they add ``prefuncs`` to :ref:`ref-tasks-deploy` *which also* put files
into ``${DEPLOYDIR}`` --- these should be refactored to use
``do_deploy_prepend`` instead.
.. _migration-3.2-nativesdk-sdk-provides-dummy:
@ -219,7 +238,7 @@ Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` cla
Custom SDK / SDK-style recipes need to include ``nativesdk-sdk-provides-dummy``
-------------------------------------------------------------------------------
All :ref:`nativesdk <ref-classes-nativesdk>` packages require ``/bin/sh`` due
All :ref:`ref-classes-nativesdk` packages require ``/bin/sh`` due
to their postinstall scriptlets, thus this package has to be dummy-provided
within the SDK and ``nativesdk-sdk-provides-dummy`` now does this. If you have
a custom SDK recipe (or your own SDK-style recipe similar to e.g.

17
documentation/migration-guides/migration-3.3.rst
View File

@ -63,13 +63,13 @@ need to update those.
New ``python3targetconfig`` class
---------------------------------
A new :ref:`python3targetconfig <ref-classes-python3targetconfig>` class has
A new :ref:`ref-classes-python3targetconfig` class has
been created for situations where you would previously have inherited the
:ref:`python3native <ref-classes-python3native>` class but need access to
:ref:`ref-classes-python3native` class but need access to
target configuration data (such as correct installation directories). Recipes
where this situation applies should be changed to inherit
:ref:`python3targetconfig <ref-classes-python3targetconfig>` instead of
:ref:`python3native <ref-classes-python3native>`. This also adds a dependency
:ref:`ref-classes-python3targetconfig` instead of
:ref:`ref-classes-python3native`. This also adds a dependency
on target ``python3``, so it should only be used where appropriate in order to
avoid unnecessarily lengthening builds.
@ -99,11 +99,10 @@ variable so that recipes can specify it explicitly, for example::
S = "${WORKDIR}/git"
DISTUTILS_SETUP_PATH = "${S}/python/pythonmodule"
Recipes that inherit from ``distutils3`` (or
:ref:`setuptools3 <ref-classes-setuptools3>` which itself inherits
``distutils3``) that also set :term:`S` to point to a Python module within a
subdirectory in the aforementioned manner should be changed to set
``DISTUTILS_SETUP_PATH`` instead.
Recipes that inherit from ``distutils3`` (or :ref:`ref-classes-setuptools3`
which itself inherits ``distutils3``) that also set :term:`S` to point to a
Python module within a subdirectory in the aforementioned manner should be
changed to set ``DISTUTILS_SETUP_PATH`` instead.
.. _migration-3.3-bitbake:

4
documentation/migration-guides/migration-3.4.rst
View File

@ -126,7 +126,7 @@ Removed classes
- ``image-mklibs``: not actively tested and upstream mklibs still
requires Python 2
- ``meta``: no longer useful. Recipes that need to skip installing
packages should inherit :ref:`nopackages <ref-classes-nopackages>` instead.
packages should inherit :ref:`ref-classes-nopackages` instead.
Prelinking disabled by default
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -259,7 +259,7 @@ Miscellaneous
instead.
- The obsolete ``oe_machinstall`` function previously provided in the
:ref:`utils <ref-classes-utils>` class has been removed. For
:ref:`ref-classes-utils` class has been removed. For
machine-specific installation it is recommended that you use the
built-in override support in the fetcher or overrides in general
instead.

21
documentation/migration-guides/migration-4.0.rst
View File

@ -119,7 +119,7 @@ License changes
- The ``AVAILABLE_LICENSES`` variable has been removed. This variable was a performance
liability and is highly dependent on which layers are added to the configuration,
which can cause signature issues for users. In addition the ``available_licenses()``
function has been removed from the :ref:`license <ref-classes-license>` class as
function has been removed from the :ref:`ref-classes-license` class as
it is no longer needed.
Removed recipes
@ -143,15 +143,14 @@ Python changes
- The Python package build process is now based on `wheels <https://pythonwheels.com/>`__.
Here are the new Python packaging classes that should be used:
:ref:`python_flit_core <ref-classes-python_flit_core>`,
:ref:`python_setuptools_build_meta <ref-classes-python_setuptools_build_meta>`
and :ref:`python_poetry_core <ref-classes-python_poetry_core>`.
:ref:`ref-classes-python_flit_core`, :ref:`ref-classes-python_setuptools_build_meta`
and :ref:`ref-classes-python_poetry_core`.
- The :ref:`setuptools3 <ref-classes-setuptools3>` class :ref:`ref-tasks-install` task now
- The :ref:`ref-classes-setuptools3` class :ref:`ref-tasks-install` task now
installs the ``wheel`` binary archive. In current versions of ``setuptools`` the
legacy ``setup.py install`` method is deprecated. If the ``setup.py`` cannot be used
with wheels, for example it creates files outside of the Python module or standard
entry points, then :ref:`setuptools3_legacy <ref-classes-setuptools3_legacy>` should
entry points, then :ref:`ref-classes-setuptools3_legacy` should
be used instead.
Prelink removed
@ -173,7 +172,7 @@ Reproducible as standard
Reproducibility is now considered as standard functionality, thus the
``reproducible`` class has been removed and its previous contents merged into the
:ref:`base <ref-classes-base>` class. If you have references in your configuration to
:ref:`ref-classes-base` class. If you have references in your configuration to
``reproducible`` in :term:`INHERIT`, :term:`USER_CLASSES` etc. then they should be
removed.
@ -215,15 +214,15 @@ Miscellaneous changes
~~~~~~~~~~~~~~~~~~~~~
- ``blacklist.bbclass`` is removed and the functionality moved to the
:ref:`base <ref-classes-base>` class with a more descriptive
:ref:`ref-classes-base` class with a more descriptive
``varflag`` variable named :term:`SKIP_RECIPE` which will use the `bb.parse.SkipRecipe()`
function. The usage remains the same, for example::
SKIP_RECIPE[my-recipe] = "Reason for skipping recipe"
- :ref:`allarch <ref-classes-allarch>` packagegroups can no longer depend on packages
- :ref:`ref-classes-allarch` packagegroups can no longer depend on packages
which use :term:`PKG` renaming such as :ref:`ref-classes-debian`. Such packagegroups
recipes should be changed to avoid inheriting :ref:`allarch <ref-classes-allarch>`.
recipes should be changed to avoid inheriting :ref:`ref-classes-allarch`.
- The ``lnr`` script has been removed. ``lnr`` implemented the same behaviour as `ln --relative --symbolic`,
since at the time of creation `--relative` was only available in coreutils 8.16
@ -232,7 +231,7 @@ Miscellaneous changes
any calls to ``lnr`` in your recipes or classes, they should be replaced with
`ln --relative --symbolic` or `ln -rs` if you prefer the short version.
- The ``package_qa_handle_error()`` function formerly in the :ref:`insane <ref-classes-insane>`
- The ``package_qa_handle_error()`` function formerly in the :ref:`ref-classes-insane`
class has been moved and renamed - if you have any references in your own custom
classes they should be changed to ``oe.qa.handle_error()``.

10
documentation/migration-guides/migration-4.1.rst
View File

@ -92,7 +92,7 @@ now cause an error::
INHERIT += "testimage"
Since :ref:`testimage <ref-classes-testimage>` is a class intended solely to
Since :ref:`ref-classes-testimage` is a class intended solely to
affect image recipes, this would be correctly specified as::
IMAGE_CLASSES += "testimage"
@ -154,16 +154,16 @@ Miscellaneous changes
you can set :term:`WATCHDOG_TIMEOUT` to the desired timeout in seconds. Note
that the same :term:`WATCHDOG_TIMEOUT` variable also specifies the timeout used
for the ``watchdog`` tool (if that is being built).
- The :ref:`image-buildinfo <ref-classes-image-buildinfo>` class now writes to
- The :ref:`ref-classes-image-buildinfo` class now writes to
``${sysconfdir}/buildinfo`` instead of ``${sysconfdir}/build`` by default (i.e.
the default value of :term:`IMAGE_BUILDINFO_FILE` has been changed). If you have
code that reads this from images at build or runtime you will need to update it
or specify your own value for :term:`IMAGE_BUILDINFO_FILE`.
- In the :ref:`archiver <ref-classes-archiver>` class, the default
- In the :ref:`ref-classes-archiver` class, the default
``ARCHIVER_OUTDIR`` value no longer includes the :term:`MACHINE` value in order
to avoid the archive task running multiple times in a multiconfig setup. If you
have custom code that does something with the files archived by the
:ref:`archiver <ref-classes-archiver>` class then you may need to adjust it to
:ref:`ref-classes-archiver` class then you may need to adjust it to
the new structure.
- If you are not using `systemd` then udev is now configured to use labels
(``LABEL`` or ``PARTLABEL``) to set the mount point for the device. For example::
@ -194,7 +194,7 @@ Miscellaneous changes
:term:`PACKAGECONFIG`. If you are customising this file you will need to
update your customisations.
- With the introduction of picobuild in
:ref:`python_pep517 <ref-classes-python_pep517>`, The ``PEP517_BUILD_API``
:ref:`ref-classes-python_pep517`, The ``PEP517_BUILD_API``
variable is no longer supported. If you have any references to this variable
you should remove them.

14
documentation/migration-guides/migration-general.rst
View File

@ -76,24 +76,24 @@ any new Yocto Project release.
- *Checking Image / SDK Changes*:
The :ref:`buildhistory <ref-classes-buildhistory>` class can be used
The :ref:`ref-classes-buildhistory` class can be used
if you wish to check the impact of changes to images / SDKs across
the migration (e.g. added/removed packages, added/removed files, size
changes etc.). To do this, follow these steps:
#. Enable :ref:`buildhistory <ref-classes-buildhistory>` before the migration
#. Enable :ref:`ref-classes-buildhistory` before the migration
#. Run a pre-migration build
#. Capture the :ref:`buildhistory <ref-classes-buildhistory>` output (as
#. Capture the :ref:`ref-classes-buildhistory` output (as
specified by :term:`BUILDHISTORY_DIR`) and ensure it is preserved for
subsequent builds. How you would do this depends on how you are running
your builds - if you are doing this all on one workstation in the same
:term:`Build Directory` you may not need to do anything other than not
deleting the :ref:`buildhistory <ref-classes-buildhistory>` output
deleting the :ref:`ref-classes-buildhistory` output
directory. For builds in a pipeline it may be more complicated.
#. Set a tag in the :ref:`buildhistory <ref-classes-buildhistory>` output (which is a git repository) before
#. Set a tag in the :ref:`ref-classes-buildhistory` output (which is a git repository) before
migration, to make the commit from the pre-migration build easy to find
as you may end up running multiple builds during the migration.
@ -102,7 +102,7 @@ any new Yocto Project release.
#. Run a build
#. Check the output changes between the previously set tag and HEAD in the
:ref:`buildhistory <ref-classes-buildhistory>` output using ``git diff`` or ``buildhistory-diff``.
:ref:`ref-classes-buildhistory` output using ``git diff`` or ``buildhistory-diff``.
For more information on using :ref:`buildhistory <ref-classes-buildhistory>`, see
For more information on using :ref:`ref-classes-buildhistory`, see
:ref:`dev-manual/build-quality:maintaining build output quality`.

4
documentation/migration-guides/release-notes-3.4.rst
View File

@ -9,7 +9,7 @@ New Features / Enhancements in 3.4
- Linux kernel 5.14, glibc 2.34 and ~280 other recipe upgrades
- Switched override character to ':' (replacing '_') for more robust parsing and improved performance --- see the above migration guide for help
- Rust integrated into core, providing rust support for cross-compilation and SDK
- New :ref:`create-spdx <ref-classes-create-spdx>` class for creating SPDX SBoM documents
- New :ref:`ref-classes-create-spdx` class for creating SPDX SBoM documents
- New recipes: cargo, core-image-ptest-all, core-image-ptest-fast, core-image-weston-sdk, erofs-utils, gcompat, gi-docgen, libmicrohttpd, libseccomp, libstd-rs, perlcross, python3-markdown, python3-pyyaml, python3-smartypants, python3-typogrify, rust, rust-cross, rust-cross-canadian, rust-hello-world, rust-llvm, rust-tools-cross-canadian, rustfmt, xwayland
- Several optimisations to reduce unnecessary task dependencies for faster builds
- seccomp integrated into core, with additional enabling for gnutls, systemd, qemu
@ -71,7 +71,7 @@ New Features / Enhancements in 3.4
- Enable :ref:`ref-tasks-populate_sdk` with multilibs
- New ``SDKPATHINSTALL`` variable decouples default install path from
built in path to avoid rebuilding :ref:`nativesdk <ref-classes-nativesdk>`
built in path to avoid rebuilding :ref:`ref-classes-nativesdk`
components on e.g. :term:`DISTRO_VERSION` changes
- eSDK: Error if trying to generate an eSDK from a multiconfig
- eSDK: introduce :term:`TOOLCHAIN_HOST_TASK_ESDK` to be used in place of :term:`TOOLCHAIN_HOST_TASK` to add components to the host part of the eSDK

11
documentation/migration-guides/release-notes-4.0.rst
View File

@ -13,7 +13,7 @@ New Features / Enhancements in 4.0
- Reproducibility: this release fixes the reproducibility issues with
``rust-llvm`` and ``golang``. Recipes in OpenEmbedded-Core are now fully
reproducible. Functionality previously in the optional "reproducible"
class has been merged into the :ref:`base <ref-classes-base>` class.
class has been merged into the :ref:`ref-classes-base` class.
- Network access is now disabled by default for tasks other than where it is expected to ensure build integrity (where host kernel supports it)
@ -31,8 +31,7 @@ New Features / Enhancements in 4.0
- The Python package build process is now based on `wheels <https://pythonwheels.com/>`__
in line with the upstream direction.
- New :ref:`overlayfs <ref-classes-overlayfs>` and
:ref:`overlayfs-etc <ref-classes-overlayfs-etc>` classes and
- New :ref:`ref-classes-overlayfs` and :ref:`ref-classes-overlayfs-etc` classes and
``overlayroot`` support in the :term:`Initramfs` framework to make it easier to
overlay read-only filesystems (for example) with
:wikipedia:`OverlayFS <OverlayFS>`.
@ -218,7 +217,7 @@ New Features / Enhancements in 4.0
- Ensure addition of patch-fuzz retriggers do_qa_patch
- Added a sanity check for allarch packagegroups
- :ref:`create-spdx <ref-classes-create-spdx>` class improvements:
- :ref:`ref-classes-create-spdx` class improvements:
- Get SPDX-License-Identifier from source files
- Generate manifest also for SDKs
@ -238,9 +237,9 @@ New Features / Enhancements in 4.0
- SDK-related enhancements:
- Extended recipes to :ref:`nativesdk <ref-classes-nativesdk>`: ``cargo``,
- Extended recipes to :ref:`ref-classes-nativesdk`: ``cargo``,
``librsvg``, ``libstd-rs``, ``libva``, ``python3-docutil``, ``python3-packaging``
- Enabled :ref:`nativesdk <ref-classes-nativesdk>` recipes to find a correct version
- Enabled :ref:`ref-classes-nativesdk` recipes to find a correct version
of the rust cross compiler
- Support creating per-toolchain cmake file in SDK

30
documentation/migration-guides/release-notes-4.1.rst
View File

@ -30,7 +30,7 @@ New Features / Enhancements in 4.1
- Support for building rust for the target
- Significant SDK toolchain build optimisation
- Support for building native components in the SDK
- Support ``crate://`` fetcher with :ref:`externalsrc <ref-classes-externalsrc>`
- Support ``crate://`` fetcher with :ref:`ref-classes-externalsrc`
- New core recipes:
@ -52,7 +52,7 @@ New Features / Enhancements in 4.1
- Added support for Ignored CVEs
- Enable recursive CVE checking also for ``do_populate_sdk``
- New :term:`CVE_CHECK_SHOW_WARNINGS` variable to disable unpatched CVE warning messages
- The :ref:`pypi <ref-classes-pypi>` class now defaults :term:`CVE_PRODUCT` from :term:`PYPI_PACKAGE`
- The :ref:`ref-classes-pypi` class now defaults :term:`CVE_PRODUCT` from :term:`PYPI_PACKAGE`
- Added current kernel CVEs to ignore list since we stay as close to the kernel stable releases as we can
- Optimisations to avoid dependencies on fetching
@ -60,9 +60,9 @@ New Features / Enhancements in 4.1
- Dependency of -dev package on main package is now an :term:`RRECOMMENDS` and can be easily set via new :term:`DEV_PKG_DEPENDENCY` variable
- Support for CPU, I/O and memory pressure regulation in BitBake
- Pressure data gathering in :ref:`buildstats <ref-classes-buildstats>` and rendering in ``pybootchartgui``
- Pressure data gathering in :ref:`ref-classes-buildstats` and rendering in ``pybootchartgui``
- New Picobuild system for lightweight Python PEP-517 build support in the :ref:`python_pep517 <ref-classes-python_pep517>` class
- New Picobuild system for lightweight Python PEP-517 build support in the :ref:`ref-classes-python_pep517` class
- Many classes are now split into global and recipe contexts for better
validation. For more information, see
@ -99,10 +99,10 @@ New Features / Enhancements in 4.1
- SDK-related enhancements:
- :ref:`Support for using the regular build system as an SDK <sdk-manual/extensible:Setting up the Extensible SDK environment directly in a Yocto build>`
- :ref:`image-buildinfo <ref-classes-image-buildinfo>` class now also writes build information to SDKs
- :ref:`ref-classes-image-buildinfo` class now also writes build information to SDKs
- New :term:`SDK_TOOLCHAIN_LANGS` variable to control support of rust / go in SDK
- rust-llvm: enabled :ref:`nativesdk <ref-classes-nativesdk>` variant
- python3-pluggy: enabled for :ref:`native <ref-classes-native>` / :ref:`nativesdk <ref-classes-nativesdk>`
- rust-llvm: enabled :ref:`ref-classes-nativesdk` variant
- python3-pluggy: enabled for :ref:`ref-classes-native` / :ref:`ref-classes-nativesdk`
- QEMU/runqemu enhancements:
@ -115,11 +115,11 @@ New Features / Enhancements in 4.1
- New variable :term:`UBOOT_MKIMAGE_KERNEL_TYPE`
- New variable :term:`FIT_PAD_ALG` to control FIT image padding algorithm
- New :term:`KERNEL_DEPLOY_DEPEND` variable to allow disabling image dependency on deploying the kernel
- :ref:`image_types <ref-classes-image_types>`: isolate the write of UBI
- :ref:`ref-classes-image_types`: isolate the write of UBI
configuration to a ``write_ubi_config`` function that can be easily overridden
- openssh: add support for config snippet includes to ssh and sshd
- :ref:`create-spdx <ref-classes-create-spdx>`: Add :term:`SPDX_PRETTY` option
- :ref:`ref-classes-create-spdx`: Add :term:`SPDX_PRETTY` option
- wpa-supplicant: build static library if not disabled via :term:`DISABLE_STATIC`
- wpa-supplicant: package dynamic modules
- openssl: extract legacy provider module to a separate package
@ -132,11 +132,11 @@ New Features / Enhancements in 4.1
- systemd: systemd-systemctl: Support instance conf files during enable
- weston.init: enable ``xwayland`` in weston.ini if ``x11`` is in :term:`DISTRO_FEATURES`
- New ``npm_registry`` Python module to enable caching with nodejs 16+
- :ref:`npm <ref-classes-npm>`: replaced ``npm pack`` call with ``tar czf`` for nodejs 16+ compatibility and improved ``do_configure`` performance
- Enabled :ref:`bin_package <ref-classes-bin-package>` class to work properly in the native case
- :ref:`ref-classes-npm`: replaced ``npm pack`` call with ``tar czf`` for nodejs 16+ compatibility and improved ``do_configure`` performance
- Enabled :ref:`ref-classes-bin-package` class to work properly in the native case
- Enabled :ref:`buildpaths <qa-check-buildpaths>` QA check as a warning by default
- New :term:`OVERLAYFS_ETC_EXPOSE_LOWER` to provide read-only access to the original ``/etc`` content with :ref:`overlayfs-etc <ref-classes-overlayfs-etc>`
- New :term:`OVERLAYFS_QA_SKIP` variable to allow skipping check on :ref:`overlayfs <ref-classes-overlayfs>` mounts
- New :term:`OVERLAYFS_ETC_EXPOSE_LOWER` to provide read-only access to the original ``/etc`` content with :ref:`ref-classes-overlayfs-etc`
- New :term:`OVERLAYFS_QA_SKIP` variable to allow skipping check on :ref:`ref-classes-overlayfs` mounts
- New :term:`PACKAGECONFIG` options for individual recipes:
- apr: xsi-strerror
@ -176,7 +176,7 @@ New Features / Enhancements in 4.1
- The Python ``zoneinfo`` module is now split out to its own ``python3-zoneinfo`` package.
- busybox: added devmem 128-bit support
- vim: split xxd out into its own package
- New :ref:`github-releases <ref-classes-github-releases>` class to consolidate version checks for github-based packages
- New :ref:`ref-classes-github-releases` class to consolidate version checks for github-based packages
- ``devtool reset`` now preserves ``workspace/sources`` source trees in ``workspace/attic/sources/`` instead of leaving them in-place
- scripts/patchreview: Add commit to stored json data
- scripts/patchreview: Make json output human parsable
@ -204,7 +204,7 @@ Known Issues in 4.1
:yocto_bugs:`bug 14626 </show_bug.cgi?id=14626>`, which also details the fix.
- The change to :ref:`migration-4.1-classes-split` inadvertently moved the
:ref:`externalsrc <ref-classes-externalsrc>` class to ``meta/classes-recipe``,
:ref:`ref-classes-externalsrc` class to ``meta/classes-recipe``,
when it is not recipe-specific and can also be used in a global context. The
class will be moved back to ``meta/classes`` in the next point release. Filed
as :yocto_bugs:`bug 14940 </show_bug.cgi?id=14940>`.

58
documentation/overview-manual/concepts.rst
View File

@ -107,8 +107,7 @@ Classes
-------
Class files (``.bbclass``) contain information that is useful to share
between recipes files. An example is the
:ref:`autotools <ref-classes-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 <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 <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.
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 <ref-classes-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 <ref-classes-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 <ref-classes-autotools>` class
class, see the :ref:`ref-classes-autotools` class
:yocto_git:`here </poky/tree/meta/classes-recipe/autotools.bbclass>`.
- *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 <ref-classes-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 <ref-classes-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 <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.
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 <ref-classes-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 <ref-classes-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 <ref-classes-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 <ref-classes-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

611
documentation/ref-manual/classes.rst
View File

File diff suppressed because it is too large Load Diff

2
documentation/ref-manual/features.rst
View File

@ -358,7 +358,7 @@ Here are the image features available for all images:
a given image.
Some image features are available only when you inherit the
:ref:`core-image <ref-classes-core-image>` class. The current list of
:ref:`ref-classes-core-image` class. The current list of
these valid features is as follows:
- *hwcodecs:* Installs hardware acceleration codecs.

12
documentation/ref-manual/qa-checks.rst
View File

@ -580,7 +580,7 @@ Errors and Warnings
The specified package contains mime type files (``.xml`` files in
``${datadir}/mime/packages``) and yet does not inherit the
:ref:`mime <ref-classes-mime>` class which will ensure that these get
:ref:`ref-classes-mime` class which will ensure that these get
properly installed. Either add ``inherit mime`` to the recipe or remove the
files at the :ref:`ref-tasks-install` step if they are not needed.
@ -590,7 +590,7 @@ Errors and Warnings
- ``package contains desktop file with key 'MimeType' but does not inhert mime-xdg: <packagename> path '<file>' [mime-xdg]``
The specified package contains a .desktop file with a 'MimeType' key
present, but does not inherit the :ref:`mime-xdg <ref-classes-mime-xdg>`
present, but does not inherit the :ref:`ref-classes-mime-xdg`
class that is required in order for that to be activated. Either add
``inherit mime`` to the recipe or remove the files at the
:ref:`ref-tasks-install` step if they are not needed.
@ -621,9 +621,9 @@ Errors and Warnings
- ``<recipename>: recipe doesn't inherit features_check [unhandled-features-check]``
This check ensures that if one of the variables that the
:ref:`features_check <ref-classes-features_check>` class supports (e.g.
:ref:`ref-classes-features_check` class supports (e.g.
:term:`REQUIRED_DISTRO_FEATURES`) is used, then the recipe
inherits :ref:`features_check <ref-classes-features_check>` in order for
inherits :ref:`ref-classes-features_check` in order for
the requirement to actually work. If you are seeing this message, either
add ``inherit features_check`` to your recipe or remove the reference to
the variable if it is not needed.
@ -634,7 +634,7 @@ Errors and Warnings
- ``<recipename>: recipe defines ALTERNATIVE:<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]``
This check ensures that if a recipe sets the :term:`ALTERNATIVE` variable that the
recipe also inherits :ref:`update-alternatives <ref-classes-update-alternatives>` such
recipe also inherits :ref:`ref-classes-update-alternatives` such
that the alternative will be correctly set up. If you are seeing this message, either
add ``inherit update-alternatives`` to your recipe or remove the reference to the variable
if it is not needed.
@ -655,7 +655,7 @@ Errors and Warnings
- ``<packagename> contains perllocal.pod (<files>), should not be installed [perllocalpod]``
``perllocal.pod`` is an index file of locally installed modules and so shouldn't be
installed by any distribution packages. The :ref:`cpan <ref-classes-cpan>` class
installed by any distribution packages. The :ref:`ref-classes-cpan` class
already sets ``NO_PERLLOCAL`` to stop this file being generated by most Perl recipes,
but if a recipe is using ``MakeMaker`` directly then they might not be doing this
correctly. This check ensures that perllocal.pod is not in any package in order to

4
documentation/ref-manual/structure.rst
View File

@ -233,7 +233,7 @@ is available via the :term:`TOPDIR` variable.
-----------------------
The OpenEmbedded build system creates this directory when you enable
build history via the :ref:`buildhistory <ref-classes-buildhistory>` class file. The directory
build history via the :ref:`ref-classes-buildhistory` class file. The directory
organizes build information into image, packages, and SDK
subdirectories. For information on the build history feature, see the
":ref:`dev-manual/build-quality:maintaining build output quality`"
@ -375,7 +375,7 @@ remove the ``build/sstate-cache`` directory.
~~~~~~~~~~~~~~~~~~~~~~~~~
This directory stores the build statistics as generated by the
:ref:`buildstats <ref-classes-buildstats>` class.
:ref:`ref-classes-buildstats` class.
.. _structure-build-tmp-cache:

10
documentation/ref-manual/tasks.rst
View File

@ -78,9 +78,9 @@ task runs with the current working directory set to
``${``\ :term:`B`\ ``}``.
Recipes implementing this task should inherit the
:ref:`deploy <ref-classes-deploy>` class and should write the output
:ref:`ref-classes-deploy` class and should write the output
to ``${``\ :term:`DEPLOYDIR`\ ``}``, which is not to be
confused with ``${DEPLOY_DIR}``. The :ref:`deploy <ref-classes-deploy>` class sets up
confused with ``${DEPLOY_DIR}``. The :ref:`ref-classes-deploy` class sets up
:ref:`ref-tasks-deploy` as a shared state (sstate) task that can be accelerated
through sstate use. The sstate mechanism takes care of copying the
output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``.
@ -102,7 +102,7 @@ Adding :ref:`ref-tasks-deploy` after other tasks works the same way.
.. note::
You do not need to add ``before do_build`` to the ``addtask`` command
(though it is harmless), because the :ref:`base <ref-classes-base>` class contains the following::
(though it is harmless), because the :ref:`ref-classes-base` class contains the following::
do_build[recrdeptask] += "do_deploy"
@ -225,7 +225,7 @@ section in the Yocto Project Overview and Concepts Manual.
-----------------
Runs QA checks on packaged files. For more information on these checks,
see the :ref:`insane <ref-classes-insane>` class.
see the :ref:`ref-classes-insane` class.
.. _ref-tasks-package_write_deb:
@ -406,7 +406,7 @@ Installs the files into the individual recipe specific sysroots (i.e.
``recipe-sysroot`` and ``recipe-sysroot-native`` under
``${``\ :term:`WORKDIR`\ ``}`` based upon the
dependencies specified by :term:`DEPENDS`). See the
":ref:`staging <ref-classes-staging>`" class for more information.
":ref:`ref-classes-staging`" class for more information.
.. _ref-tasks-rm_work:

688
documentation/ref-manual/variables.rst
View File

File diff suppressed because it is too large Load Diff

3
documentation/sdk-manual/appendix-customizing.rst
View File

@ -49,8 +49,7 @@ build system applies them against ``local.conf`` and ``auto.conf``:
:term:`ESDK_CLASS_INHERIT_DISABLE` to disable these classes is the typical
method to disable classes that are problematic or unnecessary in the SDK
context. The default value disables the
:ref:`buildhistory <ref-classes-buildhistory>` and
:ref:`icecc <ref-classes-icecc>` classes.
:ref:`ref-classes-buildhistory` and :ref:`ref-classes-icecc` classes.
Additionally, the contents of ``conf/sdk-extra.conf``, when present, are
appended to the end of ``conf/local.conf`` within the produced SDK,

5
documentation/sdk-manual/extensible.rst
View File

@ -1079,9 +1079,8 @@ does not include complete instructions for building the software.
Instead, common functionality is encapsulated in classes inherited with
the ``inherit`` directive. This technique leaves the recipe to describe
just the things that are specific to the software being built. There is
a :ref:`base <ref-classes-base>` class that
is implicitly inherited by all recipes and provides the functionality
that most recipes typically need.
a :ref:`ref-classes-base` class that is implicitly inherited by all recipes
and provides the functionality that most recipes typically need.
The remainder of this section presents information useful when working
with recipes.

18
documentation/test-manual/intro.rst
View File

@ -100,12 +100,11 @@ the following types of tests:
different configurations, such as different init systems. The
Autobuilder tests literally hundreds of configurations and targets.
- *Sanity Checks During the Build Process:* Tests initiated through
the :ref:`insane <ref-classes-insane>`
class. These checks ensure the output of the builds are correct.
For example, does the ELF architecture in the generated binaries
match the target system? ARM binaries would not work in a MIPS
system!
- *Sanity Checks During the Build Process:* Tests initiated through the
:ref:`ref-classes-insane` class. These checks ensure the output of the
builds are correct. For example, does the ELF architecture in the
generated binaries match the target system? ARM binaries would not work
in a MIPS system!
- *Build Performance Testing:* Tests whether or not commonly used steps
during builds work efficiently and avoid regressions. Tests to time
@ -121,7 +120,8 @@ the following types of tests:
$ bitbake image -c testsdkext
The tests utilize the :ref:`testsdkext <ref-classes-testsdk>` class and the ``do_testsdkext`` task.
The tests utilize the :ref:`ref-classes-testsdk` class and the
``do_testsdkext`` task.
- *Feature Testing:* Various scenario-based tests are run through the
:ref:`OpenEmbedded Self test (oe-selftest) <ref-manual/release-process:Testing and Quality Assurance>`. We test oe-selftest on each of the main distributions
@ -131,7 +131,7 @@ the following types of tests:
$ bitbake image -c testimage
The tests utilize the :ref:`testimage <ref-classes-testimage>`
The tests utilize the :ref:`ref-classes-testimage`
class and the :ref:`ref-tasks-testimage` task.
- *Layer Testing:* The Autobuilder has the possibility to test whether
@ -151,7 +151,7 @@ the following types of tests:
$ bitbake image -c testsdk
The tests utilize the :ref:`testsdk <ref-classes-testsdk>` class and
The tests utilize the :ref:`ref-classes-testsdk` class and
the ``do_testsdk`` task.
- *Unit Testing:* Unit tests on various components of the system run

2
documentation/test-manual/understand-autobuilder.rst
View File

@ -206,7 +206,7 @@ are general setup steps that are run once and include:
#. Set up any :term:`buildtools` tarball if configured.
#. Call "buildhistory-init" if :ref:`buildhistory <ref-classes-buildhistory>` is configured.
#. Call "buildhistory-init" if :ref:`ref-classes-buildhistory` is configured.
For each step that is configured in ``config.json``, it will perform the
following: