29 files changed, 0 insertions, 8207 deletions
diff --git a/bitbake/doc/.gitignore b/bitbake/doc/.gitignore
deleted file mode 100644
index 69fa449dd9..0000000000
--- a/bitbake/doc/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-_build/
diff --git a/bitbake/doc/COPYING.GPL b/bitbake/doc/COPYING.GPL
deleted file mode 100644
index d511905c16..0000000000
--- a/bitbake/doc/COPYING.GPL
+++ /dev/null
@@ -1,339 +0,0 @@
-                    GNU GENERAL PUBLIC LICENSE
-                       Version 2, June 1991
- Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
- 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
- Everyone is permitted to copy and distribute verbatim copies
- of this license document, but changing it is not allowed.
-                            Preamble
-  The licenses for most software are designed to take away your
-freedom to share and change it.  By contrast, the GNU General Public
-License is intended to guarantee your freedom to share and change free
-software--to make sure the software is free for all its users.  This
-General Public License applies to most of the Free Software
-Foundation's software and to any other program whose authors commit to
-using it.  (Some other Free Software Foundation software is covered by
-the GNU Lesser General Public License instead.)  You can apply it to
-your programs, too.
-  When we speak of free software, we are referring to freedom, not
-price.  Our General Public Licenses are designed to make sure that you
-have the freedom to distribute copies of free software (and charge for
-this service if you wish), that you receive source code or can get it
-if you want it, that you can change the software or use pieces of it
-in new free programs; and that you know you can do these things.
-  To protect your rights, we need to make restrictions that forbid
-anyone to deny you these rights or to ask you to surrender the rights.
-These restrictions translate to certain responsibilities for you if you
-distribute copies of the software, or if you modify it.
-  For example, if you distribute copies of such a program, whether
-gratis or for a fee, you must give the recipients all the rights that
-you have.  You must make sure that they, too, receive or can get the
-source code.  And you must show them these terms so they know their
-rights.
-  We protect your rights with two steps: (1) copyright the software, and
-(2) offer you this license which gives you legal permission to copy,
-distribute and/or modify the software.
-  Also, for each author's protection and ours, we want to make certain
-that everyone understands that there is no warranty for this free
-software.  If the software is modified by someone else and passed on, we
-want its recipients to know that what they have is not the original, so
-that any problems introduced by others will not reflect on the original
-authors' reputations.
-  Finally, any free program is threatened constantly by software
-patents.  We wish to avoid the danger that redistributors of a free
-program will individually obtain patent licenses, in effect making the
-program proprietary.  To prevent this, we have made it clear that any
-patent must be licensed for everyone's free use or not licensed at all.
-  The precise terms and conditions for copying, distribution and
-modification follow.
-                    GNU GENERAL PUBLIC LICENSE
-   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
-  0. This License applies to any program or other work which contains
-a notice placed by the copyright holder saying it may be distributed
-under the terms of this General Public License.  The "Program", below,
-refers to any such program or work, and a "work based on the Program"
-means either the Program or any derivative work under copyright law:
-that is to say, a work containing the Program or a portion of it,
-either verbatim or with modifications and/or translated into another
-language.  (Hereinafter, translation is included without limitation in
-the term "modification".)  Each licensee is addressed as "you".
-Activities other than copying, distribution and modification are not
-covered by this License; they are outside its scope.  The act of
-running the Program is not restricted, and the output from the Program
-is covered only if its contents constitute a work based on the
-Program (independent of having been made by running the Program).
-Whether that is true depends on what the Program does.
-  1. You may copy and distribute verbatim copies of the Program's
-source code as you receive it, in any medium, provided that you
-conspicuously and appropriately publish on each copy an appropriate
-copyright notice and disclaimer of warranty; keep intact all the
-notices that refer to this License and to the absence of any warranty;
-and give any other recipients of the Program a copy of this License
-along with the Program.
-You may charge a fee for the physical act of transferring a copy, and
-you may at your option offer warranty protection in exchange for a fee.
-  2. You may modify your copy or copies of the Program or any portion
-of it, thus forming a work based on the Program, and copy and
-distribute such modifications or work under the terms of Section 1
-above, provided that you also meet all of these conditions:
-    a) You must cause the modified files to carry prominent notices
-    stating that you changed the files and the date of any change.
-    b) You must cause any work that you distribute or publish, that in
-    whole or in part contains or is derived from the Program or any
-    part thereof, to be licensed as a whole at no charge to all third
-    parties under the terms of this License.
-    c) If the modified program normally reads commands interactively
-    when run, you must cause it, when started running for such
-    interactive use in the most ordinary way, to print or display an
-    announcement including an appropriate copyright notice and a
-    notice that there is no warranty (or else, saying that you provide
-    a warranty) and that users may redistribute the program under
-    these conditions, and telling the user how to view a copy of this
-    License.  (Exception: if the Program itself is interactive but
-    does not normally print such an announcement, your work based on
-    the Program is not required to print an announcement.)
-These requirements apply to the modified work as a whole.  If
-identifiable sections of that work are not derived from the Program,
-and can be reasonably considered independent and separate works in
-themselves, then this License, and its terms, do not apply to those
-sections when you distribute them as separate works.  But when you
-distribute the same sections as part of a whole which is a work based
-on the Program, the distribution of the whole must be on the terms of
-this License, whose permissions for other licensees extend to the
-entire whole, and thus to each and every part regardless of who wrote it.
-Thus, it is not the intent of this section to claim rights or contest
-your rights to work written entirely by you; rather, the intent is to
-exercise the right to control the distribution of derivative or
-collective works based on the Program.
-In addition, mere aggregation of another work not based on the Program
-with the Program (or with a work based on the Program) on a volume of
-a storage or distribution medium does not bring the other work under
-the scope of this License.
-  3. You may copy and distribute the Program (or a work based on it,
-under Section 2) in object code or executable form under the terms of
-Sections 1 and 2 above provided that you also do one of the following:
-    a) Accompany it with the complete corresponding machine-readable
-    source code, which must be distributed under the terms of Sections
-    1 and 2 above on a medium customarily used for software interchange; or,
-    b) Accompany it with a written offer, valid for at least three
-    years, to give any third party, for a charge no more than your
-    cost of physically performing source distribution, a complete
-    machine-readable copy of the corresponding source code, to be
-    distributed under the terms of Sections 1 and 2 above on a medium
-    customarily used for software interchange; or,
-    c) Accompany it with the information you received as to the offer
-    to distribute corresponding source code.  (This alternative is
-    allowed only for noncommercial distribution and only if you
-    received the program in object code or executable form with such
-    an offer, in accord with Subsection b above.)
-The source code for a work means the preferred form of the work for
-making modifications to it.  For an executable work, complete source
-code means all the source code for all modules it contains, plus any
-associated interface definition files, plus the scripts used to
-control compilation and installation of the executable.  However, as a
-special exception, the source code distributed need not include
-anything that is normally distributed (in either source or binary
-form) with the major components (compiler, kernel, and so on) of the
-operating system on which the executable runs, unless that component
-itself accompanies the executable.
-If distribution of executable or object code is made by offering
-access to copy from a designated place, then offering equivalent
-access to copy the source code from the same place counts as
-distribution of the source code, even though third parties are not
-compelled to copy the source along with the object code.
-  4. You may not copy, modify, sublicense, or distribute the Program
-except as expressly provided under this License.  Any attempt
-otherwise to copy, modify, sublicense or distribute the Program is
-void, and will automatically terminate your rights under this License.
-However, parties who have received copies, or rights, from you under
-this License will not have their licenses terminated so long as such
-parties remain in full compliance.
-  5. You are not required to accept this License, since you have not
-signed it.  However, nothing else grants you permission to modify or
-distribute the Program or its derivative works.  These actions are
-prohibited by law if you do not accept this License.  Therefore, by
-modifying or distributing the Program (or any work based on the
-Program), you indicate your acceptance of this License to do so, and
-all its terms and conditions for copying, distributing or modifying
-the Program or works based on it.
-  6. Each time you redistribute the Program (or any work based on the
-Program), the recipient automatically receives a license from the
-original licensor to copy, distribute or modify the Program subject to
-these terms and conditions.  You may not impose any further
-restrictions on the recipients' exercise of the rights granted herein.
-You are not responsible for enforcing compliance by third parties to
-this License.
-  7. If, as a consequence of a court judgment or allegation of patent
-infringement or for any other reason (not limited to patent issues),
-conditions are imposed on you (whether by court order, agreement or
-otherwise) that contradict the conditions of this License, they do not
-excuse you from the conditions of this License.  If you cannot
-distribute so as to satisfy simultaneously your obligations under this
-License and any other pertinent obligations, then as a consequence you
-may not distribute the Program at all.  For example, if a patent
-license would not permit royalty-free redistribution of the Program by
-all those who receive copies directly or indirectly through you, then
-the only way you could satisfy both it and this License would be to
-refrain entirely from distribution of the Program.
-If any portion of this section is held invalid or unenforceable under
-any particular circumstance, the balance of the section is intended to
-apply and the section as a whole is intended to apply in other
-circumstances.
-It is not the purpose of this section to induce you to infringe any
-patents or other property right claims or to contest validity of any
-such claims; this section has the sole purpose of protecting the
-integrity of the free software distribution system, which is
-implemented by public license practices.  Many people have made
-generous contributions to the wide range of software distributed
-through that system in reliance on consistent application of that
-system; it is up to the author/donor to decide if he or she is willing
-to distribute software through any other system and a licensee cannot
-impose that choice.
-This section is intended to make thoroughly clear what is believed to
-be a consequence of the rest of this License.
-  8. If the distribution and/or use of the Program is restricted in
-certain countries either by patents or by copyrighted interfaces, the
-original copyright holder who places the Program under this License
-may add an explicit geographical distribution limitation excluding
-those countries, so that distribution is permitted only in or among
-countries not thus excluded.  In such case, this License incorporates
-the limitation as if written in the body of this License.
-  9. The Free Software Foundation may publish revised and/or new versions
-of the General Public License from time to time.  Such new versions will
-be similar in spirit to the present version, but may differ in detail to
-address new problems or concerns.
-Each version is given a distinguishing version number.  If the Program
-specifies a version number of this License which applies to it and "any
-later version", you have the option of following the terms and conditions
-either of that version or of any later version published by the Free
-Software Foundation.  If the Program does not specify a version number of
-this License, you may choose any version ever published by the Free Software
-Foundation.
-  10. If you wish to incorporate parts of the Program into other free
-programs whose distribution conditions are different, write to the author
-to ask for permission.  For software which is copyrighted by the Free
-Software Foundation, write to the Free Software Foundation; we sometimes
-make exceptions for this.  Our decision will be guided by the two goals
-of preserving the free status of all derivatives of our free software and
-of promoting the sharing and reuse of software generally.
-                            NO WARRANTY
-  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
-FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
-OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
-PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
-OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
-TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
-PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
-REPAIR OR CORRECTION.
-  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
-WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
-REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
-INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
-OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
-TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
-YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
-PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
-POSSIBILITY OF SUCH DAMAGES.
-                     END OF TERMS AND CONDITIONS
-            How to Apply These Terms to Your New Programs
-  If you develop a new program, and you want it to be of the greatest
-possible use to the public, the best way to achieve this is to make it
-free software which everyone can redistribute and change under these terms.
-  To do so, attach the following notices to the program.  It is safest
-to attach them to the start of each source file to most effectively
-convey the exclusion of warranty; and each file should have at least
-the "copyright" line and a pointer to where the full notice is found.
-    <one line to give the program's name and a brief idea of what it does.>
-    Copyright (C) <year>  <name of author>
-    This program is free software; you can redistribute it and/or modify
-    it under the terms of the GNU General Public License as published by
-    the Free Software Foundation; either version 2 of the License, or
-    (at your option) any later version.
-    This program is distributed in the hope that it will be useful,
-    but WITHOUT ANY WARRANTY; without even the implied warranty of
-    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-    GNU General Public License for more details.
-    You should have received a copy of the GNU General Public License along
-    with this program; if not, write to the Free Software Foundation, Inc.,
-    51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
-Also add information on how to contact you by electronic and paper mail.
-If the program is interactive, make it output a short notice like this
-when it starts in an interactive mode:
-    Gnomovision version 69, Copyright (C) year name of author
-    Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
-    This is free software, and you are welcome to redistribute it
-    under certain conditions; type `show c' for details.
-The hypothetical commands `show w' and `show c' should show the appropriate
-parts of the General Public License.  Of course, the commands you use may
-be called something other than `show w' and `show c'; they could even be
-mouse-clicks or menu items--whatever suits your program.
-You should also get your employer (if you work as a programmer) or your
-school, if any, to sign a "copyright disclaimer" for the program, if
-necessary.  Here is a sample; alter the names:
-  Yoyodyne, Inc., hereby disclaims all copyright interest in the program
-  `Gnomovision' (which makes passes at compilers) written by James Hacker.
-  <signature of Ty Coon>, 1 April 1989
-  Ty Coon, President of Vice
-This General Public License does not permit incorporating your program into
-proprietary programs.  If your program is a subroutine library, you may
-consider it more useful to permit linking proprietary applications with the
-library.  If this is what you want to do, use the GNU Lesser General
-Public License instead of this License.
diff --git a/bitbake/doc/COPYING.MIT b/bitbake/doc/COPYING.MIT
deleted file mode 100644
index 7e7d57413d..0000000000
--- a/bitbake/doc/COPYING.MIT
+++ /dev/null
@@ -1,17 +0,0 @@
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT
-SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
-DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
-OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR
-THE USE OR OTHER DEALINGS IN THE SOFTWARE.
diff --git a/bitbake/doc/Makefile b/bitbake/doc/Makefile
deleted file mode 100644
index 996f01b7d5..0000000000
--- a/bitbake/doc/Makefile
+++ /dev/null
@@ -1,35 +0,0 @@
-# Minimal makefile for Sphinx documentation
-#
-# You can set these variables from the command line, and also
-# from the environment for the first two.
-SPHINXOPTS    ?= -W --keep-going -j auto
-SPHINXBUILD   ?= sphinx-build
-SOURCEDIR     = .
-BUILDDIR      = _build
-DESTDIR       = final
-ifeq ($(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi),0)
-$(error "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed")
-endif
-# Put it first so that "make" without argument is like "make help".
-help:
-        @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
-.PHONY: help Makefile clean publish
-publish: Makefile html singlehtml
-        rm -rf $(BUILDDIR)/$(DESTDIR)/
-        mkdir -p $(BUILDDIR)/$(DESTDIR)/
-        cp -r $(BUILDDIR)/html/* $(BUILDDIR)/$(DESTDIR)/
-        cp $(BUILDDIR)/singlehtml/index.html $(BUILDDIR)/$(DESTDIR)/singleindex.html
-        sed -i -e 's@index.html#@singleindex.html#@g' $(BUILDDIR)/$(DESTDIR)/singleindex.html
-clean:
-        @rm -rf $(BUILDDIR)
-# Catch-all target: route all unknown targets to Sphinx using the new
-# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
-%: Makefile
-        @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
diff --git a/bitbake/doc/README b/bitbake/doc/README
deleted file mode 100644
index d4f56afa37..0000000000
--- a/bitbake/doc/README
+++ /dev/null
@@ -1,55 +0,0 @@
-Documentation
-=============
-This is the directory that contains the BitBake documentation. 
-Manual Organization
-===================
-Folders exist for individual manuals as follows:
-* bitbake-user-manual      --- The BitBake User Manual 
-Each folder is self-contained regarding content and figures.
-If you want to find HTML versions of the BitBake manuals on the web, 
-go to https://www.openembedded.org/wiki/Documentation.
-Sphinx
-======
-The BitBake documentation was migrated from the original DocBook
-format to Sphinx based documentation for the Yocto Project 3.2
-release.
-Additional information related to the Sphinx migration, and guidelines
-for developers willing to contribute to the BitBake documentation can
-be found in the Yocto Project Documentation README file:
-https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/tree/documentation/README
-How to build the Yocto Project documentation
-============================================
-Sphinx is written in Python. While it might work with Python2, for
-obvious reasons, we will only support building the BitBake
-documentation with Python3.
-Sphinx might be available in your Linux distro packages repositories,
-however it is not recommend using distro packages, as they might be
-old versions, especially if you are using an LTS version of your
-distro. The recommended method to install Sphinx and all required
-dependencies is to use the Python Package Index (pip).
-To install all required packages run:
- $ pip3 install sphinx sphinx_rtd_theme pyyaml
-To build the documentation locally, run:
- $ cd doc
- $ make html
-The resulting HTML index page will be _build/html/index.html, and you
-can browse your own copy of the locally generated documentation with
-your browser.
diff --git a/bitbake/doc/_templates/breadcrumbs.html b/bitbake/doc/_templates/breadcrumbs.html
deleted file mode 100644
index eb6244b74c..0000000000
--- a/bitbake/doc/_templates/breadcrumbs.html
+++ /dev/null
@@ -1,14 +0,0 @@
-{% extends "!breadcrumbs.html" %}
-{% block breadcrumbs %}
-    <li>
-      <span class="doctype_switcher_placeholder">{{ doctype or 'single' }}</span>
-      <span class="version_switcher_placeholder">{{ release }}</span>
-    </li>
-    <li> &raquo;</li>
-    {% for doc in parents %}
-      <li><a href="{{ doc.link|e }}">{{ doc.title }}</a> &raquo;</li>
-    {% endfor %}
-    <li>{{ title }}</li>
-{% endblock %}
diff --git a/bitbake/doc/_templates/footer.html b/bitbake/doc/_templates/footer.html
deleted file mode 100644
index 1398f20d7e..0000000000
--- a/bitbake/doc/_templates/footer.html
+++ /dev/null
@@ -1,9 +0,0 @@
-<footer>
-  <hr/>
-  <div role="contentinfo">
-    <p>&copy; Copyright {{ copyright }}
-       <br>Last updated on {{ last_updated }} from the <a href="https://git.openembedded.org/bitbake/">bitbake</a> git repository.
-    </p>
-  </div>
-</footer>
diff --git a/bitbake/doc/_templates/layout.html b/bitbake/doc/_templates/layout.html
deleted file mode 100644
index 308d5c7a28..0000000000
--- a/bitbake/doc/_templates/layout.html
+++ /dev/null
@@ -1,7 +0,0 @@
-{% extends "!layout.html" %}
-{% block extrabody %}
-<div id="outdated-warning" style="text-align: center; background-color: #FFBABA; color: #6A0E0E;">
-</div>
-{% endblock %}
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.rst
deleted file mode 100644
index d407f59c0d..0000000000
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-execution.rst
+++ /dev/null
@@ -1,761 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-=========
-Execution
-=========
-|
-The primary purpose for running BitBake is to produce some kind of
-output such as a single installable package, a kernel, a software
-development kit, or even a full, board-specific bootable Linux image,
-complete with bootloader, kernel, and root filesystem. Of course, you
-can execute the ``bitbake`` command with options that cause it to
-execute single tasks, compile single recipe files, capture or clear
-data, or simply return information about the execution environment.
-This chapter describes BitBake's execution process from start to finish
-when you use it to create an image. The execution process is launched
-using the following command form::
-  $ bitbake target
-For information on
-the BitBake command and its options, see ":ref:`The BitBake Command
-<bitbake-user-manual-command>`" section.
-.. note::
-   Prior to executing BitBake, you should take advantage of available
-   parallel thread execution on your build host by setting the
-   :term:`BB_NUMBER_THREADS` variable in
-   your project's ``local.conf`` configuration file.
-   A common method to determine this value for your build host is to run
-   the following::
-     $ grep processor /proc/cpuinfo
-   This command returns
-   the number of processors, which takes into account hyper-threading.
-   Thus, a quad-core build host with hyper-threading most likely shows
-   eight processors, which is the value you would then assign to
-   :term:`BB_NUMBER_THREADS`.
-   A possibly simpler solution is that some Linux distributions (e.g.
-   Debian and Ubuntu) provide the ``ncpus`` command.
-Parsing the Base Configuration Metadata
-=======================================
-The first thing BitBake does is parse base configuration metadata. Base
-configuration metadata consists of your project's ``bblayers.conf`` file
-to determine what layers BitBake needs to recognize, all necessary
-``layer.conf`` files (one from each layer), and ``bitbake.conf``. The
-data itself is of various types:
-  **Recipes:** Details about particular pieces of software.
-  **Class Data:** An abstraction of common build information (e.g. how to
-   build a Linux kernel).
-  **Configuration Data:** Machine-specific settings, policy decisions,
-   and so forth. Configuration data acts as the glue to bind everything
-   together.
-The ``layer.conf`` files are used to construct key variables such as
-:term:`BBPATH` and :term:`BBFILES`. :term:`BBPATH` is used to search for
-configuration files under the ``conf`` directory and class files under the
-``classes-global``, ``classes-recipe`` and ``classes`` directories.
-:term:`BBFILES` is used to locate both recipe and recipe append files (``.bb``
-and ``.bbappend``). If there is no ``bblayers.conf`` file, it is assumed the
-user has set the :term:`BBPATH` and :term:`BBFILES` directly in the environment.
-Next, the ``bitbake.conf`` file is located using the :term:`BBPATH` variable
-that was just constructed. The ``bitbake.conf`` file may also include
-other configuration files using the ``include`` or ``require``
-directives.
-Prior to parsing configuration files, BitBake looks at certain
-variables, including:
-  :term:`BB_ENV_PASSTHROUGH`
-  :term:`BB_ENV_PASSTHROUGH_ADDITIONS`
-  :term:`BB_PRESERVE_ENV`
-  :term:`BB_ORIGENV`
-  :term:`BITBAKE_UI`
-The first four variables in this list relate to how BitBake treats shell
-environment variables during task execution. By default, BitBake cleans
-the environment variables and provides tight control over the shell
-execution environment. However, through the use of these first four
-variables, you can apply your control regarding the environment
-variables allowed to be used by BitBake in the shell during execution of
-tasks. See the
-":ref:`bitbake-user-manual/bitbake-user-manual-metadata:Passing Information Into the Build Task Environment`"
-section and the information about these variables in the variable
-glossary for more information on how they work and on how to use them.
-The base configuration metadata is global and therefore affects all
-recipes and tasks that are executed.
-BitBake first searches the current working directory for an optional
-``conf/bblayers.conf`` configuration file. This file is expected to
-contain a :term:`BBLAYERS` variable that is a
-space-delimited list of 'layer' directories. Recall that if BitBake
-cannot find a ``bblayers.conf`` file, then it is assumed the user has
-set the :term:`BBPATH` and :term:`BBFILES` variables directly in the
-environment.
-For each directory (layer) in this list, a ``conf/layer.conf`` file is
-located and parsed with the :term:`LAYERDIR` variable
-being set to the directory where the layer was found. The idea is these
-files automatically set up :term:`BBPATH` and other
-variables correctly for a given build directory.
-BitBake then expects to find the ``conf/bitbake.conf`` file somewhere in
-the user-specified :term:`BBPATH`. That configuration file generally has
-include directives to pull in any other metadata such as files specific
-to the architecture, the machine, the local environment, and so forth.
-Only variable definitions and include directives are allowed in BitBake
-``.conf`` files. Some variables directly influence BitBake's behavior.
-These variables might have been set from the environment depending on
-the environment variables previously mentioned or set in the
-configuration files. The ":ref:`bitbake-user-manual/bitbake-user-manual-ref-variables:Variables Glossary`"
-chapter presents a full list of
-variables.
-After parsing configuration files, BitBake uses its rudimentary
-inheritance mechanism, which is through class files, to inherit some
-standard classes. BitBake parses a class when the inherit directive
-responsible for getting that class is encountered.
-The ``base.bbclass`` file is always included. Other classes that are
-specified in the configuration using the
-:term:`INHERIT` variable are also included. BitBake
-searches for class files in a ``classes`` subdirectory under the paths
-in :term:`BBPATH` in the same way as configuration files.
-A good way to get an idea of the configuration files and the class files
-used in your execution environment is to run the following BitBake
-command::
-  $ bitbake -e > mybb.log
-Examining the top of the ``mybb.log``
-shows you the many configuration files and class files used in your
-execution environment.
-.. note::
-   You need to be aware of how BitBake parses curly braces. If a recipe
-   uses a closing curly brace within the function and the character has
-   no leading spaces, BitBake produces a parsing error. If you use a
-   pair of curly braces in a shell function, the closing curly brace
-   must not be located at the start of the line without leading spaces.
-   Here is an example that causes BitBake to produce a parsing error::
-      fakeroot create_shar() {
-         cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
-      usage()
-      {
-         echo "test"
-         ######  The following "}" at the start of the line causes a parsing error ######
-      }
-      EOF
-      }
-      Writing the recipe this way avoids the error:
-      fakeroot create_shar() {
-         cat << "EOF" > ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
-      usage()
-      {
-         echo "test"
-         ###### The following "}" with a leading space at the start of the line avoids the error ######
-       }
-      EOF
-      }
-Locating and Parsing Recipes
-============================
-During the configuration phase, BitBake will have set
-:term:`BBFILES`. BitBake now uses it to construct a
-list of recipes to parse, along with any append files (``.bbappend``) to
-apply. :term:`BBFILES` is a space-separated list of available files and
-supports wildcards. An example would be::
-  BBFILES = "/path/to/bbfiles/*.bb /path/to/appends/*.bbappend"
-BitBake parses each
-recipe and append file located with :term:`BBFILES` and stores the values of
-various variables into the datastore.
-.. note::
-   Append files are applied in the order they are encountered in BBFILES.
-For each file, a fresh copy of the base configuration is made, then the
-recipe is parsed line by line. Any inherit statements cause BitBake to
-find and then parse class files (``.bbclass``) using
-:term:`BBPATH` as the search path. Finally, BitBake
-parses in order any append files found in :term:`BBFILES`.
-One common convention is to use the recipe filename to define pieces of
-metadata. For example, in ``bitbake.conf`` the recipe name and version
-are used to set the variables :term:`PN` and
-:term:`PV`::
-   PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
-   PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
-In this example, a recipe called "something_1.2.3.bb" would set
-:term:`PN` to "something" and :term:`PV` to "1.2.3".
-By the time parsing is complete for a recipe, BitBake has a list of
-tasks that the recipe defines and a set of data consisting of keys and
-values as well as dependency information about the tasks.
-BitBake does not need all of this information. It only needs a small
-subset of the information to make decisions about the recipe.
-Consequently, BitBake caches the values in which it is interested and
-does not store the rest of the information. Experience has shown it is
-faster to re-parse the metadata than to try and write it out to the disk
-and then reload it.
-Where possible, subsequent BitBake commands reuse this cache of recipe
-information. The validity of this cache is determined by first computing
-a checksum of the base configuration data (see
-:term:`BB_HASHCONFIG_IGNORE_VARS`) and
-then checking if the checksum matches. If that checksum matches what is
-in the cache and the recipe and class files have not changed, BitBake is
-able to use the cache. BitBake then reloads the cached information about
-the recipe instead of reparsing it from scratch.
-Recipe file collections exist to allow the user to have multiple
-repositories of ``.bb`` files that contain the same exact package. For
-example, one could easily use them to make one's own local copy of an
-upstream repository, but with custom modifications that one does not
-want upstream. Here is an example::
-  BBFILES = "/stuff/openembedded/*/*.bb /stuff/openembedded.modified/*/*.bb"
-  BBFILE_COLLECTIONS = "upstream local"
-  BBFILE_PATTERN_upstream = "^/stuff/openembedded/"
-  BBFILE_PATTERN_local = "^/stuff/openembedded.modified/"
-  BBFILE_PRIORITY_upstream = "5"
-  BBFILE_PRIORITY_local = "10"
-.. note::
-   The layers mechanism is now the preferred method of collecting code.
-   While the collections code remains, its main use is to set layer
-   priorities and to deal with overlap (conflicts) between layers.
-.. _bb-bitbake-providers:
-Providers
-=========
-Assuming BitBake has been instructed to execute a target and that all
-the recipe files have been parsed, BitBake starts to figure out how to
-build the target. BitBake looks through the :term:`PROVIDES` list for each
-of the recipes. A :term:`PROVIDES` list is the list of names by which the
-recipe can be known. Each recipe's :term:`PROVIDES` list is created
-implicitly through the recipe's :term:`PN` variable and
-explicitly through the recipe's :term:`PROVIDES`
-variable, which is optional.
-When a recipe uses :term:`PROVIDES`, that recipe's functionality can be
-found under an alternative name or names other than the implicit :term:`PN`
-name. As an example, suppose a recipe named ``keyboard_1.0.bb``
-contained the following::
-  PROVIDES += "fullkeyboard"
-The :term:`PROVIDES`
-list for this recipe becomes "keyboard", which is implicit, and
-"fullkeyboard", which is explicit. Consequently, the functionality found
-in ``keyboard_1.0.bb`` can be found under two different names.
-.. _bb-bitbake-preferences:
-Preferences
-===========
-The :term:`PROVIDES` list is only part of the solution for figuring out a
-target's recipes. Because targets might have multiple providers, BitBake
-needs to prioritize providers by determining provider preferences.
-A common example in which a target has multiple providers is
-"virtual/kernel", which is on the :term:`PROVIDES` list for each kernel
-recipe. Each machine often selects the best kernel provider by using a
-line similar to the following in the machine configuration file::
-  PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
-The default :term:`PREFERRED_PROVIDER` is the provider
-with the same name as the target. BitBake iterates through each target
-it needs to build and resolves them and their dependencies using this
-process.
-Understanding how providers are chosen is made complicated by the fact
-that multiple versions might exist for a given provider. BitBake
-defaults to the highest version of a provider. Version comparisons are
-made using the same method as Debian. You can use the
-:term:`PREFERRED_VERSION` variable to
-specify a particular version. You can influence the order by using the
-:term:`DEFAULT_PREFERENCE` variable.
-By default, files have a preference of "0". Setting
-:term:`DEFAULT_PREFERENCE` to "-1" makes the recipe unlikely to be used
-unless it is explicitly referenced. Setting :term:`DEFAULT_PREFERENCE` to
-"1" makes it likely the recipe is used. :term:`PREFERRED_VERSION` overrides
-any :term:`DEFAULT_PREFERENCE` setting. :term:`DEFAULT_PREFERENCE` is often used
-to mark newer and more experimental recipe versions until they have
-undergone sufficient testing to be considered stable.
-When there are multiple "versions" of a given recipe, BitBake defaults
-to selecting the most recent version, unless otherwise specified. If the
-recipe in question has a
-:term:`DEFAULT_PREFERENCE` set lower than
-the other recipes (default is 0), then it will not be selected. This
-allows the person or persons maintaining the repository of recipe files
-to specify their preference for the default selected version.
-Additionally, the user can specify their preferred version.
-If the first recipe is named ``a_1.1.bb``, then the
-:term:`PN` variable will be set to "a", and the
-:term:`PV` variable will be set to 1.1.
-Thus, if a recipe named ``a_1.2.bb`` exists, BitBake will choose 1.2 by
-default. However, if you define the following variable in a ``.conf``
-file that BitBake parses, you can change that preference::
-  PREFERRED_VERSION_a = "1.1"
-.. note::
-   It is common for a recipe to provide two versions -- a stable,
-   numbered (and preferred) version, and a version that is automatically
-   checked out from a source code repository that is considered more
-   "bleeding edge" but can be selected only explicitly.
-   For example, in the OpenEmbedded codebase, there is a standard,
-   versioned recipe file for BusyBox, ``busybox_1.22.1.bb``, but there
-   is also a Git-based version, ``busybox_git.bb``, which explicitly
-   contains the line ::
-     DEFAULT_PREFERENCE = "-1"
-   to ensure that the
-   numbered, stable version is always preferred unless the developer
-   selects otherwise.
-.. _bb-bitbake-dependencies:
-Dependencies
-============
-Each target BitBake builds consists of multiple tasks such as ``fetch``,
-``unpack``, ``patch``, ``configure``, and ``compile``. For best
-performance on multi-core systems, BitBake considers each task as an
-independent entity with its own set of dependencies.
-Dependencies are defined through several variables. You can find
-information about variables BitBake uses in the
-:doc:`bitbake-user-manual-ref-variables` near the end of this manual. At a
-basic level, it is sufficient to know that BitBake uses the
-:term:`DEPENDS` and
-:term:`RDEPENDS` variables when calculating
-dependencies.
-For more information on how BitBake handles dependencies, see the
-:ref:`bitbake-user-manual/bitbake-user-manual-metadata:Dependencies`
-section.
-.. _ref-bitbake-tasklist:
-The Task List
-=============
-Based on the generated list of providers and the dependency information,
-BitBake can now calculate exactly what tasks it needs to run and in what
-order it needs to run them. The
-:ref:`bitbake-user-manual/bitbake-user-manual-execution:executing tasks`
-section has more information on how BitBake chooses which task to
-execute next.
-The build now starts with BitBake forking off threads up to the limit
-set in the :term:`BB_NUMBER_THREADS`
-variable. BitBake continues to fork threads as long as there are tasks
-ready to run, those tasks have all their dependencies met, and the
-thread threshold has not been exceeded.
-It is worth noting that you can greatly speed up the build time by
-properly setting the :term:`BB_NUMBER_THREADS` variable.
-As each task completes, a timestamp is written to the directory
-specified by the :term:`STAMP` variable. On subsequent
-runs, BitBake looks in the build directory within ``tmp/stamps`` and
-does not rerun tasks that are already completed unless a timestamp is
-found to be invalid. Currently, invalid timestamps are only considered
-on a per recipe file basis. So, for example, if the configure stamp has
-a timestamp greater than the compile timestamp for a given target, then
-the compile task would rerun. Running the compile task again, however,
-has no effect on other providers that depend on that target.
-The exact format of the stamps is partly configurable. In modern
-versions of BitBake, a hash is appended to the stamp so that if the
-configuration changes, the stamp becomes invalid and the task is
-automatically rerun. This hash, or signature used, is governed by the
-signature policy that is configured (see the
-:ref:`bitbake-user-manual/bitbake-user-manual-execution:checksums (signatures)`
-section for information). It is also
-possible to append extra metadata to the stamp using the
-``[stamp-extra-info]`` task flag. For example, OpenEmbedded uses this
-flag to make some tasks machine-specific.
-.. note::
-   Some tasks are marked as "nostamp" tasks. No timestamp file is
-   created when these tasks are run. Consequently, "nostamp" tasks are
-   always rerun.
-For more information on tasks, see the
-:ref:`bitbake-user-manual/bitbake-user-manual-metadata:tasks` section.
-Executing Tasks
-===============
-Tasks can be either a shell task or a Python task. For shell tasks,
-BitBake writes a shell script to
-``${``\ :term:`T`\ ``}/run.do_taskname.pid`` and then
-executes the script. The generated shell script contains all the
-exported variables, and the shell functions with all variables expanded.
-Output from the shell script goes to the file
-``${``\ :term:`T`\ ``}/log.do_taskname.pid``. Looking at the expanded shell functions in
-the run file and the output in the log files is a useful debugging
-technique.
-For Python tasks, BitBake executes the task internally and logs
-information to the controlling terminal. Future versions of BitBake will
-write the functions to files similar to the way shell tasks are handled.
-Logging will be handled in a way similar to shell tasks as well.
-The order in which BitBake runs the tasks is controlled by its task
-scheduler. It is possible to configure the scheduler and define custom
-implementations for specific use cases. For more information, see these
-variables that control the behavior:
-  :term:`BB_SCHEDULER`
-  :term:`BB_SCHEDULERS`
-It is possible to have functions run before and after a task's main
-function. This is done using the ``[prefuncs]`` and ``[postfuncs]``
-flags of the task that lists the functions to run.
-.. _checksums:
-Checksums (Signatures)
-======================
-A checksum is a unique signature of a task's inputs. The signature of a
-task can be used to determine if a task needs to be run. Because it is a
-change in a task's inputs that triggers running the task, BitBake needs
-to detect all the inputs to a given task. For shell tasks, this turns
-out to be fairly easy because BitBake generates a "run" shell script for
-each task and it is possible to create a checksum that gives you a good
-idea of when the task's data changes.
-To complicate the problem, some things should not be included in the
-checksum. First, there is the actual specific build path of a given task
- the working directory. It does not matter if the working directory
-changes because it should not affect the output for target packages. The
-simplistic approach for excluding the working directory is to set it to
-some fixed value and create the checksum for the "run" script. BitBake
-goes one step better and uses the
-:term:`BB_BASEHASH_IGNORE_VARS` variable
-to define a list of variables that should never be included when
-generating the signatures.
-Another problem results from the "run" scripts containing functions that
-might or might not get called. The incremental build solution contains
-code that figures out dependencies between shell functions. This code is
-used to prune the "run" scripts down to the minimum set, thereby
-alleviating this problem and making the "run" scripts much more readable
-as a bonus.
-So far we have solutions for shell scripts. What about Python tasks? The
-same approach applies even though these tasks are more difficult. The
-process needs to figure out what variables a Python function accesses
-and what functions it calls. Again, the incremental build solution
-contains code that first figures out the variable and function
-dependencies, and then creates a checksum for the data used as the input
-to the task.
-Like the working directory case, situations exist where dependencies
-should be ignored. For these cases, you can instruct the build process
-to ignore a dependency by using a line like the following::
-  PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
-This example ensures that the
-``PACKAGE_ARCHS`` variable does not depend on the value of ``MACHINE``,
-even if it does reference it.
-Equally, there are cases where we need to add dependencies BitBake is
-not able to find. You can accomplish this by using a line like the
-following::
-  PACKAGE_ARCHS[vardeps] = "MACHINE"
-This example explicitly
-adds the ``MACHINE`` variable as a dependency for ``PACKAGE_ARCHS``.
-Consider a case with in-line Python, for example, where BitBake is not
-able to figure out dependencies. When running in debug mode (i.e. using
-``-DDD``), BitBake produces output when it discovers something for which
-it cannot figure out dependencies.
-Thus far, this section has limited discussion to the direct inputs into
-a task. Information based on direct inputs is referred to as the
-"basehash" in the code. However, there is still the question of a task's
-indirect inputs --- the things that were already built and present in the
-build directory. The checksum (or signature) for a particular task needs
-to add the hashes of all the tasks on which the particular task depends.
-Choosing which dependencies to add is a policy decision. However, the
-effect is to generate a master checksum that combines the basehash and
-the hashes of the task's dependencies.
-At the code level, there are a variety of ways both the basehash and the
-dependent task hashes can be influenced. Within the BitBake
-configuration file, we can give BitBake some extra information to help
-it construct the basehash. The following statement effectively results
-in a list of global variable dependency excludes --- variables never
-included in any checksum. This example uses variables from OpenEmbedded
-to help illustrate the concept::
-   BB_BASEHASH_IGNORE_VARS ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
-       SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL \
-       USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
-       PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
-       CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
-The previous example excludes the work directory, which is part of
-``TMPDIR``.
-The rules for deciding which hashes of dependent tasks to include
-through dependency chains are more complex and are generally
-accomplished with a Python function. The code in
-``meta/lib/oe/sstatesig.py`` shows two examples of this and also
-illustrates how you can insert your own policy into the system if so
-desired. This file defines the basic signature generator
-OpenEmbedded-Core uses: "OEBasicHash". By default, there
-is a dummy "noop" signature handler enabled in BitBake. This means that
-behavior is unchanged from previous versions. ``OE-Core`` uses the
-"OEBasicHash" signature handler by default through this setting in the
-``bitbake.conf`` file::
-  BB_SIGNATURE_HANDLER ?= "OEBasicHash"
-The main feature of the "OEBasicHash" :term:`BB_SIGNATURE_HANDLER` is that
-it adds the task hash to the stamp files. Thanks to this, any metadata
-change will change the task hash, automatically causing the task to be run
-again. This removes the need to bump :term:`PR` values, and changes to
-metadata automatically ripple across the build.
-It is also worth noting that the end result of signature
-generators is to make some dependency and hash information available to
-the build. This information includes:
-  ``BB_BASEHASH_task-``\ *taskname*: The base hashes for each task in the
-   recipe.
-  ``BB_BASEHASH_``\ *filename:taskname*: The base hashes for each
-   dependent task.
-  :term:`BB_TASKHASH`: The hash of the currently running task.
-It is worth noting that BitBake's "-S" option lets you debug BitBake's
-processing of signatures. The options passed to -S allow different
-debugging modes to be used, either using BitBake's own debug functions
-or possibly those defined in the metadata/signature handler itself. The
-simplest parameter to pass is "none", which causes a set of signature
-information to be written out into ``STAMPS_DIR`` corresponding to the
-targets specified. The other currently available parameter is
-"printdiff", which causes BitBake to try to establish the most recent
-signature match it can (e.g. in the sstate cache) and then run
-compare the matched signatures to determine the stamps and delta
-where these two stamp trees diverge. This can be used to determine why
-tasks need to be re-run in situations where that is not expected.
-.. note::
-   It is likely that future versions of BitBake will provide other
-   signature handlers triggered through additional "-S" parameters.
-You can find more information on checksum metadata in the
-:ref:`bitbake-user-manual/bitbake-user-manual-metadata:task checksums and setscene`
-section.
-Setscene
-========
-The setscene process enables BitBake to handle "pre-built" artifacts.
-The ability to handle and reuse these artifacts allows BitBake the
-luxury of not having to build something from scratch every time.
-Instead, BitBake can use, when possible, existing build artifacts.
-BitBake needs to have reliable data indicating whether or not an
-artifact is compatible. Signatures, described in the previous section,
-provide an ideal way of representing whether an artifact is compatible.
-If a signature is the same, an object can be reused.
-If an object can be reused, the problem then becomes how to replace a
-given task or set of tasks with the pre-built artifact. BitBake solves
-the problem with the "setscene" process.
-When BitBake is asked to build a given target, before building anything,
-it first asks whether cached information is available for any of the
-targets it's building, or any of the intermediate targets. If cached
-information is available, BitBake uses this information instead of
-running the main tasks.
-BitBake first calls the function defined by the
-:term:`BB_HASHCHECK_FUNCTION` variable
-with a list of tasks and corresponding hashes it wants to build. This
-function is designed to be fast and returns a list of the tasks for
-which it believes in can obtain artifacts.
-Next, for each of the tasks that were returned as possibilities, BitBake
-executes a setscene version of the task that the possible artifact
-covers. Setscene versions of a task have the string "_setscene" appended
-to the task name. So, for example, the task with the name ``xxx`` has a
-setscene task named ``xxx_setscene``. The setscene version of the task
-executes and provides the necessary artifacts returning either success
-or failure.
-As previously mentioned, an artifact can cover more than one task. For
-example, it is pointless to obtain a compiler if you already have the
-compiled binary. To handle this, BitBake calls the
-:term:`BB_SETSCENE_DEPVALID` function for
-each successful setscene task to know whether or not it needs to obtain
-the dependencies of that task.
-You can find more information on setscene metadata in the
-:ref:`bitbake-user-manual/bitbake-user-manual-metadata:task checksums and setscene`
-section.
-Logging
-=======
-In addition to the standard command line option to control how verbose
-builds are when execute, bitbake also supports user defined
-configuration of the `Python
-logging <https://docs.python.org/3/library/logging.html>`__ facilities
-through the :term:`BB_LOGCONFIG` variable. This
-variable defines a JSON or YAML `logging
-configuration <https://docs.python.org/3/library/logging.config.html>`__
-that will be intelligently merged into the default configuration. The
-logging configuration is merged using the following rules:
-  The user defined configuration will completely replace the default
-   configuration if top level key ``bitbake_merge`` is set to the value
-   ``False``. In this case, all other rules are ignored.
-  The user configuration must have a top level ``version`` which must
-   match the value of the default configuration.
-  Any keys defined in the ``handlers``, ``formatters``, or ``filters``,
-   will be merged into the same section in the default configuration,
-   with the user specified keys taking replacing a default one if there
-   is a conflict. In practice, this means that if both the default
-   configuration and user configuration specify a handler named
-   ``myhandler``, the user defined one will replace the default. To
-   prevent the user from inadvertently replacing a default handler,
-   formatter, or filter, all of the default ones are named with a prefix
-   of "``BitBake.``"
-  If a logger is defined by the user with the key ``bitbake_merge`` set
-   to ``False``, that logger will be completely replaced by user
-   configuration. In this case, no other rules will apply to that
-   logger.
-  All user defined ``filter`` and ``handlers`` properties for a given
-   logger will be merged with corresponding properties from the default
-   logger. For example, if the user configuration adds a filter called
-   ``myFilter`` to the ``BitBake.SigGen``, and the default configuration
-   adds a filter called ``BitBake.defaultFilter``, both filters will be
-   applied to the logger
-As a first example, you can create a ``hashequiv.json`` user logging
-configuration file to log all Hash Equivalence related messages of ``VERBOSE``
-or higher priority to a file called ``hashequiv.log``::
-   {
-       "version": 1,
-       "handlers": {
-           "autobuilderlog": {
-               "class": "logging.FileHandler",
-               "formatter": "logfileFormatter",
-               "level": "DEBUG",
-               "filename": "hashequiv.log",
-               "mode": "w"
-           }
-       },
-       "formatters": {
-               "logfileFormatter": {
-                   "format": "%(name)s: %(levelname)s: %(message)s"
-               }
-       },
-       "loggers": {
-           "BitBake.SigGen.HashEquiv": {
-               "level": "VERBOSE",
-               "handlers": ["autobuilderlog"]
-           },
-           "BitBake.RunQueue.HashEquiv": {
-               "level": "VERBOSE",
-               "handlers": ["autobuilderlog"]
-           }
-       }
-   }
-Then set the :term:`BB_LOGCONFIG` variable in ``conf/local.conf``::
-   BB_LOGCONFIG = "hashequiv.json"
-Another example is this ``warn.json`` file to log all ``WARNING`` and
-higher priority messages to a ``warn.log`` file::
-  {
-      "version": 1,
-      "formatters": {
-          "warnlogFormatter": {
-              "()": "bb.msg.BBLogFormatter",
-              "format": "%(levelname)s: %(message)s"
-          }
-      },
-      "handlers": {
-          "warnlog": {
-              "class": "logging.FileHandler",
-              "formatter": "warnlogFormatter",
-              "level": "WARNING",
-              "filename": "warn.log"
-          }
-      },
-      "loggers": {
-          "BitBake": {
-              "handlers": ["warnlog"]
-          }
-      },
-      "@disable_existing_loggers": false
-  }
-Note that BitBake's helper classes for structured logging are implemented in
-``lib/bb/msg.py``.
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
deleted file mode 100644
index f357765b77..0000000000
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-fetching.rst
+++ /dev/null
@@ -1,846 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-=====================
-File Download Support
-=====================
-|
-BitBake's fetch module is a standalone piece of library code that deals
-with the intricacies of downloading source code and files from remote
-systems. Fetching source code is one of the cornerstones of building
-software. As such, this module forms an important part of BitBake.
-The current fetch module is called "fetch2" and refers to the fact that
-it is the second major version of the API. The original version is
-obsolete and has been removed from the codebase. Thus, in all cases,
-"fetch" refers to "fetch2" in this manual.
-The Download (Fetch)
-====================
-BitBake takes several steps when fetching source code or files. The
-fetcher codebase deals with two distinct processes in order: obtaining
-the files from somewhere (cached or otherwise) and then unpacking those
-files into a specific location and perhaps in a specific way. Getting
-and unpacking the files is often optionally followed by patching.
-Patching, however, is not covered by this module.
-The code to execute the first part of this process, a fetch, looks
-something like the following::
-   src_uri = (d.getVar('SRC_URI') or "").split()
-   fetcher = bb.fetch2.Fetch(src_uri, d)
-   fetcher.download()
-This code sets up an instance of the fetch class. The instance uses a
-space-separated list of URLs from the :term:`SRC_URI`
-variable and then calls the ``download`` method to download the files.
-The instantiation of the fetch class is usually followed by::
-   rootdir = l.getVar('UNPACKDIR')
-   fetcher.unpack(rootdir)
-This code unpacks the downloaded files to the specified by ``UNPACKDIR``.
-.. note::
-   For convenience, the naming in these examples matches the variables
-   used by OpenEmbedded. If you want to see the above code in action,
-   examine the OpenEmbedded class file ``base.bbclass``
-   .
-The :term:`SRC_URI` and ``UNPACKDIR`` variables are not hardcoded into the
-fetcher, since those fetcher methods can be (and are) called with
-different variable names. In OpenEmbedded for example, the shared state
-(sstate) code uses the fetch module to fetch the sstate files.
-When the ``download()`` method is called, BitBake tries to resolve the
-URLs by looking for source files in a specific search order:
-  *Pre-mirror Sites:* BitBake first uses pre-mirrors to try and find
-   source files. These locations are defined using the
-   :term:`PREMIRRORS` variable.
-  *Source URI:* If pre-mirrors fail, BitBake uses the original URL (e.g
-   from :term:`SRC_URI`).
-  *Mirror Sites:* If fetch failures occur, BitBake next uses mirror
-   locations as defined by the :term:`MIRRORS` variable.
-For each URL passed to the fetcher, the fetcher calls the submodule that
-handles that particular URL type. This behavior can be the source of
-some confusion when you are providing URLs for the :term:`SRC_URI` variable.
-Consider the following two URLs::
-   https://git.yoctoproject.org/git/poky;protocol=git
-   git://git.yoctoproject.org/git/poky;protocol=http
-In the former case, the URL is passed to the ``wget`` fetcher, which does not
-understand "git". Therefore, the latter case is the correct form since the Git
-fetcher does know how to use HTTP as a transport.
-Here are some examples that show commonly used mirror definitions::
-   PREMIRRORS ?= "\
-      bzr://.*/.\*  http://somemirror.org/sources/ \
-      cvs://.*/.\*  http://somemirror.org/sources/ \
-      git://.*/.\*  http://somemirror.org/sources/ \
-      hg://.*/.\*   http://somemirror.org/sources/ \
-      osc://.*/.\*  http://somemirror.org/sources/ \
-      p4://.*/.\*   http://somemirror.org/sources/ \
-     svn://.*/.\*   http://somemirror.org/sources/"
-   MIRRORS =+ "\
-      ftp://.*/.\*   http://somemirror.org/sources/ \
-      http://.*/.\*  http://somemirror.org/sources/ \
-      https://.*/.\* http://somemirror.org/sources/"
-It is useful to note that BitBake
-supports cross-URLs. It is possible to mirror a Git repository on an
-HTTP server as a tarball. This is what the ``git://`` mapping in the
-previous example does.
-Since network accesses are slow, BitBake maintains a cache of files
-downloaded from the network. Any source files that are not local (i.e.
-downloaded from the Internet) are placed into the download directory,
-which is specified by the :term:`DL_DIR` variable.
-File integrity is of key importance for reproducing builds. For
-non-local archive downloads, the fetcher code can verify SHA-256 and MD5
-checksums to ensure the archives have been downloaded correctly. You can
-specify these checksums by using the :term:`SRC_URI` variable with the
-appropriate varflags as follows::
-   SRC_URI[md5sum] = "value"
-   SRC_URI[sha256sum] = "value"
-You can also specify the checksums as
-parameters on the :term:`SRC_URI` as shown below::
-  SRC_URI = "http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d"
-If multiple URIs exist, you can specify the checksums either directly as
-in the previous example, or you can name the URLs. The following syntax
-shows how you name the URIs::
-   SRC_URI = "http://example.com/foobar.tar.bz2;name=foo"
-   SRC_URI[foo.md5sum] = 4a8e0f237e961fd7785d19d07fdb994d
-After a file has been downloaded and
-has had its checksum checked, a ".done" stamp is placed in :term:`DL_DIR`.
-BitBake uses this stamp during subsequent builds to avoid downloading or
-comparing a checksum for the file again.
-.. note::
-   It is assumed that local storage is safe from data corruption. If
-   this were not the case, there would be bigger issues to worry about.
-If :term:`BB_STRICT_CHECKSUM` is set, any
-download without a checksum triggers an error message. The
-:term:`BB_NO_NETWORK` variable can be used to
-make any attempted network access a fatal error, which is useful for
-checking that mirrors are complete as well as other things.
-If :term:`BB_CHECK_SSL_CERTS` is set to ``0`` then SSL certificate checking will
-be disabled. This variable defaults to ``1`` so SSL certificates are normally
-checked.
-.. _bb-the-unpack:
-The Unpack
-==========
-The unpack process usually immediately follows the download. For all
-URLs except Git URLs, BitBake uses the common ``unpack`` method.
-A number of parameters exist that you can specify within the URL to
-govern the behavior of the unpack stage:
-  *unpack:* Controls whether the URL components are unpacked. If set to
-   "1", which is the default, the components are unpacked. If set to
-   "0", the unpack stage leaves the file alone. This parameter is useful
-   when you want an archive to be copied in and not be unpacked.
-  *dos:* Applies to ``.zip`` and ``.jar`` files and specifies whether
-   to use DOS line ending conversion on text files.
-  *striplevel:* Strip specified number of leading components (levels)
-   from file names on extraction
-  *subdir:* Unpacks the specific URL to the specified subdirectory
-   within the root directory.
-The unpack call automatically decompresses and extracts files with ".Z",
-".z", ".gz", ".xz", ".zip", ".jar", ".ipk", ".rpm". ".srpm", ".deb" and
-".bz2" extensions as well as various combinations of tarball extensions.
-As mentioned, the Git fetcher has its own unpack method that is
-optimized to work with Git trees. Basically, this method works by
-cloning the tree into the final directory. The process is completed
-using references so that there is only one central copy of the Git
-metadata needed.
-.. _bb-fetchers:
-Fetchers
-========
-As mentioned earlier, the URL prefix determines which fetcher submodule
-BitBake uses. Each submodule can support different URL parameters, which
-are described in the following sections.
-.. _local-file-fetcher:
-Local file fetcher (``file://``)
--------------------------------
-This submodule handles URLs that begin with ``file://``. The filename
-you specify within the URL can be either an absolute or relative path to
-a file. If the filename is relative, the contents of the
-:term:`FILESPATH` variable is used in the same way
-``PATH`` is used to find executables. If the file cannot be found, it is
-assumed that it is available in :term:`DL_DIR` by the
-time the ``download()`` method is called.
-If you specify a directory, the entire directory is unpacked.
-Here are a couple of example URLs, the first relative and the second
-absolute::
-   SRC_URI = "file://relativefile.patch"
-   SRC_URI = "file:///Users/ich/very_important_software"
-.. _http-ftp-fetcher:
-HTTP/FTP wget fetcher (``http://``, ``ftp://``, ``https://``)
-------------------------------------------------------------
-This fetcher obtains files from web and FTP servers. Internally, the
-fetcher uses the wget utility.
-The executable and parameters used are specified by the
-``FETCHCMD_wget`` variable, which defaults to sensible values. The
-fetcher supports a parameter "downloadfilename" that allows the name of
-the downloaded file to be specified. Specifying the name of the
-downloaded file is useful for avoiding collisions in
-:term:`DL_DIR` when dealing with multiple files that
-have the same name.
-If a username and password are specified in the ``SRC_URI``, a Basic
-Authorization header will be added to each request, including across redirects.
-To instead limit the Authorization header to the first request, add
-"redirectauth=0" to the list of parameters.
-Some example URLs are as follows::
-   SRC_URI = "http://oe.handhelds.org/not_there.aac"
-   SRC_URI = "ftp://oe.handhelds.org/not_there_as_well.aac"
-   SRC_URI = "ftp://you@oe.handhelds.org/home/you/secret.plan"
-.. note::
-   Because URL parameters are delimited by semi-colons, this can
-   introduce ambiguity when parsing URLs that also contain semi-colons,
-   for example::
-           SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git;a=snapshot;h=a5dd47"
-   Such URLs should should be modified by replacing semi-colons with '&'
-   characters::
-           SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47"
-   In most cases this should work. Treating semi-colons and '&' in
-   queries identically is recommended by the World Wide Web Consortium
-   (W3C). Note that due to the nature of the URL, you may have to
-   specify the name of the downloaded file as well::
-           SRC_URI = "http://abc123.org/git/?p=gcc/gcc.git&a=snapshot&h=a5dd47;downloadfilename=myfile.bz2"
-.. _cvs-fetcher:
-CVS fetcher (``(cvs://``)
-------------------------
-This submodule handles checking out files from the CVS version control
-system. You can configure it using a number of different variables:
-  :term:`FETCHCMD_cvs <FETCHCMD>`: The name of the executable to use when running
-   the ``cvs`` command. This name is usually "cvs".
-  :term:`SRCDATE`: The date to use when fetching the CVS source code. A
-   special value of "now" causes the checkout to be updated on every
-   build.
-  :term:`CVSDIR`: Specifies where a temporary
-   checkout is saved. The location is often ``DL_DIR/cvs``.
-  CVS_PROXY_HOST: The name to use as a "proxy=" parameter to the
-   ``cvs`` command.
-  CVS_PROXY_PORT: The port number to use as a "proxyport="
-   parameter to the ``cvs`` command.
-As well as the standard username and password URL syntax, you can also
-configure the fetcher with various URL parameters:
-The supported parameters are as follows:
-  *"method":* The protocol over which to communicate with the CVS
-   server. By default, this protocol is "pserver". If "method" is set to
-   "ext", BitBake examines the "rsh" parameter and sets ``CVS_RSH``. You
-   can use "dir" for local directories.
-  *"module":* Specifies the module to check out. You must supply this
-   parameter.
-  *"tag":* Describes which CVS TAG should be used for the checkout. By
-   default, the TAG is empty.
-  *"date":* Specifies a date. If no "date" is specified, the
-   :term:`SRCDATE` of the configuration is used to
-   checkout a specific date. The special value of "now" causes the
-   checkout to be updated on every build.
-  *"localdir":* Used to rename the module. Effectively, you are
-   renaming the output directory to which the module is unpacked. You
-   are forcing the module into a special directory relative to
-   :term:`CVSDIR`.
-  *"rsh":* Used in conjunction with the "method" parameter.
-  *"scmdata":* Causes the CVS metadata to be maintained in the tarball
-   the fetcher creates when set to "keep". The tarball is expanded into
-   the work directory. By default, the CVS metadata is removed.
-  *"fullpath":* Controls whether the resulting checkout is at the
-   module level, which is the default, or is at deeper paths.
-  *"norecurse":* Causes the fetcher to only checkout the specified
-   directory with no recurse into any subdirectories.
-  *"port":* The port to which the CVS server connects.
-Some example URLs are as follows::
-   SRC_URI = "cvs://CVSROOT;module=mymodule;tag=some-version;method=ext"
-   SRC_URI = "cvs://CVSROOT;module=mymodule;date=20060126;localdir=usethat"
-.. _svn-fetcher:
-Subversion (SVN) Fetcher (``svn://``)
-------------------------------------
-This fetcher submodule fetches code from the Subversion source control
-system. The executable used is specified by ``FETCHCMD_svn``, which
-defaults to "svn". The fetcher's temporary working directory is set by
-:term:`SVNDIR`, which is usually ``DL_DIR/svn``.
-The supported parameters are as follows:
-  *"module":* The name of the svn module to checkout. You must provide
-   this parameter. You can think of this parameter as the top-level
-   directory of the repository data you want.
-  *"path_spec":* A specific directory in which to checkout the
-   specified svn module.
-  *"protocol":* The protocol to use, which defaults to "svn". If
-   "protocol" is set to "svn+ssh", the "ssh" parameter is also used.
-  *"rev":* The revision of the source code to checkout.
-  *"scmdata":* Causes the ".svn" directories to be available during
-   compile-time when set to "keep". By default, these directories are
-   removed.
-  *"ssh":* An optional parameter used when "protocol" is set to
-   "svn+ssh". You can use this parameter to specify the ssh program used
-   by svn.
-  *"transportuser":* When required, sets the username for the
-   transport. By default, this parameter is empty. The transport
-   username is different than the username used in the main URL, which
-   is passed to the subversion command.
-Following are three examples using svn::
-   SRC_URI = "svn://myrepos/proj1;module=vip;protocol=http;rev=667"
-   SRC_URI = "svn://myrepos/proj1;module=opie;protocol=svn+ssh"
-   SRC_URI = "svn://myrepos/proj1;module=trunk;protocol=http;path_spec=${MY_DIR}/proj1"
-.. _git-fetcher:
-Git Fetcher (``git://``)
------------------------
-This fetcher submodule fetches code from the Git source control system.
-The fetcher works by creating a bare clone of the remote into
-:term:`GITDIR`, which is usually ``DL_DIR/git2``. This
-bare clone is then cloned into the work directory during the unpack
-stage when a specific tree is checked out. This is done using alternates
-and by reference to minimize the amount of duplicate data on the disk
-and make the unpack process fast. The executable used can be set with
-``FETCHCMD_git``.
-This fetcher supports the following parameters:
-  *"protocol":* The protocol used to fetch the files. The default is
-   "git" when a hostname is set. If a hostname is not set, the Git
-   protocol is "file". You can also use "http", "https", "ssh" and
-   "rsync".
-   .. note::
-     When ``protocol`` is "ssh", the URL expected in :term:`SRC_URI` differs
-     from the one that is typically passed to ``git clone`` command and provided
-     by the Git server to fetch from. For example, the URL returned by GitLab
-     server for ``mesa`` when cloning over SSH is
-     ``git@gitlab.freedesktop.org:mesa/mesa.git``, however the expected URL in
-     :term:`SRC_URI` is the following::
-       SRC_URI = "git://git@gitlab.freedesktop.org/mesa/mesa.git;branch=main;protocol=ssh;..."
-     Note the ``:`` character changed for a ``/`` before the path to the project.
-  *"nocheckout":* Tells the fetcher to not checkout source code when
-   unpacking when set to "1". Set this option for the URL where there is
-   a custom routine to checkout code. The default is "0".
-  *"rebaseable":* Indicates that the upstream Git repository can be
-   rebased. You should set this parameter to "1" if revisions can become
-   detached from branches. In this case, the source mirror tarball is
-   done per revision, which has a loss of efficiency. Rebasing the
-   upstream Git repository could cause the current revision to disappear
-   from the upstream repository. This option reminds the fetcher to
-   preserve the local cache carefully for future use. The default value
-   for this parameter is "0".
-  *"nobranch":* Tells the fetcher to not check the SHA validation for
-   the branch when set to "1". The default is "0". Set this option for
-   the recipe that refers to the commit that is valid for any namespace
-   (branch, tag, ...) instead of the branch.
-  *"bareclone":* Tells the fetcher to clone a bare clone into the
-   destination directory without checking out a working tree. Only the
-   raw Git metadata is provided. This parameter implies the "nocheckout"
-   parameter as well.
-  *"branch":* The branch(es) of the Git tree to clone. Unless
-   "nobranch" is set to "1", this is a mandatory parameter. The number of
-   branch parameters must match the number of name parameters.
-  *"rev":* The revision to use for the checkout. If :term:`SRCREV` is also set,
-   this parameter must match its value.
-  *"tag":* Specifies a tag to use when fetching. To correctly resolve
-   tags, BitBake must access the network. If a ``rev`` parameter or
-   :term:`SRCREV` is also specified, network access is not necessary to resolve
-   the tag and instead, it is verified that they both resolve to the same commit
-   SHA at unpack time.  The ``tag`` parameter is optional, but strongly
-   recommended if the checked out revision is a tag.
-  *"subpath":* Limits the checkout to a specific subpath of the tree.
-   By default, the whole tree is checked out.
-  *"destsuffix":* The name of the path in which to place the checkout.
-   By default, the path is ``git/``.
-  *"usehead":* Enables local ``git://`` URLs to use the current branch
-   HEAD as the revision for use with ``AUTOREV``. The "usehead"
-   parameter implies no branch and only works when the transfer protocol
-   is ``file://``.
-Here are some example URLs::
-   SRC_URI = "git://github.com/fronteed/icheck.git;protocol=https;branch=${PV};tag=${PV}"
-   SRC_URI = "git://github.com/asciidoc/asciidoc-py;protocol=https;branch=main"
-   SRC_URI = "git://git@gitlab.freedesktop.org/mesa/mesa.git;branch=main;protocol=ssh;..."
-.. note::
-   Specifying passwords directly in ``git://`` urls is not supported.
-   There are several reasons: :term:`SRC_URI` is often written out to logs and
-   other places, and that could easily leak passwords; it is also all too
-   easy to share metadata without removing passwords. SSH keys, ``~/.netrc``
-   and ``~/.ssh/config`` files can be used as alternatives.
-Using tags with the git fetcher may cause surprising behaviour. Bitbake needs to
-resolve the tag to a specific revision and to do that, it has to connect to and use
-the upstream repository. This is because the revision the tags point at can change and
-we've seen cases of this happening in well known public repositories. This can mean
-many more network connections than expected and recipes may be reparsed at every build.
-Source mirrors will also be bypassed as the upstream repository is the only source
-of truth to resolve the revision accurately. For these reasons, whilst the fetcher
-can support tags, we recommend being specific about revisions in recipes.
-.. _gitsm-fetcher:
-Git Submodule Fetcher (``gitsm://``)
------------------------------------
-This fetcher submodule inherits from the :ref:`Git
-fetcher<bitbake-user-manual/bitbake-user-manual-fetching:git fetcher
-(\`\`git://\`\`)>` and extends that fetcher's behavior by fetching a
-repository's submodules. :term:`SRC_URI` is passed to the Git fetcher as
-described in the :ref:`bitbake-user-manual/bitbake-user-manual-fetching:git
-fetcher (\`\`git://\`\`)` section.
-.. note::
-   You must clean a recipe when switching between '``git://``' and
-   '``gitsm://``' URLs.
-   The Git Submodules fetcher is not a complete fetcher implementation.
-   The fetcher has known issues where it does not use the normal source
-   mirroring infrastructure properly. Further, the submodule sources it
-   fetches are not visible to the licensing and source archiving
-   infrastructures.
-.. _clearcase-fetcher:
-ClearCase Fetcher (``ccrc://``)
-------------------------------
-This fetcher submodule fetches code from a
-`ClearCase <http://en.wikipedia.org/wiki/Rational_ClearCase>`__
-repository.
-To use this fetcher, make sure your recipe has proper
-:term:`SRC_URI`, :term:`SRCREV`, and
-:term:`PV` settings. Here is an example::
-   SRC_URI = "ccrc://cc.example.org/ccrc;vob=/example_vob;module=/example_module"
-   SRCREV = "EXAMPLE_CLEARCASE_TAG"
-   PV = "${@d.getVar("SRCREV", False).replace("/", "+")}"
-The fetcher uses the ``rcleartool`` or
-``cleartool`` remote client, depending on which one is available.
-Following are options for the :term:`SRC_URI` statement:
-  *vob*: The name, which must include the prepending "/" character,
-   of the ClearCase VOB. This option is required.
-  *module*: The module, which must include the prepending "/"
-   character, in the selected VOB.
-   .. note::
-      The module and vob options are combined to create the load rule in the
-      view config spec. As an example, consider the vob and module values from
-      the SRC_URI statement at the start of this section. Combining those values
-      results in the following::
-         load /example_vob/example_module
-  *proto*: The protocol, which can be either ``http`` or ``https``.
-By default, the fetcher creates a configuration specification. If you
-want this specification written to an area other than the default, use
-the ``CCASE_CUSTOM_CONFIG_SPEC`` variable in your recipe to define where
-the specification is written.
-.. note::
-   the SRCREV loses its functionality if you specify this variable. However,
-   SRCREV is still used to label the archive after a fetch even though it does
-   not define what is fetched.
-Here are a couple of other behaviors worth mentioning:
-  When using ``cleartool``, the login of ``cleartool`` is handled by
-   the system. The login require no special steps.
-  In order to use ``rcleartool`` with authenticated users, an
-   "rcleartool login" is necessary before using the fetcher.
-.. _perforce-fetcher:
-Perforce Fetcher (``p4://``)
----------------------------
-This fetcher submodule fetches code from the
-`Perforce <https://www.perforce.com/>`__ source control system. The
-executable used is specified by ``FETCHCMD_p4``, which defaults to "p4".
-The fetcher's temporary working directory is set by
-:term:`P4DIR`, which defaults to "DL_DIR/p4".
-The fetcher does not make use of a perforce client, instead it
-relies on ``p4 files`` to retrieve a list of
-files and ``p4 print`` to transfer the content
-of those files locally.
-To use this fetcher, make sure your recipe has proper
-:term:`SRC_URI`, :term:`SRCREV`, and
-:term:`PV` values. The p4 executable is able to use the
-config file defined by your system's ``P4CONFIG`` environment variable
-in order to define the Perforce server URL and port, username, and
-password if you do not wish to keep those values in a recipe itself. If
-you choose not to use ``P4CONFIG``, or to explicitly set variables that
-``P4CONFIG`` can contain, you can specify the ``P4PORT`` value, which is
-the server's URL and port number, and you can specify a username and
-password directly in your recipe within :term:`SRC_URI`.
-Here is an example that relies on ``P4CONFIG`` to specify the server URL
-and port, username, and password, and fetches the Head Revision::
-   SRC_URI = "p4://example-depot/main/source/..."
-   SRCREV = "${AUTOREV}"
-   PV = "p4-${SRCPV}"
-   S = "${UNPACKDIR}/p4"
-Here is an example that specifies the server URL and port, username, and
-password, and fetches a Revision based on a Label::
-   P4PORT = "tcp:p4server.example.net:1666"
-   SRC_URI = "p4://user:passwd@example-depot/main/source/..."
-   SRCREV = "release-1.0"
-   PV = "p4-${SRCPV}"
-   S = "${UNPACKDIR}/p4"
-.. note::
-   You should always set S to "${UNPACKDIR}/p4" in your recipe.
-By default, the fetcher strips the depot location from the local file paths. In
-the above example, the content of ``example-depot/main/source/`` will be placed
-in ``${UNPACKDIR}/p4``.  For situations where preserving parts of the remote depot
-paths locally is desirable, the fetcher supports two parameters:
- *"module":*
-    The top-level depot location or directory to fetch. The value of this
-    parameter can also point to a single file within the depot, in which case
-    the local file path will include the module path.
- *"remotepath":*
-    When used with the value "``keep``", the fetcher will mirror the full depot
-    paths locally for the specified location, even in combination with the
-    ``module`` parameter.
-Here is an example use of the the ``module`` parameter::
-   SRC_URI = "p4://user:passwd@example-depot/main;module=source/..."
-In this case, the content of the top-level directory ``source/`` will be fetched
-to ``${P4DIR}``, including the directory itself.  The top-level directory will
-be accesible at ``${P4DIR}/source/``.
-Here is an example use of the the ``remotepath`` parameter::
-   SRC_URI = "p4://user:passwd@example-depot/main;module=source/...;remotepath=keep"
-In this case, the content of the top-level directory ``source/`` will be fetched
-to ``${P4DIR}``, but the complete depot paths will be mirrored locally. The
-top-level directory will be accessible at
-``${P4DIR}/example-depot/main/source/``.
-.. _repo-fetcher:
-Repo Fetcher (``repo://``)
--------------------------
-This fetcher submodule fetches code from ``google-repo`` source control
-system. The fetcher works by initiating and syncing sources of the
-repository into :term:`REPODIR`, which is usually
-``${DL_DIR}/repo``.
-This fetcher supports the following parameters:
-  *"protocol":* Protocol to fetch the repository manifest (default:
-   git).
-  *"branch":* Branch or tag of repository to get (default: master).
-  *"manifest":* Name of the manifest file (default: ``default.xml``).
-Here are some example URLs::
-   SRC_URI = "repo://REPOROOT;protocol=git;branch=some_branch;manifest=my_manifest.xml"
-   SRC_URI = "repo://REPOROOT;protocol=file;branch=some_branch;manifest=my_manifest.xml"
-.. _az-fetcher:
-Az Fetcher (``az://``)
--------------------------
-This submodule fetches data from an
-`Azure Storage account <https://docs.microsoft.com/en-us/azure/storage/>`__ ,
-it inherits its functionality from the HTTP wget fetcher, but modifies its
-behavior to accomodate the usage of a
-`Shared Access Signature (SAS) <https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview>`__
-for non-public data.
-Such functionality is set by the variable:
-  :term:`AZ_SAS`: The Azure Storage Shared Access Signature provides secure
-   delegate access to resources, if this variable is set, the Az Fetcher will
-   use it when fetching artifacts from the cloud.
-You can specify the AZ_SAS variable prefixed with a ? as shown below::
-   AZ_SAS = "?se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>"
-Here is an example URL::
-   SRC_URI = "az://<azure-storage-account>.blob.core.windows.net/<foo_container>/<bar_file>"
-It can also be used when setting mirrors definitions using the :term:`PREMIRRORS` variable.
-.. _gcp-fetcher:
-GCP Fetcher (``gs://``)
--------------------------
-This submodule fetches data from a
-`Google Cloud Storage Bucket <https://cloud.google.com/storage/docs/buckets>`__.
-It uses the `Google Cloud Storage Python Client <https://cloud.google.com/python/docs/reference/storage/latest>`__
-to check the status of objects in the bucket and download them.
-The use of the Python client makes it substantially faster than using command
-line tools such as gsutil.
-The fetcher requires the Google Cloud Storage Python Client to be installed, along
-with the gsutil tool.
-The fetcher requires that the machine has valid credentials for accessing the
-chosen bucket. Instructions for authentication can be found in the
-`Google Cloud documentation <https://cloud.google.com/docs/authentication/provide-credentials-adc#local-dev>`__.
-If it used from the OpenEmbedded build system, the fetcher can be used for
-fetching sstate artifacts from a GCS bucket by specifying the
-``SSTATE_MIRRORS`` variable as shown below::
-   SSTATE_MIRRORS ?= "\
-       file://.* gs://<bucket name>/PATH \
-   "
-The fetcher can also be used in recipes::
-   SRC_URI = "gs://<bucket name>/<foo_container>/<bar_file>"
-However, the checksum of the file should be also be provided::
-   SRC_URI[sha256sum] = "<sha256 string>"
-.. _crate-fetcher:
-Crate Fetcher (``crate://``)
----------------------------
-This submodule fetches code for
-`Rust language "crates" <https://doc.rust-lang.org/reference/glossary.html?highlight=crate#crate>`__
-corresponding to Rust libraries and programs to compile. Such crates are typically shared
-on https://crates.io/ but this fetcher supports other crate registries too.
-The format for the :term:`SRC_URI` setting must be::
-   SRC_URI = "crate://REGISTRY/NAME/VERSION"
-Here is an example URL::
-   SRC_URI = "crate://crates.io/glob/0.2.11"
-.. _npm-fetcher:
-NPM Fetcher (``npm://``)
------------------------
-This submodule fetches source code from an
-`NPM <https://en.wikipedia.org/wiki/Npm_(software)>`__
-Javascript package registry.
-The format for the :term:`SRC_URI` setting must be::
-   SRC_URI = "npm://some.registry.url;ParameterA=xxx;ParameterB=xxx;..."
-This fetcher supports the following parameters:
-  *"package":* The NPM package name. This is a mandatory parameter.
-  *"version":* The NPM package version. This is a mandatory parameter.
-  *"downloadfilename":* Specifies the filename used when storing the downloaded file.
-  *"destsuffix":* Specifies the directory to use to unpack the package (default: ``npm``).
-Note that NPM fetcher only fetches the package source itself. The dependencies
-can be fetched through the `npmsw-fetcher`_.
-Here is an example URL with both fetchers::
-   SRC_URI = " \
-       npm://registry.npmjs.org/;package=cute-files;version=${PV} \
-       npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
-       "
-See :yocto_docs:`Creating Node Package Manager (NPM) Packages
-</dev-manual/packages.html#creating-node-package-manager-npm-packages>`
-in the Yocto Project manual for details about using
-:yocto_docs:`devtool <https://docs.yoctoproject.org/ref-manual/devtool-reference.html>`
-to automatically create a recipe from an NPM URL.
-.. _npmsw-fetcher:
-NPM shrinkwrap Fetcher (``npmsw://``)
-------------------------------------
-This submodule fetches source code from an
-`NPM shrinkwrap <https://docs.npmjs.com/cli/v8/commands/npm-shrinkwrap>`__
-description file, which lists the dependencies
-of an NPM package while locking their versions.
-The format for the :term:`SRC_URI` setting must be::
-   SRC_URI = "npmsw://some.registry.url;ParameterA=xxx;ParameterB=xxx;..."
-This fetcher supports the following parameters:
-  *"dev":* Set this parameter to ``1`` to install "devDependencies".
-  *"destsuffix":* Specifies the directory to use to unpack the dependencies
-   (``${S}`` by default).
-Note that the shrinkwrap file can also be provided by the recipe for
-the package which has such dependencies, for example::
-   SRC_URI = " \
-       npm://registry.npmjs.org/;package=cute-files;version=${PV} \
-       npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
-       "
-Such a file can automatically be generated using
-:yocto_docs:`devtool <https://docs.yoctoproject.org/ref-manual/devtool-reference.html>`
-as described in the :yocto_docs:`Creating Node Package Manager (NPM) Packages
-</dev-manual/packages.html#creating-node-package-manager-npm-packages>`
-section of the Yocto Project.
-Other Fetchers
--------------
-Fetch submodules also exist for the following:
-  Bazaar (``bzr://``)
-  Mercurial (``hg://``)
-  OSC (``osc://``)
-  S3 (``s3://``)
-  Secure FTP (``sftp://``)
-  Secure Shell (``ssh://``)
-  Trees using Git Annex (``gitannex://``)
-No documentation currently exists for these lesser used fetcher
-submodules. However, you might find the code helpful and readable.
-Auto Revisions
-==============
-We need to document ``AUTOREV`` and :term:`SRCREV_FORMAT` here.
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.rst
deleted file mode 100644
index 654196ca24..0000000000
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.rst
+++ /dev/null
@@ -1,408 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-===================
-Hello World Example
-===================
-BitBake Hello World
-===================
-The simplest example commonly used to demonstrate any new programming
-language or tool is the "`Hello
-World <http://en.wikipedia.org/wiki/Hello_world_program>`__" example.
-This appendix demonstrates, in tutorial form, Hello World within the
-context of BitBake. The tutorial describes how to create a new project
-and the applicable metadata files necessary to allow BitBake to build
-it.
-Obtaining BitBake
-=================
-See the :ref:`bitbake-user-manual/bitbake-user-manual-intro:obtaining bitbake` section for
-information on how to obtain BitBake. Once you have the source code on
-your machine, the BitBake directory appears as follows::
-   $ ls -al
-   total 108
-   drwxr-xr-x  9 fawkh 10000  4096 feb 24 12:10 .
-   drwx------ 36 fawkh 10000  4096 mar  2 17:00 ..
-   -rw-r--r--  1 fawkh 10000   365 feb 24 12:10 AUTHORS
-   drwxr-xr-x  2 fawkh 10000  4096 feb 24 12:10 bin
-   -rw-r--r--  1 fawkh 10000 16501 feb 24 12:10 ChangeLog
-   drwxr-xr-x  2 fawkh 10000  4096 feb 24 12:10 classes
-   drwxr-xr-x  2 fawkh 10000  4096 feb 24 12:10 conf
-   drwxr-xr-x  5 fawkh 10000  4096 feb 24 12:10 contrib
-   drwxr-xr-x  6 fawkh 10000  4096 feb 24 12:10 doc
-   drwxr-xr-x  8 fawkh 10000  4096 mar  2 16:26 .git
-   -rw-r--r--  1 fawkh 10000    31 feb 24 12:10 .gitattributes
-   -rw-r--r--  1 fawkh 10000   392 feb 24 12:10 .gitignore
-   drwxr-xr-x 13 fawkh 10000  4096 feb 24 12:11 lib
-   -rw-r--r--  1 fawkh 10000  1224 feb 24 12:10 LICENSE
-   -rw-r--r--  1 fawkh 10000 15394 feb 24 12:10 LICENSE.GPL-2.0-only
-   -rw-r--r--  1 fawkh 10000  1286 feb 24 12:10 LICENSE.MIT
-   -rw-r--r--  1 fawkh 10000   229 feb 24 12:10 MANIFEST.in
-   -rw-r--r--  1 fawkh 10000  2413 feb 24 12:10 README
-   -rw-r--r--  1 fawkh 10000    43 feb 24 12:10 toaster-requirements.txt
-   -rw-r--r--  1 fawkh 10000  2887 feb 24 12:10 TODO
-At this point, you should have BitBake cloned to a directory that
-matches the previous listing except for dates and user names.
-Setting Up the BitBake Environment
-==================================
-First, you need to be sure that you can run BitBake. Set your working
-directory to where your local BitBake files are and run the following
-command::
-  $ ./bin/bitbake --version
-  BitBake Build Tool Core version 2.3.1
-The console output tells you what version
-you are running.
-The recommended method to run BitBake is from a directory of your
-choice. To be able to run BitBake from any directory, you need to add
-the executable binary to your binary to your shell's environment
-``PATH`` variable. First, look at your current ``PATH`` variable by
-entering the following::
-  $ echo $PATH
-Next, add the directory location
-for the BitBake binary to the ``PATH``. Here is an example that adds the
-``/home/scott-lenovo/bitbake/bin`` directory to the front of the
-``PATH`` variable::
-  $ export PATH=/home/scott-lenovo/bitbake/bin:$PATH
-You should now be able to enter the ``bitbake`` command from the command
-line while working from any directory.
-The Hello World Example
-=======================
-The overall goal of this exercise is to build a complete "Hello World"
-example utilizing task and layer concepts. Because this is how modern
-projects such as OpenEmbedded and the Yocto Project utilize BitBake, the
-example provides an excellent starting point for understanding BitBake.
-To help you understand how to use BitBake to build targets, the example
-starts with nothing but the ``bitbake`` command, which causes BitBake to
-fail and report problems. The example progresses by adding pieces to the
-build to eventually conclude with a working, minimal "Hello World"
-example.
-While every attempt is made to explain what is happening during the
-example, the descriptions cannot cover everything. You can find further
-information throughout this manual. Also, you can actively participate
-in the :oe_lists:`/g/bitbake-devel`
-discussion mailing list about the BitBake build tool.
-.. note::
-   This example was inspired by and drew heavily from
-   `Mailing List post - The BitBake equivalent of "Hello, World!"
-   <https://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html>`_.
-As stated earlier, the goal of this example is to eventually compile
-"Hello World". However, it is unknown what BitBake needs and what you
-have to provide in order to achieve that goal. Recall that BitBake
-utilizes three types of metadata files:
-:ref:`bitbake-user-manual/bitbake-user-manual-intro:configuration files`,
-:ref:`bitbake-user-manual/bitbake-user-manual-intro:classes`, and
-:ref:`bitbake-user-manual/bitbake-user-manual-intro:recipes`.
-But where do they go? How does BitBake find
-them? BitBake's error messaging helps you answer these types of
-questions and helps you better understand exactly what is going on.
-Following is the complete "Hello World" example.
-#.  **Create a Project Directory:** First, set up a directory for the
-    "Hello World" project. Here is how you can do so in your home
-    directory::
-      $ mkdir ~/hello
-      $ cd ~/hello
-    This is the directory that
-    BitBake will use to do all of its work. You can use this directory
-    to keep all the metafiles needed by BitBake. Having a project
-    directory is a good way to isolate your project.
-#.  **Run BitBake:** At this point, you have nothing but a project
-    directory. Run the ``bitbake`` command and see what it does::
-       $ bitbake
-       ERROR: The BBPATH variable is not set and bitbake did not find a conf/bblayers.conf file in the expected location.
-       Maybe you accidentally invoked bitbake from the wrong directory?
-    When you run BitBake, it begins looking for metadata files. The
-    :term:`BBPATH` variable is what tells BitBake where
-    to look for those files. :term:`BBPATH` is not set and you need to set
-    it. Without :term:`BBPATH`, BitBake cannot find any configuration files
-    (``.conf``) or recipe files (``.bb``) at all. BitBake also cannot
-    find the ``bitbake.conf`` file.
-#.  **Setting BBPATH:** For this example, you can set :term:`BBPATH` in
-    the same manner that you set ``PATH`` earlier in the appendix. You
-    should realize, though, that it is much more flexible to set the
-    :term:`BBPATH` variable up in a configuration file for each project.
-    From your shell, enter the following commands to set and export the
-    :term:`BBPATH` variable::
-      $ BBPATH="projectdirectory"
-      $ export BBPATH
-    Use your actual project directory in the command. BitBake uses that
-    directory to find the metadata it needs for your project.
-    .. note::
-       When specifying your project directory, do not use the tilde
-       ("~") character as BitBake does not expand that character as the
-       shell would.
-#.  **Run BitBake:** Now that you have :term:`BBPATH` defined, run the
-    ``bitbake`` command again::
-       $ bitbake
-       ERROR: Unable to parse /home/scott-lenovo/bitbake/lib/bb/parse/__init__.py
-       Traceback (most recent call last):
-       File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 127, in resolve_file(fn='conf/bitbake.conf', d=<bb.data_smart.DataSmart object at 0x7f22919a3df0>):
-             if not newfn:
-       >            raise IOError(errno.ENOENT, "file %s not found in %s" % (fn, bbpath))
-             fn = newfn
-       FileNotFoundError: [Errno 2] file conf/bitbake.conf not found in <projectdirectory>
-    This sample output shows that BitBake could not find the
-    ``conf/bitbake.conf`` file in the project directory. This file is
-    the first thing BitBake must find in order to build a target. And,
-    since the project directory for this example is empty, you need to
-    provide a ``conf/bitbake.conf`` file.
-#.  **Creating conf/bitbake.conf:** The ``conf/bitbake.conf`` includes
-    a number of configuration variables BitBake uses for metadata and
-    recipe files. For this example, you need to create the file in your
-    project directory and define some key BitBake variables. For more
-    information on the ``bitbake.conf`` file, see
-    https://git.openembedded.org/bitbake/tree/conf/bitbake.conf.
-    Use the following commands to create the ``conf`` directory in the
-    project directory::
-      $ mkdir conf
-    From within the ``conf`` directory,
-    use some editor to create the ``bitbake.conf`` so that it contains
-    the following::
-       PN  = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
-       TMPDIR  = "${TOPDIR}/tmp"
-       CACHE   = "${TMPDIR}/cache"
-       STAMP   = "${TMPDIR}/${PN}/stamps"
-       T       = "${TMPDIR}/${PN}/work"
-       B       = "${TMPDIR}/${PN}"
-    .. note::
-       Without a value for :term:`PN`, the variables :term:`STAMP`, :term:`T`, and :term:`B`, prevent more
-       than one recipe from working. You can fix this by either setting :term:`PN` to
-       have a value similar to what OpenEmbedded and BitBake use in the default
-       ``bitbake.conf`` file (see previous example). Or, by manually updating each
-       recipe to set :term:`PN`. You will also need to include :term:`PN` as part of the :term:`STAMP`,
-       :term:`T`, and :term:`B` variable definitions in the ``local.conf`` file.
-    The ``TMPDIR`` variable establishes a directory that BitBake uses
-    for build output and intermediate files other than the cached
-    information used by the
-    :ref:`bitbake-user-manual/bitbake-user-manual-execution:setscene`
-    process. Here, the ``TMPDIR`` directory is set to ``hello/tmp``.
-    .. tip::
-       You can always safely delete the tmp directory in order to rebuild a
-       BitBake target. The build process creates the directory for you when you
-       run BitBake.
-    For information about each of the other variables defined in this
-    example, check :term:`PN`, :term:`TOPDIR`, :term:`CACHE`, :term:`STAMP`,
-    :term:`T` or :term:`B` to take you to the definitions in the
-    glossary.
-#.  **Run BitBake:** After making sure that the ``conf/bitbake.conf`` file
-    exists, you can run the ``bitbake`` command again::
-       $ bitbake
-       ERROR: Unable to parse /home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py
-       Traceback (most recent call last):
-       File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 67, in inherit(files=['base'], fn='configuration INHERITs', lineno=0, d=<bb.data_smart.DataSmart object at 0x7fab6815edf0>):
-             if not os.path.exists(file):
-       >            raise ParseError("Could not inherit file %s" % (file), fn, lineno)
-       bb.parse.ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
-    In the sample output,
-    BitBake could not find the ``classes/base.bbclass`` file. You need
-    to create that file next.
-#.  **Creating classes/base.bbclass:** BitBake uses class files to
-    provide common code and functionality. The minimally required class
-    for BitBake is the ``classes/base.bbclass`` file. The ``base`` class
-    is implicitly inherited by every recipe. BitBake looks for the class
-    in the ``classes`` directory of the project (i.e ``hello/classes``
-    in this example).
-    Create the ``classes`` directory as follows::
-      $ cd $HOME/hello
-      $ mkdir classes
-    Move to the ``classes`` directory and then create the
-    ``base.bbclass`` file by inserting this single line::
-      addtask build
-    The minimal task that BitBake runs is the ``do_build`` task. This is
-    all the example needs in order to build the project. Of course, the
-    ``base.bbclass`` can have much more depending on which build
-    environments BitBake is supporting.
-#.  **Run BitBake:** After making sure that the ``classes/base.bbclass``
-    file exists, you can run the ``bitbake`` command again::
-       $ bitbake
-       Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
-    BitBake is finally reporting
-    no errors. However, you can see that it really does not have
-    anything to do. You need to create a recipe that gives BitBake
-    something to do.
-#.  **Creating a Layer:** While it is not really necessary for such a
-    small example, it is good practice to create a layer in which to
-    keep your code separate from the general metadata used by BitBake.
-    Thus, this example creates and uses a layer called "mylayer".
-    .. note::
-       You can find additional information on layers in the
-       ":ref:`bitbake-user-manual/bitbake-user-manual-intro:Layers`" section.
-    Minimally, you need a recipe file and a layer configuration file in
-    your layer. The configuration file needs to be in the ``conf``
-    directory inside the layer. Use these commands to set up the layer
-    and the ``conf`` directory::
-       $ cd $HOME
-       $ mkdir mylayer
-       $ cd mylayer
-       $ mkdir conf
-    Move to the ``conf`` directory and create a ``layer.conf`` file that has the
-    following::
-      BBPATH .= ":${LAYERDIR}"
-      BBFILES += "${LAYERDIR}/*.bb"
-      BBFILE_COLLECTIONS += "mylayer"
-      BBFILE_PATTERN_mylayer := "^${LAYERDIR_RE}/"
-      LAYERSERIES_CORENAMES = "hello_world_example"
-      LAYERSERIES_COMPAT_mylayer = "hello_world_example"
-    For information on these variables, click on :term:`BBFILES`,
-    :term:`LAYERDIR`, :term:`BBFILE_COLLECTIONS`, :term:`BBFILE_PATTERN_mylayer <BBFILE_PATTERN>`
-    or :term:`LAYERSERIES_COMPAT` to go to the definitions in the glossary.
-    .. note::
-       We are setting both ``LAYERSERIES_CORENAMES`` and :term:`LAYERSERIES_COMPAT` in this particular case, because we
-       are using bitbake without OpenEmbedded.
-       You should usually just use :term:`LAYERSERIES_COMPAT` to specify the OE-Core versions for which your layer
-       is compatible, and add the meta-openembedded layer to your project.
-    You need to create the recipe file next. Inside your layer at the
-    top-level, use an editor and create a recipe file named
-    ``printhello.bb`` that has the following::
-       DESCRIPTION = "Prints Hello World"
-       PN = 'printhello'
-       PV = '1'
-       python do_build() {
-          bb.plain("********************");
-          bb.plain("*                  *");
-          bb.plain("*  Hello, World!   *");
-          bb.plain("*                  *");
-          bb.plain("********************");
-       }
-    The recipe file simply provides
-    a description of the recipe, the name, version, and the ``do_build``
-    task, which prints out "Hello World" to the console. For more
-    information on :term:`DESCRIPTION`, :term:`PN` or :term:`PV`
-    follow the links to the glossary.
-#. **Run BitBake With a Target:** Now that a BitBake target exists, run
-    the command and provide that target::
-      $ cd $HOME/hello
-      $ bitbake printhello
-      ERROR: no recipe files to build, check your BBPATH and BBFILES?
-      Summary: There was 1 ERROR message shown, returning a non-zero exit code.
-    We have created the layer with the recipe and
-    the layer configuration file but it still seems that BitBake cannot
-    find the recipe. BitBake needs a ``conf/bblayers.conf`` that lists
-    the layers for the project. Without this file, BitBake cannot find
-    the recipe.
-#. **Creating conf/bblayers.conf:** BitBake uses the
-    ``conf/bblayers.conf`` file to locate layers needed for the project.
-    This file must reside in the ``conf`` directory of the project (i.e.
-    ``hello/conf`` for this example).
-    Set your working directory to the ``hello/conf`` directory and then
-    create the ``bblayers.conf`` file so that it contains the following::
-       BBLAYERS ?= " \
-           /home/<you>/mylayer \
-       "
-    You need to provide your own information for ``you`` in the file.
-#. **Run BitBake With a Target:** Now that you have supplied the
-    ``bblayers.conf`` file, run the ``bitbake`` command and provide the
-    target::
-       $ bitbake printhello
-       Loading cache: 100% |
-       Loaded 0 entries from dependency cache.
-       Parsing recipes: 100% |##################################################################################|
-       Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped, 0 masked, 0 errors.
-       NOTE: Resolving any missing task queue dependencies
-       Initialising tasks: 100% |###############################################################################|
-       NOTE: No setscene tasks
-       NOTE: Executing Tasks
-       ********************
-       *                  *
-       *  Hello, World!   *
-       *                  *
-       ********************
-       NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and all succeeded.
-    .. note::
-       After the first execution, re-running bitbake printhello again will not
-       result in a BitBake run that prints the same console output. The reason
-       for this is that the first time the printhello.bb recipe's do_build task
-       executes successfully, BitBake writes a stamp file for the task. Thus,
-       the next time you attempt to run the task using that same bitbake
-       command, BitBake notices the stamp and therefore determines that the task
-       does not need to be re-run. If you delete the tmp directory or run
-       bitbake -c clean printhello and then re-run the build, the "Hello,
-       World!" message will be printed again.
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.rst
deleted file mode 100644
index 9837b009ea..0000000000
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-intro.rst
+++ /dev/null
@@ -1,709 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-========
-Overview
-========
-|
-Welcome to the BitBake User Manual. This manual provides information on
-the BitBake tool. The information attempts to be as independent as
-possible regarding systems that use BitBake, such as OpenEmbedded and
-the Yocto Project. In some cases, scenarios or examples within the
-context of a build system are used in the manual to help with
-understanding. For these cases, the manual clearly states the context.
-.. _intro:
-Introduction
-============
-Fundamentally, BitBake is a generic task execution engine that allows
-shell and Python tasks to be run efficiently and in parallel while
-working within complex inter-task dependency constraints. One of
-BitBake's main users, OpenEmbedded, takes this core and builds embedded
-Linux software stacks using a task-oriented approach.
-Conceptually, BitBake is similar to GNU Make in some regards but has
-significant differences:
-  BitBake executes tasks according to the provided metadata that builds up
-   the tasks. Metadata is stored in recipe (``.bb``) and related recipe
-   "append" (``.bbappend``) files, configuration (``.conf``) and
-   underlying include (``.inc``) files, and in class (``.bbclass``)
-   files. The metadata provides BitBake with instructions on what tasks
-   to run and the dependencies between those tasks.
-  BitBake includes a fetcher library for obtaining source code from
-   various places such as local files, source control systems, or
-   websites.
-  The instructions for each unit to be built (e.g. a piece of software)
-   are known as "recipe" files and contain all the information about the
-   unit (dependencies, source file locations, checksums, description and
-   so on).
-  BitBake includes a client/server abstraction and can be used from a
-   command line or used as a service over XML-RPC and has several
-   different user interfaces.
-History and Goals
-=================
-BitBake was originally a part of the OpenEmbedded project. It was
-inspired by the Portage package management system used by the Gentoo
-Linux distribution. On December 7, 2004, OpenEmbedded project team
-member Chris Larson split the project into two distinct pieces:
-  BitBake, a generic task executor
-  OpenEmbedded, a metadata set utilized by BitBake
-Today, BitBake is the primary basis of the
-`OpenEmbedded <https://www.openembedded.org/>`__ project, which is being
-used to build and maintain Linux distributions such as the `Poky
-Reference Distribution <https://www.yoctoproject.org/software-item/poky/>`__,
-developed under the umbrella of the `Yocto Project <https://www.yoctoproject.org>`__.
-Prior to BitBake, no other build tool adequately met the needs of an
-aspiring embedded Linux distribution. All of the build systems used by
-traditional desktop Linux distributions lacked important functionality,
-and none of the ad hoc Buildroot-based systems, prevalent in the
-embedded space, were scalable or maintainable.
-Some important original goals for BitBake were:
-  Handle cross-compilation.
-  Handle inter-package dependencies (build time on target architecture,
-   build time on native architecture, and runtime).
-  Support running any number of tasks within a given package,
-   including, but not limited to, fetching upstream sources, unpacking
-   them, patching them, configuring them, and so forth.
-  Be Linux distribution agnostic for both build and target systems.
-  Be architecture agnostic.
-  Support multiple build and target operating systems (e.g. Cygwin, the
-   BSDs, and so forth).
-  Be self-contained, rather than tightly integrated into the build
-   machine's root filesystem.
-  Handle conditional metadata on the target architecture, operating
-   system, distribution, and machine.
-  Be easy to use the tools to supply local metadata and packages
-   against which to operate.
-  Be easy to use BitBake to collaborate between multiple projects for
-   their builds.
-  Provide an inheritance mechanism to share common metadata between
-   many packages.
-Over time it became apparent that some further requirements were
-necessary:
-  Handle variants of a base recipe (e.g. native, sdk, and multilib).
-  Split metadata into layers and allow layers to enhance or override
-   other layers.
-  Allow representation of a given set of input variables to a task as a
-   checksum. Based on that checksum, allow acceleration of builds with
-   prebuilt components.
-BitBake satisfies all the original requirements and many more with
-extensions being made to the basic functionality to reflect the
-additional requirements. Flexibility and power have always been the
-priorities. BitBake is highly extensible and supports embedded Python
-code and execution of any arbitrary tasks.
-.. _Concepts:
-Concepts
-========
-BitBake is a program written in the Python language. At the highest
-level, BitBake interprets metadata, decides what tasks are required to
-run, and executes those tasks. Similar to GNU Make, BitBake controls how
-software is built. GNU Make achieves its control through "makefiles",
-while BitBake uses "recipes".
-BitBake extends the capabilities of a simple tool like GNU Make by
-allowing for the definition of much more complex tasks, such as
-assembling entire embedded Linux distributions.
-The remainder of this section introduces several concepts that should be
-understood in order to better leverage the power of BitBake.
-Recipes
-------
-BitBake Recipes, which are denoted by the file extension ``.bb``, are
-the most basic metadata files. These recipe files provide BitBake with
-the following:
-  Descriptive information about the package (author, homepage, license,
-   and so on)
-  The version of the recipe
-  Existing dependencies (both build and runtime dependencies)
-  Where the source code resides and how to fetch it
-  Whether the source code requires any patches, where to find them, and
-   how to apply them
-  How to configure and compile the source code
-  How to assemble the generated artifacts into one or more installable
-   packages
-  Where on the target machine to install the package or packages
-   created
-Within the context of BitBake, or any project utilizing BitBake as its
-build system, files with the ``.bb`` extension are referred to as
-recipes.
-.. note::
-   The term "package" is also commonly used to describe recipes.
-   However, since the same word is used to describe packaged output from
-   a project, it is best to maintain a single descriptive term -
-   "recipes". Put another way, a single "recipe" file is quite capable
-   of generating a number of related but separately installable
-   "packages". In fact, that ability is fairly common.
-Configuration Files
-------------------
-Configuration files, which are denoted by the ``.conf`` extension,
-define various configuration variables that govern the project's build
-process. These files fall into several areas that define machine
-configuration, distribution configuration, possible compiler tuning,
-general common configuration, and user configuration. The main
-configuration file is the sample ``bitbake.conf`` file, which is located
-within the BitBake source tree ``conf`` directory.
-Classes
-------
-Class files, which are denoted by the ``.bbclass`` extension, contain
-information that is useful to share between metadata files. The BitBake
-source tree currently comes with one class metadata file called
-``base.bbclass``. You can find this file in the ``classes`` directory.
-The ``base.bbclass`` class files is special since it is always included
-automatically for all recipes and classes. This class contains
-definitions for standard basic tasks such as fetching, unpacking,
-configuring (empty by default), compiling (runs any Makefile present),
-installing (empty by default) and packaging (empty by default). These
-tasks are often overridden or extended by other classes added during the
-project development process.
-Class Types
-~~~~~~~~~~~
-BitBake supports class files installed in three different directories:
-  ``classes-global/``: these classes must be inherited globally through the
-   :term:`INHERIT` variable in a :ref:`configuration file
-   <bitbake-user-manual/bitbake-user-manual-intro:Configuration Files>`.  These
-   classes are included for every recipe being built. For example, you would use
-   the global class named ``myclass`` like so::
-      INHERIT += "myclass"
-  ``classes-recipe/``: these classes must be inherited from a recipe using the
-   :ref:`inherit <ref-bitbake-user-manual-metadata-inherit>` directive. They do
-   not support being inherited globally. For example, you would use the recipe
-   class named ``myclass`` like so::
-      inherit myclass
-  ``classes/``: this final directory is meant for classes that can be used in
-   the two contexts explain above. In other words, they can be inherit either
-   globally or in a recipe.
-For details on how BitBake locates class files, see the
-:ref:`bitbake-user-manual/bitbake-user-manual-metadata:Locating Class Files`
-section of the Bitbake User Manual.
-Layers
------
-Layers allow you to isolate different types of customizations from each
-other. While you might find it tempting to keep everything in one layer
-when working on a single project, the more modular your metadata, the
-easier it is to cope with future changes.
-To illustrate how you can use layers to keep things modular, consider
-customizations you might make to support a specific target machine.
-These types of customizations typically reside in a special layer,
-rather than a general layer, called a Board Support Package (BSP) layer.
-Furthermore, the machine customizations should be isolated from recipes
-and metadata that support a new GUI environment, for example. This
-situation gives you a couple of layers: one for the machine
-configurations and one for the GUI environment. It is important to
-understand, however, that the BSP layer can still make machine-specific
-additions to recipes within the GUI environment layer without polluting
-the GUI layer itself with those machine-specific changes. You can
-accomplish this through a recipe that is a BitBake append
-(``.bbappend``) file.
-.. _append-bbappend-files:
-Append Files
------------
-Append files, which are files that have the ``.bbappend`` file
-extension, extend or override information in an existing recipe file.
-BitBake expects every append file to have a corresponding recipe file.
-Furthermore, the append file and corresponding recipe file must use the
-same root filename. The filenames can differ only in the file type
-suffix used (e.g. ``formfactor_0.0.bb`` and
-``formfactor_0.0.bbappend``).
-Information in append files extends or overrides the information in the
-underlying, similarly-named recipe files.
-When you name an append file, you can use the "``%``" wildcard character
-to allow for matching recipe names. For example, suppose you have an
-append file named as follows::
-  busybox_1.21.%.bbappend
-That append file
-would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So,
-the append file would match the following recipe names::
-  busybox_1.21.1.bb
-  busybox_1.21.2.bb
-  busybox_1.21.3.bb
-  busybox_1.21.10.bb
-  busybox_1.21.11.bb
-.. note::
-   The use of the " % " character is limited in that it only works directly in
-   front of the .bbappend portion of the append file's name. You cannot use the
-   wildcard character in any other location of the name.
-If the ``busybox`` recipe was updated to ``busybox_1.3.0.bb``, the
-append name would not match. However, if you named the append file
-``busybox_1.%.bbappend``, then you would have a match.
-In the most general case, you could name the append file something as
-simple as ``busybox_%.bbappend`` to be entirely version independent.
-Obtaining BitBake
-=================
-You can obtain BitBake several different ways:
-  **Cloning BitBake:** Using Git to clone the BitBake source code
-   repository is the recommended method for obtaining BitBake. Cloning
-   the repository makes it easy to get bug fixes and have access to
-   stable branches and the master branch. Once you have cloned BitBake,
-   you should use the latest stable branch for development since the
-   master branch is for BitBake development and might contain less
-   stable changes.
-   You usually need a version of BitBake that matches the metadata you
-   are using. The metadata is generally backwards compatible but not
-   forward compatible.
-   Here is an example that clones the BitBake repository::
-     $ git clone git://git.openembedded.org/bitbake
-   This command clones the BitBake
-   Git repository into a directory called ``bitbake``. Alternatively,
-   you can designate a directory after the ``git clone`` command if you
-   want to call the new directory something other than ``bitbake``. Here
-   is an example that names the directory ``bbdev``::
-     $ git clone git://git.openembedded.org/bitbake bbdev
-  **Installation using your Distribution Package Management System:**
-   This method is not recommended because the BitBake version that is
-   provided by your distribution, in most cases, is several releases
-   behind a snapshot of the BitBake repository.
-  **Taking a snapshot of BitBake:** Downloading a snapshot of BitBake
-   from the source code repository gives you access to a known branch or
-   release of BitBake.
-      .. note::
-         Cloning the Git repository, as described earlier, is the preferred
-         method for getting BitBake. Cloning the repository makes it easier
-         to update as patches are added to the stable branches.
-   The following example downloads a snapshot of BitBake version 1.17.0::
-     $ wget https://git.openembedded.org/bitbake/snapshot/bitbake-1.17.0.tar.gz
-     $ tar zxpvf bitbake-1.17.0.tar.gz
-   After extraction of the tarball using
-   the tar utility, you have a directory entitled ``bitbake-1.17.0``.
-  **Using the BitBake that Comes With Your Build Checkout:** A final
-   possibility for getting a copy of BitBake is that it already comes
-   with your checkout of a larger BitBake-based build system, such as
-   Poky. Rather than manually checking out individual layers and gluing
-   them together yourself, you can check out an entire build system. The
-   checkout will already include a version of BitBake that has been
-   thoroughly tested for compatibility with the other components. For
-   information on how to check out a particular BitBake-based build
-   system, consult that build system's supporting documentation.
-.. _bitbake-user-manual-command:
-The BitBake Command
-===================
-The ``bitbake`` command is the primary interface to the BitBake tool.
-This section presents the BitBake command syntax and provides several
-execution examples.
-Usage and syntax
----------------
-Following is the usage and syntax for BitBake::
-   $ bitbake -h
-   usage: bitbake [-s] [-e] [-g] [-u UI] [--version] [-h] [-f] [-c CMD]
-                  [-C INVALIDATE_STAMP] [--runall RUNALL] [--runonly RUNONLY]
-                  [--no-setscene] [--skip-setscene] [--setscene-only] [-n] [-p]
-                  [-k] [-P] [-S SIGNATURE_HANDLER] [--revisions-changed]
-                  [-b BUILDFILE] [-D] [-l DEBUG_DOMAINS] [-v] [-q]
-                  [-w WRITEEVENTLOG] [-B BIND] [-T SERVER_TIMEOUT]
-                  [--remote-server REMOTE_SERVER] [-m] [--token XMLRPCTOKEN]
-                  [--observe-only] [--status-only] [--server-only] [-r PREFILE]
-                  [-R POSTFILE] [-I EXTRA_ASSUME_PROVIDED]
-                  [recipename/target ...]
-   It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH
-   which will provide the layer, BBFILES and other configuration information.
-   General options:
-     recipename/target     Execute the specified task (default is 'build') for
-                           these target recipes (.bb files).
-     -s, --show-versions   Show current and preferred versions of all recipes.
-     -e, --environment     Show the global or per-recipe environment complete
-                           with information about where variables were
-                           set/changed.
-     -g, --graphviz        Save dependency tree information for the specified
-                           targets in the dot syntax.
-     -u UI, --ui UI        The user interface to use (knotty, ncurses, taskexp,
-                           taskexp_ncurses or teamcity - default knotty).
-     --version             Show programs version and exit.
-     -h, --help            Show this help message and exit.
-   Task control options:
-     -f, --force           Force the specified targets/task to run (invalidating
-                           any existing stamp file).
-     -c CMD, --cmd CMD     Specify the task to execute. The exact options
-                           available depend on the metadata. Some examples might
-                           be 'compile' or 'populate_sysroot' or 'listtasks' may
-                           give a list of the tasks available.
-     -C INVALIDATE_STAMP, --clear-stamp INVALIDATE_STAMP
-                           Invalidate the stamp for the specified task such as
-                           'compile' and then run the default task for the
-                           specified target(s).
-     --runall RUNALL       Run the specified task for any recipe in the taskgraph
-                           of the specified target (even if it wouldn't otherwise
-                           have run).
-     --runonly RUNONLY     Run only the specified task within the taskgraph of
-                           the specified targets (and any task dependencies those
-                           tasks may have).
-     --no-setscene         Do not run any setscene tasks. sstate will be ignored
-                           and everything needed, built.
-     --skip-setscene       Skip setscene tasks if they would be executed. Tasks
-                           previously restored from sstate will be kept, unlike
-                           --no-setscene.
-     --setscene-only       Only run setscene tasks, don't run any real tasks.
-   Execution control options:
-     -n, --dry-run         Don't execute, just go through the motions.
-     -p, --parse-only      Quit after parsing the BB recipes.
-     -k, --continue        Continue as much as possible after an error. While the
-                           target that failed and anything depending on it cannot
-                           be built, as much as possible will be built before
-                           stopping.
-     -P, --profile         Profile the command and save reports.
-     -S SIGNATURE_HANDLER, --dump-signatures SIGNATURE_HANDLER
-                           Dump out the signature construction information, with
-                           no task execution. The SIGNATURE_HANDLER parameter is
-                           passed to the handler. Two common values are none and
-                           printdiff but the handler may define more/less. none
-                           means only dump the signature, printdiff means
-                           recursively compare the dumped signature with the most
-                           recent one in a local build or sstate cache (can be
-                           used to find out why tasks re-run when that is not
-                           expected)
-     --revisions-changed   Set the exit code depending on whether upstream
-                           floating revisions have changed or not.
-     -b BUILDFILE, --buildfile BUILDFILE
-                           Execute tasks from a specific .bb recipe directly.
-                           WARNING: Does not handle any dependencies from other
-                           recipes.
-   Logging/output control options:
-     -D, --debug           Increase the debug level. You can specify this more
-                           than once. -D sets the debug level to 1, where only
-                           bb.debug(1, ...) messages are printed to stdout; -DD
-                           sets the debug level to 2, where both bb.debug(1, ...)
-                           and bb.debug(2, ...) messages are printed; etc.
-                           Without -D, no debug messages are printed. Note that
-                           -D only affects output to stdout. All debug messages
-                           are written to ${T}/log.do_taskname, regardless of the
-                           debug level.
-     -l DEBUG_DOMAINS, --log-domains DEBUG_DOMAINS
-                           Show debug logging for the specified logging domains.
-     -v, --verbose         Enable tracing of shell tasks (with 'set -x'). Also
-                           print bb.note(...) messages to stdout (in addition to
-                           writing them to ${T}/log.do_<task>).
-     -q, --quiet           Output less log message data to the terminal. You can
-                           specify this more than once.
-     -w WRITEEVENTLOG, --write-log WRITEEVENTLOG
-                           Writes the event log of the build to a bitbake event
-                           json file. Use '' (empty string) to assign the name
-                           automatically.
-   Server options:
-     -B BIND, --bind BIND  The name/address for the bitbake xmlrpc server to bind
-                           to.
-     -T SERVER_TIMEOUT, --idle-timeout SERVER_TIMEOUT
-                           Set timeout to unload bitbake server due to
-                           inactivity, set to -1 means no unload, default:
-                           Environment variable BB_SERVER_TIMEOUT.
-     --remote-server REMOTE_SERVER
-                           Connect to the specified server.
-     -m, --kill-server     Terminate any running bitbake server.
-     --token XMLRPCTOKEN   Specify the connection token to be used when
-                           connecting to a remote server.
-     --observe-only        Connect to a server as an observing-only client.
-     --status-only         Check the status of the remote bitbake server.
-     --server-only         Run bitbake without a UI, only starting a server
-                           (cooker) process.
-   Configuration options:
-     -r PREFILE, --read PREFILE
-                           Read the specified file before bitbake.conf.
-     -R POSTFILE, --postread POSTFILE
-                           Read the specified file after bitbake.conf.
-     -I EXTRA_ASSUME_PROVIDED, --ignore-deps EXTRA_ASSUME_PROVIDED
-                           Assume these dependencies don't exist and are already
-                           provided (equivalent to ASSUME_PROVIDED). Useful to
-                           make dependency graphs more appealing.
-..
-    Bitbake help output generated with "stty columns 80; bin/bitbake -h"
-.. _bitbake-examples:
-Examples
--------
-This section presents some examples showing how to use BitBake.
-.. _example-executing-a-task-against-a-single-recipe:
-Executing a Task Against a Single Recipe
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Executing tasks for a single recipe file is relatively simple. You
-specify the file in question, and BitBake parses it and executes the
-specified task. If you do not specify a task, BitBake executes the
-default task, which is "build". BitBake obeys inter-task dependencies
-when doing so.
-The following command runs the build task, which is the default task, on
-the ``foo_1.0.bb`` recipe file::
-  $ bitbake -b foo_1.0.bb
-The following command runs the clean task on the ``foo.bb`` recipe file::
-  $ bitbake -b foo.bb -c clean
-.. note::
-   The "-b" option explicitly does not handle recipe dependencies. Other
-   than for debugging purposes, it is instead recommended that you use
-   the syntax presented in the next section.
-Executing Tasks Against a Set of Recipe Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-There are a number of additional complexities introduced when one wants
-to manage multiple ``.bb`` files. Clearly there needs to be a way to
-tell BitBake what files are available and, of those, which you want to
-execute. There also needs to be a way for each recipe to express its
-dependencies, both for build-time and runtime. There must be a way for
-you to express recipe preferences when multiple recipes provide the same
-functionality, or when there are multiple versions of a recipe.
-The ``bitbake`` command, when not using "--buildfile" or "-b" only
-accepts a "PROVIDES". You cannot provide anything else. By default, a
-recipe file generally "PROVIDES" its "packagename" as shown in the
-following example::
-  $ bitbake foo
-This next example "PROVIDES" the
-package name and also uses the "-c" option to tell BitBake to just
-execute the ``do_clean`` task::
-  $ bitbake -c clean foo
-Executing a List of Task and Recipe Combinations
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The BitBake command line supports specifying different tasks for
-individual targets when you specify multiple targets. For example,
-suppose you had two targets (or recipes) ``myfirstrecipe`` and
-``mysecondrecipe`` and you needed BitBake to run ``taskA`` for the first
-recipe and ``taskB`` for the second recipe::
-  $ bitbake myfirstrecipe:do_taskA mysecondrecipe:do_taskB
-Generating Dependency Graphs
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-BitBake is able to generate dependency graphs using the ``dot`` syntax.
-You can convert these graphs into images using the ``dot`` tool from
-`Graphviz <http://www.graphviz.org>`__.
-When you generate a dependency graph, BitBake writes two files to the
-current working directory:
-  ``task-depends.dot``: Shows dependencies between tasks. These
-   dependencies match BitBake's internal task execution list.
-  ``pn-buildlist``: Shows a simple list of targets that are to be
-   built.
-To stop depending on common depends, use the ``-I`` depend option and
-BitBake omits them from the graph. Leaving this information out can
-produce more readable graphs. This way, you can remove from the graph
-:term:`DEPENDS` from inherited classes such as ``base.bbclass``.
-Here are two examples that create dependency graphs. The second example
-omits depends common in OpenEmbedded from the graph::
-  $ bitbake -g foo
-  $ bitbake -g -I virtual/kernel -I eglibc foo
-Executing a Multiple Configuration Build
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-BitBake is able to build multiple images or packages using a single
-command where the different targets require different configurations
-(multiple configuration builds). Each target, in this scenario, is
-referred to as a "multiconfig".
-To accomplish a multiple configuration build, you must define each
-target's configuration separately using a parallel configuration file in
-the build directory. The location for these multiconfig configuration
-files is specific. They must reside in the current build directory in a
-sub-directory of ``conf`` named ``multiconfig``. Following is an example
-for two separate targets:
-.. image:: figures/bb_multiconfig_files.png
-   :align: center
-The reason for this required file hierarchy is because the :term:`BBPATH`
-variable is not constructed until the layers are parsed. Consequently,
-using the configuration file as a pre-configuration file is not possible
-unless it is located in the current working directory.
-Minimally, each configuration file must define the machine and the
-temporary directory BitBake uses for the build. Suggested practice
-dictates that you do not overlap the temporary directories used during
-the builds.
-Aside from separate configuration files for each target, you must also
-enable BitBake to perform multiple configuration builds. Enabling is
-accomplished by setting the
-:term:`BBMULTICONFIG` variable in the
-``local.conf`` configuration file. As an example, suppose you had
-configuration files for ``target1`` and ``target2`` defined in the build
-directory. The following statement in the ``local.conf`` file both
-enables BitBake to perform multiple configuration builds and specifies
-the two extra multiconfigs::
-  BBMULTICONFIG = "target1 target2"
-Once the target configuration files are in place and BitBake has been
-enabled to perform multiple configuration builds, use the following
-command form to start the builds::
-  $ bitbake [mc:multiconfigname:]target [[[mc:multiconfigname:]target] ... ]
-Here is an example for two extra multiconfigs: ``target1`` and ``target2``::
-  $ bitbake mc::target mc:target1:target mc:target2:target
-.. _bb-enabling-multiple-configuration-build-dependencies:
-Enabling Multiple Configuration Build Dependencies
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Sometimes dependencies can exist between targets (multiconfigs) in a
-multiple configuration build. For example, suppose that in order to
-build an image for a particular architecture, the root filesystem of
-another build for a different architecture needs to exist. In other
-words, the image for the first multiconfig depends on the root
-filesystem of the second multiconfig. This dependency is essentially
-that the task in the recipe that builds one multiconfig is dependent on
-the completion of the task in the recipe that builds another
-multiconfig.
-To enable dependencies in a multiple configuration build, you must
-declare the dependencies in the recipe using the following statement
-form::
-  task_or_package[mcdepends] = "mc:from_multiconfig:to_multiconfig:recipe_name:task_on_which_to_depend"
-To better show how to use this statement, consider an example with two
-multiconfigs: ``target1`` and ``target2``::
-  image_task[mcdepends] = "mc:target1:target2:image2:rootfs_task"
-In this example, the
-``from_multiconfig`` is "target1" and the ``to_multiconfig`` is "target2". The
-task on which the image whose recipe contains image_task depends on the
-completion of the rootfs_task used to build out image2, which is
-associated with the "target2" multiconfig.
-Once you set up this dependency, you can build the "target1" multiconfig
-using a BitBake command as follows::
-  $ bitbake mc:target1:image1
-This command executes all the tasks needed to create ``image1`` for the "target1"
-multiconfig. Because of the dependency, BitBake also executes through
-the ``rootfs_task`` for the "target2" multiconfig build.
-Having a recipe depend on the root filesystem of another build might not
-seem that useful. Consider this change to the statement in the image1
-recipe::
-  image_task[mcdepends] = "mc:target1:target2:image2:image_task"
-In this case, BitBake must create ``image2`` for the "target2" build since
-the "target1" build depends on it.
-Because "target1" and "target2" are enabled for multiple configuration
-builds and have separate configuration files, BitBake places the
-artifacts for each build in the respective temporary build directories.
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-library-functions.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-library-functions.rst
deleted file mode 100644
index 09e353945b..0000000000
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-library-functions.rst
+++ /dev/null
@@ -1,59 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-=================
-Library Functions
-=================
-|
-This chapter lists common library functions available under the ``lib/``
-directory in BitBake.
-These functions can be used in recipes or configuration files with
-:ref:`inline-Python <bitbake-user-manual/bitbake-user-manual-metadata:Inline
-Python Variable Expansion>` or :ref:`Python
-<bitbake-user-manual/bitbake-user-manual-metadata:BitBake-Style Python
-Functions>` functions.
-Logging utilities
-=================
-Different logging utilities can be used from Python code in recipes or
-configuration files.
-The strings passed below can be formatted with ``str.format()``, for example::
-   bb.warn("Houston, we have a %s", "bit of a problem")
-Formatted string can also be used directly::
-   bb.error("%s, we have a %s" % ("Houston", "big problem"))
-Python f-strings may also be used::
-   h = "Houston"
-   bb.fatal(f"{h}, we have a critical problem")
-.. automodule:: bb
-   :members:
-      debug,
-      error,
-      erroronce,
-      fatal,
-      note,
-      plain,
-      verbnote,
-      warn,
-      warnonce,
-``bb.utils``
-============
-.. automodule:: bb.utils
-   :members:
-   :exclude-members:
-      LogCatcher,
-      PrCtlError,
-      VersionStringException,
-      better_compile,
-      better_exec,
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
deleted file mode 100644
index 4dadf0bc7b..0000000000
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst
+++ /dev/null
@@ -1,2276 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-====================
-Syntax and Operators
-====================
-|
-BitBake files have their own syntax. The syntax has similarities to
-several other languages but also has some unique features. This section
-describes the available syntax and operators as well as provides
-examples.
-Basic Syntax
-============
-This section provides some basic syntax examples.
-Basic Variable Setting
----------------------
-The following example sets ``VARIABLE`` to "value". This assignment
-occurs immediately as the statement is parsed. It is a "hard"
-assignment. ::
-   VARIABLE = "value"
-As expected, if you include leading or
-trailing spaces as part of an assignment, the spaces are retained::
-   VARIABLE = " value"
-   VARIABLE = "value "
-Setting ``VARIABLE`` to "" sets
-it to an empty string, while setting the variable to " " sets it to a
-blank space (i.e. these are not the same values). ::
-   VARIABLE = ""
-   VARIABLE = " "
-You can use single quotes instead of double quotes when setting a
-variable's value. Doing so allows you to use values that contain the
-double quote character::
-   VARIABLE = 'I have a " in my value'
-.. note::
-   Unlike in Bourne shells, single quotes work identically to double
-   quotes in all other ways. They do not suppress variable expansions.
-Modifying Existing Variables
----------------------------
-Sometimes you need to modify existing variables. Following are some
-cases where you might find you want to modify an existing variable:
-  Customize a recipe that uses the variable.
-  Change a variable's default value used in a ``*.bbclass`` file.
-  Change the variable in a ``*.bbappend`` file to override the variable
-   in the original recipe.
-  Change the variable in a configuration file so that the value
-   overrides an existing configuration.
-Changing a variable value can sometimes depend on how the value was
-originally assigned and also on the desired intent of the change. In
-particular, when you append a value to a variable that has a default
-value, the resulting value might not be what you expect. In this case,
-the value you provide might replace the value rather than append to the
-default value.
-If after you have changed a variable's value and something unexplained
-occurs, you can use BitBake to check the actual value of the suspect
-variable. You can make these checks for both configuration and recipe
-level changes:
-  For configuration changes, use the following::
-      $ bitbake -e
-   This
-   command displays variable values after the configuration files (i.e.
-   ``local.conf``, ``bblayers.conf``, ``bitbake.conf`` and so forth)
-   have been parsed.
-   .. note::
-      Variables that are exported to the environment are preceded by the
-      string "export" in the command's output.
-  To find changes to a given variable in a specific recipe, use the
-   following::
-      $ bitbake recipename -e | grep VARIABLENAME=\"
-   This command checks to see if the variable actually makes
-   it into a specific recipe.
-Line Joining
------------
-Outside of :ref:`functions <bitbake-user-manual/bitbake-user-manual-metadata:functions>`,
-BitBake joins any line ending in
-a backslash character ("\\") with the following line before parsing
-statements. The most common use for the "\\" character is to split
-variable assignments over multiple lines, as in the following example::
-   FOO = "bar \
-          baz \
-          qaz"
-Both the "\\" character and the newline
-character that follow it are removed when joining lines. Thus, no
-newline characters end up in the value of ``FOO``.
-Consider this additional example where the two assignments both assign
-"barbaz" to ``FOO``::
-   FOO = "barbaz"
-   FOO = "bar\
-   baz"
-.. note::
-   BitBake does not interpret escape sequences like "\\n" in variable
-   values. For these to have an effect, the value must be passed to some
-   utility that interprets escape sequences, such as
-   ``printf`` or ``echo -n``.
-Variable Expansion
------------------
-Variables can reference the contents of other variables using a syntax
-that is similar to variable expansion in Bourne shells. The following
-assignments result in A containing "aval" and B evaluating to
-"preavalpost". ::
-   A = "aval"
-   B = "pre${A}post"
-.. note::
-   Unlike in Bourne shells, the curly braces are mandatory: Only ``${FOO}`` and not
-   ``$FOO`` is recognized as an expansion of ``FOO``.
-The "=" operator does not immediately expand variable references in the
-right-hand side. Instead, expansion is deferred until the variable
-assigned to is actually used. The result depends on the current values
-of the referenced variables. The following example should clarify this
-behavior::
-   A = "${B} baz"
-   B = "${C} bar"
-   C = "foo"
-   *At this point, ${A} equals "foo bar baz"*
-   C = "qux"
-   *At this point, ${A} equals "qux bar baz"*
-   B = "norf"
-   *At this point, ${A} equals "norf baz"*
-Contrast this behavior with the
-:ref:`bitbake-user-manual/bitbake-user-manual-metadata:immediate variable
-expansion (:=)` operator.
-If the variable expansion syntax is used on a variable that does not
-exist, the string is kept as is. For example, given the following
-assignment, ``BAR`` expands to the literal string "${FOO}" as long as
-``FOO`` does not exist. ::
-   BAR = "${FOO}"
-Setting a default value (?=)
----------------------------
-You can use the "?=" operator to achieve a "softer" assignment for a
-variable. This type of assignment allows you to define a variable if it
-is undefined when the statement is parsed, but to leave the value alone
-if the variable has a value. Here is an example::
-   A ?= "aval"
-If ``A`` is
-set at the time this statement is parsed, the variable retains its
-value. However, if ``A`` is not set, the variable is set to "aval".
-.. note::
-   This assignment is immediate. Consequently, if multiple "?="
-   assignments to a single variable exist, the first of those ends up
-   getting used.
-Setting a weak default value (??=)
----------------------------------
-The weak default value of a variable is the value which that variable
-will expand to if no value has been assigned to it via any of the other
-assignment operators. The "??=" operator takes effect immediately, replacing
-any previously defined weak default value. Here is an example::
-   W ??= "x"
-   A := "${W}" # Immediate variable expansion
-   W ??= "y"
-   B := "${W}" # Immediate variable expansion
-   W ??= "z"
-   C = "${W}"
-   W ?= "i"
-After parsing we will have::
-   A = "x"
-   B = "y"
-   C = "i"
-   W = "i"
-Appending and prepending non-override style will not substitute the weak
-default value, which means that after parsing::
-   W ??= "x"
-   W += "y"
-we will have::
-   W = " y"
-On the other hand, override-style appends/prepends/removes are applied after
-any active weak default value has been substituted::
-   W ??= "x"
-   W:append = "y"
-After parsing we will have::
-   W = "xy"
-Immediate variable expansion (:=)
---------------------------------
-The ":=" operator results in a variable's contents being expanded
-immediately, rather than when the variable is actually used::
-   T = "123"
-   A := "test ${T}"
-   T = "456"
-   B := "${T} ${C}"
-   C = "cval"
-   C := "${C}append"
-In this example, ``A`` contains "test 123", even though the final value
-of :term:`T` is "456". The variable :term:`B` will end up containing "456
-cvalappend". This is because references to undefined variables are
-preserved as is during (immediate)expansion. This is in contrast to GNU
-Make, where undefined variables expand to nothing. The variable ``C``
-contains "cvalappend" since ``${C}`` immediately expands to "cval".
-.. _appending-and-prepending:
-Appending (+=) and prepending (=+) With Spaces
----------------------------------------------
-Appending and prepending values is common and can be accomplished using
-the "+=" and "=+" operators. These operators insert a space between the
-current value and prepended or appended value.
-These operators take immediate effect during parsing. Here are some
-examples::
-   B = "bval"
-   B += "additionaldata"
-   C = "cval"
-   C =+ "test"
-The variable :term:`B` contains "bval additionaldata" and ``C`` contains "test
-cval".
-.. _appending-and-prepending-without-spaces:
-Appending (.=) and Prepending (=.) Without Spaces
-------------------------------------------------
-If you want to append or prepend values without an inserted space, use
-the ".=" and "=." operators.
-These operators take immediate effect during parsing. Here are some
-examples::
-   B = "bval"
-   B .= "additionaldata"
-   C = "cval"
-   C =. "test"
-The variable :term:`B` contains "bvaladditionaldata" and ``C`` contains
-"testcval".
-Appending and Prepending (Override Style Syntax)
------------------------------------------------
-You can also append and prepend a variable's value using an override
-style syntax. When you use this syntax, no spaces are inserted.
-These operators differ from the ":=", ".=", "=.", "+=", and "=+"
-operators in that their effects are applied at variable expansion time
-rather than being immediately applied. Here are some examples::
-   B = "bval"
-   B:append = " additional data"
-   C = "cval"
-   C:prepend = "additional data "
-   D = "dval"
-   D:append = "additional data"
-The variable :term:`B`
-becomes "bval additional data" and ``C`` becomes "additional data cval".
-The variable ``D`` becomes "dvaladditional data".
-.. note::
-   You must control all spacing when you use the override syntax.
-.. note::
-   The overrides are applied in this order, ":append", ":prepend", ":remove".
-It is also possible to append and prepend to shell functions and
-BitBake-style Python functions. See the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:shell functions`" and ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:bitbake-style python functions`"
-sections for examples.
-.. _removing-override-style-syntax:
-Removal (Override Style Syntax)
-------------------------------
-You can remove values from lists using the removal override style
-syntax. Specifying a value for removal causes all occurrences of that
-value to be removed from the variable. Unlike ":append" and ":prepend",
-there is no need to add a leading or trailing space to the value.
-When you use this syntax, BitBake expects one or more strings.
-Surrounding spaces and spacing are preserved. Here is an example::
-   FOO = "123 456 789 123456 123 456 123 456"
-   FOO:remove = "123"
-   FOO:remove = "456"
-   FOO2 = " abc def ghi abcdef abc def abc def def"
-   FOO2:remove = "\
-       def \
-       abc \
-       ghi \
-       "
-The variable ``FOO`` becomes
-"  789 123456    " and ``FOO2`` becomes "    abcdef     ".
-Like ":append" and ":prepend", ":remove" is applied at variable
-expansion time.
-.. note::
-   The overrides are applied in this order, ":append", ":prepend", ":remove".
-   This implies it is not possible to re-append previously removed strings.
-   However, one can undo a ":remove" by using an intermediate variable whose
-   content is passed to the ":remove" so that modifying the intermediate
-   variable equals to keeping the string in::
-     FOOREMOVE = "123 456 789"
-     FOO:remove = "${FOOREMOVE}"
-     ...
-     FOOREMOVE = "123 789"
-   This expands to ``FOO:remove = "123 789"``.
-.. note::
-   Override application order may not match variable parse history, i.e.
-   the output of ``bitbake -e`` may contain ":remove" before ":append",
-   but the result will be removed string, because ":remove" is handled
-   last.
-Override Style Operation Advantages
-----------------------------------
-An advantage of the override style operations ":append", ":prepend", and
-":remove" as compared to the "+=" and "=+" operators is that the
-override style operators provide guaranteed operations. For example,
-consider a class ``foo.bbclass`` that needs to add the value "val" to
-the variable ``FOO``, and a recipe that uses ``foo.bbclass`` as follows::
-   inherit foo
-   FOO = "initial"
-If ``foo.bbclass`` uses the "+=" operator,
-as follows, then the final value of ``FOO`` will be "initial", which is
-not what is desired::
-   FOO += "val"
-If, on the other hand, ``foo.bbclass``
-uses the ":append" operator, then the final value of ``FOO`` will be
-"initial val", as intended::
-   FOO:append = " val"
-.. note::
-   It is never necessary to use "+=" together with ":append". The following
-   sequence of assignments appends "barbaz" to FOO::
-       FOO:append = "bar"
-       FOO:append = "baz"
-   The only effect of changing the second assignment in the previous
-   example to use "+=" would be to add a space before "baz" in the
-   appended value (due to how the "+=" operator works).
-Another advantage of the override style operations is that you can
-combine them with other overrides as described in the
-":ref:`bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`" section.
-Variable Flag Syntax
--------------------
-Variable flags are BitBake's implementation of variable properties or
-attributes. It is a way of tagging extra information onto a variable.
-You can find more out about variable flags in general in the
-":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variable flags`" section.
-You can define, append, and prepend values to variable flags. All the
-standard syntax operations previously mentioned work for variable flags
-except for override style syntax (i.e. ":prepend", ":append", and
-":remove").
-Here are some examples showing how to set variable flags::
-   FOO[a] = "abc"
-   FOO[b] = "123"
-   FOO[a] += "456"
-The variable ``FOO`` has two flags:
-``[a]`` and ``[b]``. The flags are immediately set to "abc" and "123",
-respectively. The ``[a]`` flag becomes "abc 456".
-No need exists to pre-define variable flags. You can simply start using
-them. One extremely common application is to attach some brief
-documentation to a BitBake variable as follows::
-   CACHE[doc] = "The directory holding the cache of the metadata."
-.. note::
-   Variable flag names starting with an underscore (``_``) character
-   are allowed but are ignored by ``d.getVarFlags("VAR")``
-   in Python code. Such flag names are used internally by BitBake.
-Inline Python Variable Expansion
--------------------------------
-You can use inline Python variable expansion to set variables. Here is
-an example::
-   DATE = "${@time.strftime('%Y%m%d',time.gmtime())}"
-This example results in the ``DATE`` variable being set to the current date.
-Probably the most common use of this feature is to extract the value of
-variables from BitBake's internal data dictionary, ``d``. The following
-lines select the values of a package name and its version number,
-respectively::
-   PN = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"
-   PV = "${@bb.parse.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}"
-.. note::
-   Inline Python expressions work just like variable expansions insofar as the
-   "=" and ":=" operators are concerned. Given the following assignment, foo()
-   is called each time FOO is expanded::
-      FOO = "${@foo()}"
-   Contrast this with the following immediate assignment, where foo() is only
-   called once, while the assignment is parsed::
-      FOO := "${@foo()}"
-For a different way to set variables with Python code during parsing,
-see the
-":ref:`bitbake-user-manual/bitbake-user-manual-metadata:anonymous python functions`" section.
-Unsetting variables
-------------------
-It is possible to completely remove a variable or a variable flag from
-BitBake's internal data dictionary by using the "unset" keyword. Here is
-an example::
-   unset DATE
-   unset do_fetch[noexec]
-These two statements remove the ``DATE`` and the ``do_fetch[noexec]`` flag.
-Providing Pathnames
-------------------
-When specifying pathnames for use with BitBake, do not use the tilde
-("~") character as a shortcut for your home directory. Doing so might
-cause BitBake to not recognize the path since BitBake does not expand
-this character in the same way a shell would.
-Instead, provide a fuller path as the following example illustrates::
-   BBLAYERS ?= " \
-       /home/scott-lenovo/LayerA \
-   "
-Exporting Variables to the Environment
-======================================
-You can export variables to the environment of running tasks by using
-the ``export`` keyword. For example, in the following example, the
-``do_foo`` task prints "value from the environment" when run::
-   export ENV_VARIABLE
-   ENV_VARIABLE = "value from the environment"
-   do_foo() {
-       bbplain "$ENV_VARIABLE"
-   }
-.. note::
-   BitBake does not expand ``$ENV_VARIABLE`` in this case because it lacks the
-   obligatory ``{}`` . Rather, ``$ENV_VARIABLE`` is expanded by the shell.
-It does not matter whether ``export ENV_VARIABLE`` appears before or
-after assignments to ``ENV_VARIABLE``.
-It is also possible to combine ``export`` with setting a value for the
-variable. Here is an example::
-   export ENV_VARIABLE = "variable-value"
-In the output of ``bitbake -e``, variables that are exported to the
-environment are preceded by "export".
-Among the variables commonly exported to the environment are ``CC`` and
-``CFLAGS``, which are picked up by many build systems.
-Conditional Syntax (Overrides)
-==============================
-BitBake uses :term:`OVERRIDES` to control what
-variables are overridden after BitBake parses recipes and configuration
-files. This section describes how you can use :term:`OVERRIDES` as
-conditional metadata, talks about key expansion in relationship to
-:term:`OVERRIDES`, and provides some examples to help with understanding.
-Conditional Metadata
--------------------
-You can use :term:`OVERRIDES` to conditionally select a specific version of
-a variable and to conditionally append or prepend the value of a
-variable.
-.. note::
-   Overrides can only use lower-case characters, digits and dashes.
-   In particular, colons are not permitted in override names as they are used to
-   separate overrides from each other and from the variable name.
-  *Selecting a Variable:* The :term:`OVERRIDES` variable is a
-   colon-character-separated list that contains items for which you want
-   to satisfy conditions. Thus, if you have a variable that is
-   conditional on "arm", and "arm" is in :term:`OVERRIDES`, then the
-   "arm"-specific version of the variable is used rather than the
-   non-conditional version. Here is an example::
-      OVERRIDES = "architecture:os:machine"
-      TEST = "default"
-      TEST:os = "osspecific"
-      TEST:nooverride = "othercondvalue"
-   In this example, the :term:`OVERRIDES`
-   variable lists three overrides: "architecture", "os", and "machine".
-   The variable ``TEST`` by itself has a default value of "default". You
-   select the os-specific version of the ``TEST`` variable by appending
-   the "os" override to the variable (i.e. ``TEST:os``).
-   To better understand this, consider a practical example that assumes
-   an OpenEmbedded metadata-based Linux kernel recipe file. The
-   following lines from the recipe file first set the kernel branch
-   variable ``KBRANCH`` to a default value, then conditionally override
-   that value based on the architecture of the build::
-      KBRANCH = "standard/base"
-      KBRANCH:qemuarm = "standard/arm-versatile-926ejs"
-      KBRANCH:qemumips = "standard/mti-malta32"
-      KBRANCH:qemuppc = "standard/qemuppc"
-      KBRANCH:qemux86 = "standard/common-pc/base"
-      KBRANCH:qemux86-64 = "standard/common-pc-64/base"
-      KBRANCH:qemumips64 = "standard/mti-malta64"
-  *Appending and Prepending:* BitBake also supports append and prepend
-   operations to variable values based on whether a specific item is
-   listed in :term:`OVERRIDES`. Here is an example::
-      DEPENDS = "glibc ncurses"
-      OVERRIDES = "machine:local"
-      DEPENDS:append:machine = "libmad"
-   In this example, :term:`DEPENDS` becomes "glibc ncurses libmad".
-   Again, using an OpenEmbedded metadata-based kernel recipe file as an
-   example, the following lines will conditionally append to the
-   ``KERNEL_FEATURES`` variable based on the architecture::
-      KERNEL_FEATURES:append = " ${KERNEL_EXTRA_FEATURES}"
-      KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
-      KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
-  *Setting a Variable for a Single Task:* BitBake supports setting a
-   variable just for the duration of a single task. Here is an example::
-      FOO:task-configure = "val 1"
-      FOO:task-compile = "val 2"
-   In the
-   previous example, ``FOO`` has the value "val 1" while the
-   ``do_configure`` task is executed, and the value "val 2" while the
-   ``do_compile`` task is executed.
-   Internally, this is implemented by prepending the task (e.g.
-   "task-compile:") to the value of
-   :term:`OVERRIDES` for the local datastore of the
-   ``do_compile`` task.
-   You can also use this syntax with other combinations (e.g.
-   "``:prepend``") as shown in the following example::
-      EXTRA_OEMAKE:prepend:task-compile = "${PARALLEL_MAKE} "
-.. note::
-   Before BitBake 1.52 (Honister 3.4), the syntax for :term:`OVERRIDES`
-   used ``_`` instead of ``:``, so you will still find a lot of documentation
-   using ``_append``, ``_prepend``, and ``_remove``, for example.
-   For details, see the
-   :yocto_docs:`Overrides Syntax Changes </migration-guides/migration-3.4.html#override-syntax-changes>`
-   section in the Yocto Project manual migration notes.
-Key Expansion
-------------
-Key expansion happens when the BitBake datastore is finalized. To better
-understand this, consider the following example::
-   A${B} = "X"
-   B = "2"
-   A2 = "Y"
-In this case, after all the parsing is complete, BitBake expands
-``${B}`` into "2". This expansion causes ``A2``, which was set to "Y"
-before the expansion, to become "X".
-.. _variable-interaction-worked-examples:
-Examples
--------
-Despite the previous explanations that show the different forms of
-variable definitions, it can be hard to work out exactly what happens
-when variable operators, conditional overrides, and unconditional
-overrides are combined. This section presents some common scenarios
-along with explanations for variable interactions that typically confuse
-users.
-There is often confusion concerning the order in which overrides and
-various "append" operators take effect. Recall that an append or prepend
-operation using ":append" and ":prepend" does not result in an immediate
-assignment as would "+=", ".=", "=+", or "=.". Consider the following
-example::
-   OVERRIDES = "foo"
-   A = "Z"
-   A:foo:append = "X"
-For this case,
-``A`` is unconditionally set to "Z" and "X" is unconditionally and
-immediately appended to the variable ``A:foo``. Because overrides have
-not been applied yet, ``A:foo`` is set to "X" due to the append and
-``A`` simply equals "Z".
-Applying overrides, however, changes things. Since "foo" is listed in
-:term:`OVERRIDES`, the conditional variable ``A`` is replaced with the "foo"
-version, which is equal to "X". So effectively, ``A:foo`` replaces
-``A``.
-This next example changes the order of the override and the append::
-   OVERRIDES = "foo"
-   A = "Z"
-   A:append:foo = "X"
-For this case, before
-overrides are handled, ``A`` is set to "Z" and ``A:append:foo`` is set
-to "X". Once the override for "foo" is applied, however, ``A`` gets
-appended with "X". Consequently, ``A`` becomes "ZX". Notice that spaces
-are not appended.
-This next example has the order of the appends and overrides reversed
-back as in the first example::
-   OVERRIDES = "foo"
-   A = "Y"
-   A:foo:append = "Z"
-   A:foo:append = "X"
-For this case, before any overrides are resolved,
-``A`` is set to "Y" using an immediate assignment. After this immediate
-assignment, ``A:foo`` is set to "Z", and then further appended with "X"
-leaving the variable set to "ZX". Finally, applying the override for
-"foo" results in the conditional variable ``A`` becoming "ZX" (i.e.
-``A`` is replaced with ``A:foo``).
-This final example mixes in some varying operators::
-   A = "1"
-   A:append = "2"
-   A:append = "3"
-   A += "4"
-   A .= "5"
-For this case, the type of append
-operators are affecting the order of assignments as BitBake passes
-through the code multiple times. Initially, ``A`` is set to "1 45"
-because of the three statements that use immediate operators. After
-these assignments are made, BitBake applies the ":append" operations.
-Those operations result in ``A`` becoming "1 4523".
-Sharing Functionality
-=====================
-BitBake allows for metadata sharing through include files (``.inc``) and
-class files (``.bbclass``). For example, suppose you have a piece of
-common functionality such as a task definition that you want to share
-between more than one recipe. In this case, creating a ``.bbclass`` file
-that contains the common functionality and then using the ``inherit``
-directive in your recipes to inherit the class would be a common way to
-share the task.
-This section presents the mechanisms BitBake provides to allow you to
-share functionality between recipes. Specifically, the mechanisms
-include ``include``, ``inherit``, :term:`INHERIT`, and ``require``
-directives. There is also a higher-level abstraction called
-``configuration fragments`` that is enabled with ``addfragments``
-directive.
-.. _ref-bitbake-user-manual-metadata-inherit:
-``inherit`` Directive
---------------------
-When writing a recipe or class file, you can use the ``inherit``
-directive to inherit the functionality of a class (``.bbclass``).
-BitBake only supports this directive when used within recipe and class
-files (i.e. ``.bb`` and ``.bbclass``).
-The ``inherit`` directive is a rudimentary means of specifying
-functionality contained in class files that your recipes require. For
-example, you can easily abstract out the tasks involved in building a
-package that uses Autoconf and Automake and put those tasks into a class
-file and then have your recipe inherit that class file.
-As an example, your recipes could use the following directive to inherit
-an ``autotools.bbclass`` file. The class file would contain common
-functionality for using Autotools that could be shared across recipes::
-   inherit autotools
-In this case, BitBake would search for the directory
-``classes/autotools.bbclass`` in :term:`BBPATH`.
-.. note::
-   You can override any values and functions of the inherited class
-   within your recipe by doing so after the "inherit" statement.
-If you want to use the directive to inherit multiple classes, separate
-them with spaces. The following example shows how to inherit both the
-``buildhistory`` and ``rm_work`` classes::
-   inherit buildhistory rm_work
-An advantage with the inherit directive as compared to both the
-:ref:`include <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>` and :ref:`require <bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>`
-directives is that you can inherit class files conditionally. You can
-accomplish this by using a variable expression after the ``inherit``
-statement.
-For inheriting classes conditionally, using the :ref:`inherit_defer
-<ref-bitbake-user-manual-metadata-inherit-defer>` directive is advised as
-:ref:`inherit_defer <ref-bitbake-user-manual-metadata-inherit-defer>` is
-evaluated at the end of parsing.
-.. _ref-bitbake-user-manual-metadata-inherit-defer:
-``inherit_defer`` Directive
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The :ref:`inherit_defer <ref-bitbake-user-manual-metadata-inherit-defer>`
-directive works like the :ref:`inherit
-<ref-bitbake-user-manual-metadata-inherit>` directive, except that it is only
-evaluated at the end of parsing. Its usage is recommended when a conditional
-expression is used.
-This allows conditional expressions to be evaluated "late", meaning changes to
-the variable after the line is parsed will take effect. With the :ref:`inherit
-<ref-bitbake-user-manual-metadata-inherit>` directive this is not the case.
-Here is an example::
-   inherit_defer ${VARNAME}
-If ``VARNAME`` is
-going to be set, it needs to be set before the ``inherit_defer`` statement is
-parsed. One way to achieve a conditional inherit in this case is to use
-overrides::
-   VARIABLE = ""
-   VARIABLE:someoverride = "myclass"
-Another method is by using :ref:`anonymous Python
-<bitbake-user-manual/bitbake-user-manual-metadata:Anonymous Python Functions>`.
-Here is an example::
-   python () {
-       if condition == value:
-           d.setVar('VARIABLE', 'myclass')
-       else:
-           d.setVar('VARIABLE', '')
-   }
-Alternatively, you could use an inline Python expression in the
-following form::
-   inherit_defer ${@'classname' if condition else ''}
-Or::
-   inherit_defer ${@bb.utils.contains('VARIABLE', 'something', 'classname', '', d)}
-In all cases, if the expression evaluates to an
-empty string, the statement does not trigger a syntax error because it
-becomes a no-op.
-See also :term:`BB_DEFER_BBCLASSES` for automatically promoting classes
-``inherit`` calls to ``inherit_defer``.
-.. _ref-include-directive:
-``include`` Directive
---------------------
-The ``include`` directive causes BitBake to parse a given file,
-and to include that file's contents at the location of the
-``include`` statement. This directive is similar to its equivalent
-in Make, except that if the path specified on the BitBake ``include``
-line is a relative path, BitBake will search for it on the path designated
-by :term:`BBPATH` and will include *only the first matching file*.
-The ``include`` directive is a more generic method of including
-functionality as compared to the :ref:`inherit <bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` directive>`
-directive, which is restricted to class (i.e. ``.bbclass``) files. The
-``include`` directive is applicable for any other kind of shared or
-encapsulated functionality or configuration that does not suit a
-``.bbclass`` file.
-For example, if you needed a recipe to include some self-test definitions,
-you might write::
-   include test_defs.inc
-The ``include`` directive does not produce an error if the specified file
-cannot be found. If the included file *must* exist, then you should use
-use :ref:`require <require-inclusion>` instead, which will generate an error
-if the file cannot be found.
-.. note::
-   Note well that the ``include`` directive will include the first matching
-   file and nothing further (which is almost always the behaviour you want).
-   If you need to include all matching files, you need to use the
-   ``include_all`` directive, explained below.
-.. _ref-include-all-directive:
-``include_all`` Directive
-------------------------
-The ``include_all`` directive works like the :ref:`include
-<bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>`
-directive but will include *all* of the files that match the specified path in
-the enabled layers (layers part of :term:`BBLAYERS`).
-.. note::
-   This behaviour is rarely what you want in normal operation, and should
-   be reserved for only those situations when you explicitly want to parse
-   and include all matching files found across all layers, as the following
-   example shows.
-As a realistic example of this directive, imagine that all of your active
-layers contain a file ``conf/distro/include/maintainers.inc``, containing
-maintainer information for the recipes in that layer, and you wanted to
-collect all of the content from all of those files across all of those layers.
-You could use the statement::
-   include_all conf/distro/include/maintainers.inc
-In this case, BitBake will iterate through all of the directories in
-the colon-separated :term:`BBPATH` (from left to right) and collect the
-contents of all matching files, so you end up with the maintainer
-information of all of your active layers, not just the first one.
-As the ``include_all`` directive uses the ``include`` directive in the
-background, as with ``include``, no error is produced if no files are matched.
-.. _require-inclusion:
-``require`` Directive
---------------------
-BitBake understands the ``require`` directive. This directive behaves
-just like the ``include`` directive with the exception that BitBake
-raises a parsing error if the file to be included cannot be found. Thus,
-any file you require is inserted into the file that is being parsed at
-the location of the directive.
-The require directive, like the include directive previously described,
-is a more generic method of including functionality as compared to the
-:ref:`inherit <bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` directive>` directive, which is restricted to class
-(i.e. ``.bbclass``) files. The require directive is applicable for any
-other kind of shared or encapsulated functionality or configuration that
-does not suit a ``.bbclass`` file.
-Similar to how BitBake handles :ref:`include <bitbake-user-manual/bitbake-user-manual-metadata:\`\`include\`\` directive>`, if
-the path specified on the require line is a relative path, BitBake
-locates the first file it can find within :term:`BBPATH`.
-As an example, suppose you have two versions of a recipe (e.g.
-``foo_1.2.2.bb`` and ``foo_2.0.0.bb``) where each version contains some
-identical functionality that could be shared. You could create an
-include file named ``foo.inc`` that contains the common definitions
-needed to build "foo". You need to be sure ``foo.inc`` is located in the
-same directory as your two recipe files as well. Once these conditions
-are set up, you can share the functionality using a ``require``
-directive from within each recipe::
-   require foo.inc
-``INHERIT`` Configuration Directive
-----------------------------------
-When creating a configuration file (``.conf``), you can use the
-:term:`INHERIT` configuration directive to inherit a
-class. BitBake only supports this directive when used within a
-configuration file.
-As an example, suppose you needed to inherit a class file called
-``abc.bbclass`` from a configuration file as follows::
-   INHERIT += "abc"
-This configuration directive causes the named class to be inherited at
-the point of the directive during parsing. As with the ``inherit``
-directive, the ``.bbclass`` file must be located in a "classes"
-subdirectory in one of the directories specified in :term:`BBPATH`.
-.. note::
-   Because .conf files are parsed first during BitBake's execution, using
-   INHERIT to inherit a class effectively inherits the class globally (i.e. for
-   all recipes).
-If you want to use the directive to inherit multiple classes, you can
-provide them on the same line in the ``local.conf`` file. Use spaces to
-separate the classes. The following example shows how to inherit both
-the ``autotools`` and ``pkgconfig`` classes::
-   INHERIT += "autotools pkgconfig"
-``addfragments`` Directive
--------------------------
-This directive allows fine-tuning local configurations with configuration
-snippets contained in layers in a structured, controlled way. Typically it would
-go into ``bitbake.conf``, for example::
-   addfragments conf/fragments OE_FRAGMENTS OE_FRAGMENTS_METADATA_VARS OE_BUILTIN_FRAGMENTS
-``addfragments`` takes four parameters:
-  path prefix for fragment files inside the layer file tree that bitbake
-   uses to construct full paths to the fragment files
-  name of variable that holds the list of enabled fragments in an
-   active build
-  name of variable that contains a list of variable names containing
-   fragment-specific metadata (such as descriptions)
-  name of variable that contains definitions for built-in fragments
-This allows listing enabled configuration fragments in ``OE_FRAGMENTS``
-variable like this::
-   OE_FRAGMENTS = "core/domain/somefragment core/someotherfragment anotherlayer/anotherdomain/anotherfragment"
-Fragment names listed in this variable must be prefixed by the layer name
-where a fragment file is located, defined by :term:`BBFILE_COLLECTIONS` in ``layer.conf``.
-The implementation then expands this list into
-:ref:`require <bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>`
-directives with full paths to respective layers::
-   require /path/to/core-layer/conf/fragments/domain/somefragment.conf
-   require /path/to/core-layer/conf/fragments/someotherfragment.conf
-   require /path/to/another-layer/conf/fragments/anotherdomain/anotherfragment.conf
-The variable containing a list of fragment metadata variables could look like this::
-   OE_FRAGMENTS_METADATA_VARS = "BB_CONF_FRAGMENT_SUMMARY BB_CONF_FRAGMENT_DESCRIPTION"
-The implementation will add a flag containing the fragment name to each of those variables
-when parsing fragments, so that the variables are namespaced by fragment name, and do not override
-each other when several fragments are enabled.
-The variable containing a built-in fragment definitions could look like this::
-   OE_BUILTIN_FRAGMENTS = "someprefix:SOMEVARIABLE anotherprefix:ANOTHERVARIABLE"
-and then if 'someprefix/somevalue' is added to the variable that holds the list
-of enabled fragments:
-  OE_FRAGMENTS = "... someprefix/somevalue"
-bitbake will treat that as direct value assignment in its configuration::
-  SOMEVARIABLE = "somevalue"
-Locating Include Files
----------------------
-BitBake uses the :term:`BBPATH` variable to locate needed include files.
-Additionally, BitBake searches the current directory for :ref:`include
-<ref-include-directive>` and :ref:`require <require-inclusion>` directives.
-.. note::
-   The BBPATH variable is analogous to the environment variable PATH .
-For these two directives, BitBake includes the first file it finds.
-.. note::
-   It is also possible to include *all* occurences of a file with the same name
-   with the :ref:`include_all <ref-include-all-directive>` directive.
-Let's consider the following statement called from a recipe file located in
-``/layers/meta-custom2/recipes-example/example_0.1.bb``::
-   require myfile.inc
-Where ``myfile.inc`` is located in ``/layers/meta-custom2/recipes-example/``.
-And let's assume that the value of :term:`BBPATH` is
-``/layers/meta-custom1:/layers/meta-custom2``. Then BitBake will try to find
-``myfile.inc`` in this order::
-   /layers/meta-custom2/recipes-example/example/myfile.inc
-   /layers/meta-custom1/myfile.inc
-   /layers/meta-custom2/myfile.inc
-In this case the first path of the list matches and BitBake includes this file
-in ``example_0.1.bb``.
-Another common example would be::
-   require recipes-other/other/otherfile.inc
-Where ``otherfile.inc`` is located in
-``/layers/meta-custom1/recipes-other/other/``.
-In this case, the following paths would be searched::
-   /layers/meta-custom2/recipes-example/example/recipes-other/other/otherfile.inc
-   /layers/meta-custom1/recipes-other/other/otherfile.inc
-   /layers/meta-custom2/recipes-other/other/otherfile.inc
-This time, the second item of this list would be matched.
-.. note::
-   In the above examples, the exact same search order applies for the
-   :ref:`include <ref-include-directive>` directive.
-Locating Class Files
--------------------
-Like include files, class files are located using the :term:`BBPATH` variable.
-The classes can be included in the ``classes-recipe``, ``classes-global`` and
-``classes`` directories, as explained in the
-:ref:`bitbake-user-manual/bitbake-user-manual-intro:Class types` section of the
-Bitbake User Manual. Like for the :ref:`include <ref-include-directive>` and
-:ref:`require <require-inclusion>` directives, BitBake stops and inherits the
-first class that it finds.
-For classes inherited with the :ref:`inherit
-<ref-bitbake-user-manual-metadata-inherit>` directive, BitBake will try to
-locate the class under each ``classes-recipe`` directory for each path in
-:term:`BBPATH`, and then do the same for each ``classes`` directory for each
-path in :term:`BBPATH`.
-For example, if the value :term:`BBPATH` is
-``/layers/meta-custom1:/layers/meta-custom2`` then the ``hello`` class
-would be searched in this order::
-   /layers/meta-custom1/classes-recipe/hello.bbclass
-   /layers/meta-custom2/classes-recipe/hello.bbclass
-   /layers/meta-custom1/classes/hello.bbclass
-   /layers/meta-custom2/classes/hello.bbclass
-.. note::
-   Note that the order of the list above does not depend on where the class in
-   inherited from.
-Likewise, for classes inherited with the :term:`INHERIT` variable, the
-``classes-global`` directory is searched first, and the ``classes`` directory is
-searched second. Taking the above example, this would result in the following
-list::
-   /layers/meta-custom1/classes-global/hello.bbclass
-   /layers/meta-custom2/classes-global/hello.bbclass
-   /layers/meta-custom1/classes/hello.bbclass
-   /layers/meta-custom2/classes/hello.bbclass
-Functions
-=========
-As with most languages, functions are the building blocks that are used
-to build up operations into tasks. BitBake supports these types of
-functions:
-  *Shell Functions:* Functions written in shell script and executed
-   either directly as functions, tasks, or both. They can also be called
-   by other shell functions.
-  *BitBake-Style Python Functions:* Functions written in Python and
-   executed by BitBake or other Python functions using
-   ``bb.build.exec_func()``.
-  *Python Functions:* Functions written in Python and executed by
-   Python.
-  *Anonymous Python Functions:* Python functions executed automatically
-   during parsing.
-Regardless of the type of function, you can only define them in class
-(``.bbclass``) and recipe (``.bb`` or ``.inc``) files.
-Shell Functions
---------------
-Functions written in shell script are executed either directly as
-functions, tasks, or both. They can also be called by other shell
-functions. Here is an example shell function definition::
-   some_function () {
-       echo "Hello World"
-   }
-When you create these types of functions in
-your recipe or class files, you need to follow the shell programming
-rules. The scripts are executed by ``/bin/sh``, which may not be a bash
-shell but might be something such as ``dash``. You should not use
-Bash-specific script (bashisms).
-Overrides and override-style operators like ``:append`` and ``:prepend``
-can also be applied to shell functions. Most commonly, this application
-would be used in a ``.bbappend`` file to modify functions in the main
-recipe. It can also be used to modify functions inherited from classes.
-As an example, consider the following::
-   do_foo() {
-       bbplain first
-       fn
-   }
-   fn:prepend() {
-       bbplain second
-   }
-   fn() {
-       bbplain third
-   }
-   do_foo:append() {
-       bbplain fourth
-   }
-Running ``do_foo`` prints the following::
-   recipename do_foo: first
-   recipename do_foo: second
-   recipename do_foo: third
-   recipename do_foo: fourth
-.. note::
-   Overrides and override-style operators can be applied to any shell
-   function, not just :ref:`tasks <bitbake-user-manual/bitbake-user-manual-metadata:tasks>`.
-You can use the ``bitbake -e recipename`` command to view the final
-assembled function after all overrides have been applied.
-BitBake-Style Python Functions
------------------------------
-These functions are written in Python and executed by BitBake or other
-Python functions using ``bb.build.exec_func()``.
-An example BitBake function is::
-   python some_python_function () {
-       d.setVar("TEXT", "Hello World")
-       print d.getVar("TEXT")
-   }
-Because the
-Python "bb" and "os" modules are already imported, you do not need to
-import these modules. Also in these types of functions, the datastore
-("d") is a global variable and is always automatically available.
-.. note::
-   Variable expressions (e.g.  ``${X}`` ) are no longer expanded within Python
-   functions. This behavior is intentional in order to allow you to freely set
-   variable values to expandable expressions without having them expanded
-   prematurely. If you do wish to expand a variable within a Python function,
-   use ``d.getVar("X")`` . Or, for more complicated expressions, use ``d.expand()``.
-Similar to shell functions, you can also apply overrides and
-override-style operators to BitBake-style Python functions.
-As an example, consider the following::
-   python do_foo:prepend() {
-       bb.plain("first")
-   }
-   python do_foo() {
-       bb.plain("second")
-   }
-   python do_foo:append() {
-       bb.plain("third")
-   }
-Running ``do_foo`` prints the following::
-   recipename do_foo: first
-   recipename do_foo: second
-   recipename do_foo: third
-You can use the ``bitbake -e recipename`` command to view
-the final assembled function after all overrides have been applied.
-Python Functions
----------------
-These functions are written in Python and are executed by other Python
-code. Examples of Python functions are utility functions that you intend
-to call from in-line Python or from within other Python functions. Here
-is an example::
-   def get_depends(d):
-       if d.getVar('SOMECONDITION'):
-           return "dependencywithcond"
-       else:
-           return "dependency"
-   SOMECONDITION = "1"
-   DEPENDS = "${@get_depends(d)}"
-This would result in :term:`DEPENDS` containing ``dependencywithcond``.
-Here are some things to know about Python functions:
-  Python functions can take parameters.
-  The BitBake datastore is not automatically available. Consequently,
-   you must pass it in as a parameter to the function.
-  The "bb" and "os" Python modules are automatically available. You do
-   not need to import them.
-BitBake-Style Python Functions Versus Python Functions
------------------------------------------------------
-Following are some important differences between BitBake-style Python
-functions and regular Python functions defined with "def":
-  Only BitBake-style Python functions can be :ref:`tasks <bitbake-user-manual/bitbake-user-manual-metadata:tasks>`.
-  Overrides and override-style operators can only be applied to
-   BitBake-style Python functions.
-  Only regular Python functions can take arguments and return values.
-  :ref:`Variable flags <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>` such as
-   ``[dirs]``, ``[cleandirs]``, and ``[lockfiles]`` can be used on BitBake-style
-   Python functions, but not on regular Python functions.
-  BitBake-style Python functions generate a separate
-   ``${``\ :term:`T`\ ``}/run.``\ function-name\ ``.``\ pid
-   script that is executed to run the function, and also generate a log
-   file in ``${T}/log.``\ function-name\ ``.``\ pid if they are executed
-   as tasks.
-   Regular Python functions execute "inline" and do not generate any
-   files in ``${T}``.
-  Regular Python functions are called with the usual Python syntax.
-   BitBake-style Python functions are usually tasks and are called
-   directly by BitBake, but can also be called manually from Python code
-   by using the ``bb.build.exec_func()`` function. Here is an example::
-      bb.build.exec_func("my_bitbake_style_function", d)
-   .. note::
-      ``bb.build.exec_func()`` can also be used to run shell functions from Python
-      code. If you want to run a shell function before a Python function within
-      the same task, then you can use a parent helper Python function that
-      starts by running the shell function with ``bb.build.exec_func()`` and then
-      runs the Python code.
-   To detect errors from functions executed with
-   ``bb.build.exec_func()``, you can catch the ``bb.build.FuncFailed``
-   exception.
-   .. note::
-      Functions in metadata (recipes and classes) should not themselves raise
-      ``bb.build.FuncFailed``. Rather, ``bb.build.FuncFailed`` should be viewed as a
-      general indicator that the called function failed by raising an
-      exception. For example, an exception raised by ``bb.fatal()`` will be caught
-      inside ``bb.build.exec_func()``, and a ``bb.build.FuncFailed`` will be raised in
-      response.
-Due to their simplicity, you should prefer regular Python functions over
-BitBake-style Python functions unless you need a feature specific to
-BitBake-style Python functions. Regular Python functions in metadata are
-a more recent invention than BitBake-style Python functions, and older
-code tends to use ``bb.build.exec_func()`` more often.
-Anonymous Python Functions
--------------------------
-Sometimes it is useful to set variables or perform other operations
-programmatically during parsing. To do this, you can define special
-Python functions, called anonymous Python functions, that run at the end
-of parsing. For example, the following conditionally sets a variable
-based on the value of another variable::
-   python () {
-       if d.getVar('SOMEVAR') == 'value':
-           d.setVar('ANOTHERVAR', 'value2')
-   }
-An equivalent way to mark a function as an anonymous function is to give it
-the name "__anonymous", rather than no name.
-Anonymous Python functions always run at the end of parsing, regardless
-of where they are defined. If a recipe contains many anonymous
-functions, they run in the same order as they are defined within the
-recipe. As an example, consider the following snippet::
-   python () {
-       d.setVar('FOO', 'foo 2')
-   }
-   FOO = "foo 1"
-   python () {
-       d.appendVar('BAR',' bar 2')
-   }
-   BAR = "bar 1"
-The previous example is conceptually
-equivalent to the following snippet::
-   FOO = "foo 1"
-   BAR = "bar 1"
-   FOO = "foo 2"
-   BAR += "bar 2"
-``FOO`` ends up with the value "foo 2", and
-``BAR`` with the value "bar 1 bar 2". Just as in the second snippet, the
-values set for the variables within the anonymous functions become
-available to tasks, which always run after parsing.
-Overrides and override-style operators such as "``:append``" are applied
-before anonymous functions run. In the following example, ``FOO`` ends
-up with the value "foo from anonymous"::
-   FOO = "foo"
-   FOO:append = " from outside"
-   python () {
-       d.setVar("FOO", "foo from anonymous")
-   }
-For methods
-you can use with anonymous Python functions, see the
-":ref:`bitbake-user-manual/bitbake-user-manual-metadata:functions you can call from within python`"
-section. For a different method to run Python code during parsing, see
-the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:inline python variable expansion`" section.
-Flexible Inheritance for Class Functions
----------------------------------------
-Through coding techniques and the use of ``EXPORT_FUNCTIONS``, BitBake
-supports exporting a function from a class such that the class function
-appears as the default implementation of the function, but can still be
-called if a recipe inheriting the class needs to define its own version
-of the function.
-To understand the benefits of this feature, consider the basic scenario
-where a class defines a task function and your recipe inherits the
-class. In this basic scenario, your recipe inherits the task function as
-defined in the class. If desired, your recipe can add to the start and
-end of the function by using the ":prepend" or ":append" operations
-respectively, or it can redefine the function completely. However, if it
-redefines the function, there is no means for it to call the class
-version of the function. ``EXPORT_FUNCTIONS`` provides a mechanism that
-enables the recipe's version of the function to call the original
-version of the function.
-To make use of this technique, you need the following things in place:
-  The class needs to define the function as follows::
-      classname_functionname
-   For example, if you have a class file
-   ``bar.bbclass`` and a function named ``do_foo``, the class must
-   define the function as follows::
-      bar_do_foo
-  The class needs to contain the ``EXPORT_FUNCTIONS`` statement as
-   follows::
-      EXPORT_FUNCTIONS functionname
-   For example, continuing with
-   the same example, the statement in the ``bar.bbclass`` would be as
-   follows::
-      EXPORT_FUNCTIONS do_foo
-  You need to call the function appropriately from within your recipe.
-   Continuing with the same example, if your recipe needs to call the
-   class version of the function, it should call ``bar_do_foo``.
-   Assuming ``do_foo`` was a shell function and ``EXPORT_FUNCTIONS`` was
-   used as above, the recipe's function could conditionally call the
-   class version of the function as follows::
-      do_foo() {
-          if [ somecondition ] ; then
-              bar_do_foo
-          else
-              # Do something else
-          fi
-      }
-   To call your modified version of the function as defined in your recipe,
-   call it as ``do_foo``.
-With these conditions met, your single recipe can freely choose between
-the original function as defined in the class file and the modified
-function in your recipe. If you do not set up these conditions, you are
-limited to using one function or the other.
-Tasks
-=====
-Tasks are BitBake execution units that make up the steps that BitBake
-can run for a given recipe. Tasks are only supported in recipes and
-classes (i.e. in ``.bb`` files and files included or inherited from
-``.bb`` files). By convention, tasks have names that start with "do\_".
-Promoting a Function to a Task
------------------------------
-Tasks are either :ref:`shell functions <bitbake-user-manual/bitbake-user-manual-metadata:shell functions>` or
-:ref:`BitBake-style Python functions <bitbake-user-manual/bitbake-user-manual-metadata:bitbake-style python functions>`
-that have been promoted to tasks by using the ``addtask`` command. The
-``addtask`` command can also optionally describe dependencies between
-the task and other tasks. Here is an example that shows how to define a
-task and declare some dependencies::
-   python do_printdate () {
-       import datetime
-       bb.plain('Date: %s' % (datetime.date.today()))
-   }
-   addtask printdate after do_fetch before do_build
-The first argument to ``addtask`` is the name
-of the function to promote to a task. If the name does not start with
-"do\_", "do\_" is implicitly added, which enforces the convention that all
-task names start with "do\_".
-In the previous example, the ``do_printdate`` task becomes a dependency
-of the ``do_build`` task, which is the default task (i.e. the task run
-by the ``bitbake`` command unless another task is specified explicitly).
-Additionally, the ``do_printdate`` task becomes dependent upon the
-``do_fetch`` task. Running the ``do_build`` task results in the
-``do_printdate`` task running first.
-.. note::
-   If you try out the previous example, you might see that the
-   ``do_printdate``
-   task is only run the first time you build the recipe with the
-   ``bitbake``
-   command. This is because BitBake considers the task "up-to-date"
-   after that initial run. If you want to force the task to always be
-   rerun for experimentation purposes, you can make BitBake always
-   consider the task "out-of-date" by using the
-   :ref:`[nostamp] <bitbake-user-manual/bitbake-user-manual-metadata:Variable Flags>`
-   variable flag, as follows::
-      do_printdate[nostamp] = "1"
-   You can also explicitly run the task and provide the
-   -f option as follows::
-      $ bitbake recipe -c printdate -f
-   When manually selecting a task to run with the bitbake ``recipe
-   -c task`` command, you can omit the "do\_" prefix as part of the task
-   name.
-You might wonder about the practical effects of using ``addtask``
-without specifying any dependencies as is done in the following example::
-   addtask printdate
-In this example, assuming dependencies have not been
-added through some other means, the only way to run the task is by
-explicitly selecting it with ``bitbake`` recipe ``-c printdate``. You
-can use the ``do_listtasks`` task to list all tasks defined in a recipe
-as shown in the following example::
-   $ bitbake recipe -c listtasks
-For more information on task dependencies, see the
-":ref:`bitbake-user-manual/bitbake-user-manual-execution:dependencies`" section.
-See the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variable flags`" section for information
-on variable flags you can use with tasks.
-.. note::
-   While it's infrequent, it's possible to define multiple tasks as
-   dependencies when calling ``addtask``. For example, here's a snippet
-   from the OpenEmbedded class file ``package_tar.bbclass``::
-     addtask package_write_tar before do_build after do_packagedata do_package
-   Note how the ``package_write_tar`` task has to wait until both of
-   ``do_packagedata`` and ``do_package`` complete.
-Deleting a Task
---------------
-As well as being able to add tasks, you can delete them. Simply use the
-``deltask`` command to delete a task. For example, to delete the example
-task used in the previous sections, you would use::
-   deltask printdate
-If you delete a task using the ``deltask`` command and the task has
-dependencies, the dependencies are not reconnected. For example, suppose
-you have three tasks named ``do_a``, ``do_b``, and ``do_c``.
-Furthermore, ``do_c`` is dependent on ``do_b``, which in turn is
-dependent on ``do_a``. Given this scenario, if you use ``deltask`` to
-delete ``do_b``, the implicit dependency relationship between ``do_c``
-and ``do_a`` through ``do_b`` no longer exists, and ``do_c``
-dependencies are not updated to include ``do_a``. Thus, ``do_c`` is free
-to run before ``do_a``.
-If you want dependencies such as these to remain intact, use the
-``[noexec]`` varflag to disable the task instead of using the
-``deltask`` command to delete it::
-   do_b[noexec] = "1"
-Passing Information Into the Build Task Environment
---------------------------------------------------
-When running a task, BitBake tightly controls the shell execution
-environment of the build tasks to make sure unwanted contamination from
-the build machine cannot influence the build.
-.. note::
-   By default, BitBake cleans the environment to include only those
-   things exported or listed in its passthrough list to ensure that the
-   build environment is reproducible and consistent. You can prevent this
-   "cleaning" by setting the :term:`BB_PRESERVE_ENV` variable.
-Consequently, if you do want something to get passed into the build task
-environment, you must take these two steps:
-#. Tell BitBake to load what you want from the environment into the
-   datastore. You can do so through the
-   :term:`BB_ENV_PASSTHROUGH` and
-   :term:`BB_ENV_PASSTHROUGH_ADDITIONS` variables. For
-   example, assume you want to prevent the build system from accessing
-   your ``$HOME/.ccache`` directory. The following command adds the
-   the environment variable ``CCACHE_DIR`` to BitBake's passthrough
-   list to allow that variable into the datastore::
-      export BB_ENV_PASSTHROUGH_ADDITIONS="$BB_ENV_PASSTHROUGH_ADDITIONS CCACHE_DIR"
-#. Tell BitBake to export what you have loaded into the datastore to the
-   task environment of every running task. Loading something from the
-   environment into the datastore (previous step) only makes it
-   available in the datastore. To export it to the task environment of
-   every running task, use a command similar to the following in your
-   local configuration file ``local.conf`` or your distribution
-   configuration file::
-      export CCACHE_DIR
-   .. note::
-      A side effect of the previous steps is that BitBake records the
-      variable as a dependency of the build process in things like the
-      setscene checksums. If doing so results in unnecessary rebuilds of
-      tasks, you can also flag the variable so that the setscene code
-      ignores the dependency when it creates checksums.
-Sometimes, it is useful to be able to obtain information from the
-original execution environment. BitBake saves a copy of the original
-environment into a special variable named :term:`BB_ORIGENV`.
-The :term:`BB_ORIGENV` variable returns a datastore object that can be
-queried using the standard datastore operators such as
-``getVar(, False)``. The datastore object is useful, for example, to
-find the original ``DISPLAY`` variable. Here is an example::
-   origenv = d.getVar("BB_ORIGENV", False)
-   bar = origenv.getVar("BAR", False)
-The previous example returns ``BAR`` from the original execution
-environment.
-Variable Flags
-==============
-Variable flags (varflags) help control a task's functionality and
-dependencies. BitBake reads and writes varflags to the datastore using
-the following command forms::
-   variable = d.getVarFlags("variable")
-   self.d.setVarFlags("FOO", {"func": True})
-When working with varflags, the same syntax, with the exception of
-overrides, applies. In other words, you can set, append, and prepend
-varflags just like variables. See the
-":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variable flag syntax`" section for details.
-BitBake has a defined set of varflags available for recipes and classes.
-Tasks support a number of these flags which control various
-functionality of the task:
-  ``[cleandirs]``: Empty directories that should be created before
-   the task runs. Directories that already exist are removed and
-   recreated to empty them.
-  ``[depends]``: Controls inter-task dependencies. See the
-   :term:`DEPENDS` variable and the
-   ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:inter-task
-   dependencies`" section for more information.
-  ``[deptask]``: Controls task build-time dependencies. See the
-   :term:`DEPENDS` variable and the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:build dependencies`" section for more information.
-  ``[dirs]``: Directories that should be created before the task
-   runs. Directories that already exist are left as is. The last
-   directory listed is used as the current working directory for the
-   task.
- ``[file-checksums]``: Controls the file dependencies for a task. The
-  baseline file list is the set of files associated with
-  :term:`SRC_URI`. May be used to set additional dependencies on
-  files not associated with :term:`SRC_URI`.
-  The value set to the list is a file-boolean pair where the first
-  value is the file name and the second is whether or not it
-  physically exists on the filesystem. ::
-    do_configure[file-checksums] += "${MY_DIRPATH}/my-file.txt:True"
-  It is important to record any paths which the task looked at and
-  which didn't exist. This means that if these do exist at a later
-  time, the task can be rerun with the new additional files. The
-  "exists" True or False value after the path allows this to be
-  handled.
-  ``[lockfiles]``: Specifies one or more lockfiles to lock while the
-   task executes. Only one task may hold a lockfile, and any task that
-   attempts to lock an already locked file will block until the lock is
-   released. You can use this variable flag to accomplish mutual
-   exclusion.
-  ``[network]``: When set to "1", allows a task to access the network. By
-   default, only the ``do_fetch`` task is granted network access. Recipes
-   shouldn't access the network outside of ``do_fetch`` as it usually
-   undermines fetcher source mirroring, image and licence manifests, software
-   auditing and supply chain security.
-  ``[noexec]``: When set to "1", marks the task as being empty, with
-   no execution required. You can use the ``[noexec]`` flag to set up
-   tasks as dependency placeholders, or to disable tasks defined
-   elsewhere that are not needed in a particular recipe.
-  ``[nostamp]``: When set to "1", tells BitBake to not generate a
-   stamp file for a task, which implies the task should always be
-   executed.
-   .. caution::
-      Any task that depends (possibly indirectly) on a ``[nostamp]`` task will
-      always be executed as well. This can cause unnecessary rebuilding if you
-      are not careful.
-  ``[number_threads]``: Limits tasks to a specific number of
-   simultaneous threads during execution. This varflag is useful when
-   your build host has a large number of cores but certain tasks need to
-   be rate-limited due to various kinds of resource constraints (e.g. to
-   avoid network throttling). ``number_threads`` works similarly to the
-   :term:`BB_NUMBER_THREADS` variable but is task-specific.
-   Set the value globally. For example, the following makes sure the
-   ``do_fetch`` task uses no more than two simultaneous execution
-   threads: do_fetch[number_threads] = "2"
-   .. warning::
-      -  Setting the varflag in individual recipes rather than globally
-         can result in unpredictable behavior.
-      -  Setting the varflag to a value greater than the value used in
-         the :term:`BB_NUMBER_THREADS` variable causes ``number_threads`` to
-         have no effect.
-  ``[postfuncs]``: List of functions to call after the completion of
-   the task.
-  ``[prefuncs]``: List of functions to call before the task executes.
-  ``[rdepends]``: Controls inter-task runtime dependencies. See the
-   :term:`RDEPENDS` variable, the
-   :term:`RRECOMMENDS` variable, and the
-   ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:inter-task dependencies`" section for
-   more information.
-  ``[rdeptask]``: Controls task runtime dependencies. See the
-   :term:`RDEPENDS` variable, the
-   :term:`RRECOMMENDS` variable, and the
-   ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:runtime dependencies`" section for more
-   information.
-  ``[recideptask]``: When set in conjunction with ``recrdeptask``,
-   specifies a task that should be inspected for additional
-   dependencies.
-  ``[recrdeptask]``: Controls task recursive runtime dependencies.
-   See the :term:`RDEPENDS` variable, the
-   :term:`RRECOMMENDS` variable, and the
-   ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:recursive dependencies`" section for
-   more information.
-  ``[stamp-extra-info]``: Extra stamp information to append to the
-   task's stamp. As an example, OpenEmbedded uses this flag to allow
-   machine-specific tasks.
-  ``[umask]``: The umask to run the task under.
-Several varflags are useful for controlling how signatures are
-calculated for variables. For more information on this process, see the
-":ref:`bitbake-user-manual/bitbake-user-manual-execution:checksums (signatures)`" section.
-  ``[vardeps]``: Specifies a space-separated list of additional
-   variables to add to a variable's dependencies for the purposes of
-   calculating its signature. Adding variables to this list is useful,
-   for example, when a function refers to a variable in a manner that
-   does not allow BitBake to automatically determine that the variable
-   is referred to.
-  ``[vardepsexclude]``: Specifies a space-separated list of variables
-   that should be excluded from a variable's dependencies for the
-   purposes of calculating its signature.
-  ``[vardepvalue]``: If set, instructs BitBake to ignore the actual
-   value of the variable and instead use the specified value when
-   calculating the variable's signature.
-  ``[vardepvalueexclude]``: Specifies a pipe-separated list of
-   strings to exclude from the variable's value when calculating the
-   variable's signature.
-Events
-======
-BitBake allows installation of event handlers within recipe and class
-files. Events are triggered at certain points during operation, such as
-the beginning of operation against a given recipe (i.e. ``*.bb``), the
-start of a given task, a task failure, a task success, and so forth. The
-intent is to make it easy to do things like email notification on build
-failures.
-Following is an example event handler that prints the name of the event
-and the content of the :term:`FILE` variable::
-   addhandler myclass_eventhandler
-   python myclass_eventhandler() {
-       from bb.event import getName
-       print("The name of the Event is %s" % getName(e))
-       print("The file we run for is %s" % d.getVar('FILE'))
-   }
-   myclass_eventhandler[eventmask] = "bb.event.BuildStarted
-   bb.event.BuildCompleted"
-In the previous example, an eventmask has been
-set so that the handler only sees the "BuildStarted" and
-"BuildCompleted" events. This event handler gets called every time an
-event matching the eventmask is triggered. A global variable "e" is
-defined, which represents the current event. With the ``getName(e)``
-method, you can get the name of the triggered event. The global
-datastore is available as "d". In legacy code, you might see "e.data"
-used to get the datastore. However, realize that "e.data" is deprecated
-and you should use "d" going forward.
-The context of the datastore is appropriate to the event in question.
-For example, "BuildStarted" and "BuildCompleted" events run before any
-tasks are executed so would be in the global configuration datastore
-namespace. No recipe-specific metadata exists in that namespace. The
-"BuildStarted" and "BuildCompleted" events also run in the main
-cooker/server process rather than any worker context. Thus, any changes
-made to the datastore would be seen by other cooker/server events within
-the current build but not seen outside of that build or in any worker
-context. Task events run in the actual tasks in question consequently
-have recipe-specific and task-specific contents. These events run in the
-worker context and are discarded at the end of task execution.
-During a standard build, the following common events might occur. The
-following events are the most common kinds of events that most metadata
-might have an interest in viewing:
-  ``bb.event.ConfigParsed()``: Fired when the base configuration; which
-   consists of ``bitbake.conf``, ``base.bbclass`` and any global
-   :term:`INHERIT` statements; has been parsed. You can see multiple such
-   events when each of the workers parse the base configuration or if
-   the server changes configuration and reparses. Any given datastore
-   only has one such event executed against it, however. If
-   :term:`BB_INVALIDCONF` is set in the datastore by the event
-   handler, the configuration is reparsed and a new event triggered,
-   allowing the metadata to update configuration.
-  ``bb.event.HeartbeatEvent()``: Fires at regular time intervals of one
-   second. You can configure the interval time using the
-   ``BB_HEARTBEAT_EVENT`` variable. The event's "time" attribute is the
-   ``time.time()`` value when the event is triggered. This event is
-   useful for activities such as system state monitoring.
-  ``bb.event.ParseStarted()``: Fired when BitBake is about to start
-   parsing recipes. This event's "total" attribute represents the number
-   of recipes BitBake plans to parse.
-  ``bb.event.ParseProgress()``: Fired as parsing progresses. This
-   event's "current" attribute is the number of recipes parsed as well
-   as the "total" attribute.
-  ``bb.event.ParseCompleted()``: Fired when parsing is complete. This
-   event's "cached", "parsed", "skipped", "virtuals", "masked", and
-   "errors" attributes provide statistics for the parsing results.
-  ``bb.event.BuildStarted()``: Fired when a new build starts. BitBake
-   fires multiple "BuildStarted" events (one per configuration) when
-   multiple configuration (multiconfig) is enabled.
-  ``bb.build.TaskStarted()``: Fired when a task starts. This event's
-   "taskfile" attribute points to the recipe from which the task
-   originates. The "taskname" attribute, which is the task's name,
-   includes the ``do_`` prefix, and the "logfile" attribute point to
-   where the task's output is stored. Finally, the "time" attribute is
-   the task's execution start time.
-  ``bb.build.TaskInvalid()``: Fired if BitBake tries to execute a task
-   that does not exist.
-  ``bb.build.TaskFailedSilent()``: Fired for setscene tasks that fail
-   and should not be presented to the user verbosely.
-  ``bb.build.TaskFailed()``: Fired for normal tasks that fail.
-  ``bb.build.TaskSucceeded()``: Fired when a task successfully
-   completes.
-  ``bb.event.BuildCompleted()``: Fired when a build finishes.
-  ``bb.cooker.CookerExit()``: Fired when the BitBake server/cooker
-   shuts down. This event is usually only seen by the UIs as a sign they
-   should also shutdown.
-This next list of example events occur based on specific requests to the
-server. These events are often used to communicate larger pieces of
-information from the BitBake server to other parts of BitBake such as
-user interfaces:
-  ``bb.event.TreeDataPreparationStarted()``
-  ``bb.event.TreeDataPreparationProgress()``
-  ``bb.event.TreeDataPreparationCompleted()``
-  ``bb.event.DepTreeGenerated()``
-  ``bb.event.CoreBaseFilesFound()``
-  ``bb.event.ConfigFilePathFound()``
-  ``bb.event.FilesMatchingFound()``
-  ``bb.event.ConfigFilesFound()``
-  ``bb.event.TargetsTreeGenerated()``
-.. _variants-class-extension-mechanism:
-Variants --- Class Extension Mechanism
-======================================
-BitBake supports multiple incarnations of a recipe file via the
-:term:`BBCLASSEXTEND` variable.
-The :term:`BBCLASSEXTEND` variable is a space separated list of classes used
-to "extend" the recipe for each variant. Here is an example that results in a
-second incarnation of the current recipe being available. This second
-incarnation will have the "native" class inherited. ::
-      BBCLASSEXTEND = "native"
-.. note::
-   The mechanism for this class extension is extremely specific to the
-   implementation. Usually, the recipe's :term:`PROVIDES` , :term:`PN` , and
-   :term:`DEPENDS` variables would need to be modified by the extension
-   class. For specific examples, see the OE-Core native , nativesdk , and
-   multilib classes.
-Dependencies
-============
-To allow for efficient parallel processing, BitBake handles dependencies
-at the task level. Dependencies can exist both between tasks within a
-single recipe and between tasks in different recipes. Following are
-examples of each:
-  For tasks within a single recipe, a recipe's ``do_configure`` task
-   might need to complete before its ``do_compile`` task can run.
-  For tasks in different recipes, one recipe's ``do_configure`` task
-   might require another recipe's ``do_populate_sysroot`` task to finish
-   first such that the libraries and headers provided by the other
-   recipe are available.
-This section describes several ways to declare dependencies. Remember,
-even though dependencies are declared in different ways, they are all
-simply dependencies between tasks.
-.. _dependencies-internal-to-the-bb-file:
-Dependencies Internal to the ``.bb`` File
-----------------------------------------
-BitBake uses the ``addtask`` directive to manage dependencies that are
-internal to a given recipe file. You can use the ``addtask`` directive
-to indicate when a task is dependent on other tasks or when other tasks
-depend on that recipe. Here is an example::
-   addtask printdate after do_fetch before do_build
-In this example, the ``do_printdate`` task
-depends on the completion of the ``do_fetch`` task, and the ``do_build``
-task depends on the completion of the ``do_printdate`` task.
-.. note::
-   For a task to run, it must be a direct or indirect dependency of some
-   other task that is scheduled to run.
-   For illustration, here are some examples:
-   -  The directive ``addtask mytask before do_configure`` causes
-      ``do_mytask`` to run before ``do_configure`` runs. Be aware that
-      ``do_mytask`` still only runs if its :ref:`input
-      checksum <bitbake-user-manual/bitbake-user-manual-execution:checksums (signatures)>` has changed since the last time it was
-      run. Changes to the input checksum of ``do_mytask`` also
-      indirectly cause ``do_configure`` to run.
-   -  The directive ``addtask mytask after do_configure`` by itself
-      never causes ``do_mytask`` to run. ``do_mytask`` can still be run
-      manually as follows::
-         $ bitbake recipe -c mytask
-      Declaring ``do_mytask`` as a dependency of some other task that is
-      scheduled to run also causes it to run. Regardless, the task runs after
-      ``do_configure``.
-Build Dependencies
------------------
-BitBake uses the :term:`DEPENDS` variable to manage
-build time dependencies. The ``[deptask]`` varflag for tasks signifies
-the task of each item listed in :term:`DEPENDS` that must complete before
-that task can be executed. Here is an example::
-   do_configure[deptask] = "do_populate_sysroot"
-In this example, the ``do_populate_sysroot`` task
-of each item in :term:`DEPENDS` must complete before ``do_configure`` can
-execute.
-Runtime Dependencies
--------------------
-BitBake uses the :term:`PACKAGES`, :term:`RDEPENDS`, and :term:`RRECOMMENDS`
-variables to manage runtime dependencies.
-The :term:`PACKAGES` variable lists runtime packages. Each of those packages
-can have :term:`RDEPENDS` and :term:`RRECOMMENDS` runtime dependencies. The
-``[rdeptask]`` flag for tasks is used to signify the task of each item
-runtime dependency which must have completed before that task can be
-executed. ::
-   do_package_qa[rdeptask] = "do_packagedata"
-In the previous
-example, the ``do_packagedata`` task of each item in :term:`RDEPENDS` must
-have completed before ``do_package_qa`` can execute.
-Although :term:`RDEPENDS` contains entries from the
-runtime dependency namespace, BitBake knows how to map them back
-to the build-time dependency namespace, in which the tasks are defined.
-Recursive Dependencies
----------------------
-BitBake uses the ``[recrdeptask]`` flag to manage recursive task
-dependencies. BitBake looks through the build-time and runtime
-dependencies of the current recipe, looks through the task's inter-task
-dependencies, and then adds dependencies for the listed task. Once
-BitBake has accomplished this, it recursively works through the
-dependencies of those tasks. Iterative passes continue until all
-dependencies are discovered and added.
-The ``[recrdeptask]`` flag is most commonly used in high-level recipes
-that need to wait for some task to finish "globally". For example,
-``image.bbclass`` has the following::
-   do_rootfs[recrdeptask] += "do_packagedata"
-This statement says that the ``do_packagedata`` task of
-the current recipe and all recipes reachable (by way of dependencies)
-from the image recipe must run before the ``do_rootfs`` task can run.
-BitBake allows a task to recursively depend on itself by
-referencing itself in the task list::
-   do_a[recrdeptask] = "do_a do_b"
-In the same way as before, this means that the ``do_a``
-and ``do_b`` tasks of the current recipe and all
-recipes reachable (by way of dependencies) from the recipe
-must run before the ``do_a`` task can run. In this
-case BitBake will ignore the current recipe's ``do_a``
-task circular dependency on itself.
-Inter-Task Dependencies
-----------------------
-BitBake uses the ``[depends]`` flag in a more generic form to manage
-inter-task dependencies. This more generic form allows for
-inter-dependency checks for specific tasks rather than checks for the
-data in :term:`DEPENDS`. Here is an example::
-   do_patch[depends] = "quilt-native:do_populate_sysroot"
-In this example, the ``do_populate_sysroot`` task of the target ``quilt-native``
-must have completed before the ``do_patch`` task can execute.
-The ``[rdepends]`` flag works in a similar way but takes targets in the
-runtime namespace instead of the build-time dependency namespace.
-Functions You Can Call From Within Python
-=========================================
-BitBake provides many functions you can call from within Python
-functions. This section lists the most commonly used functions, and
-mentions where to find others.
-Functions for Accessing Datastore Variables
-------------------------------------------
-It is often necessary to access variables in the BitBake datastore using
-Python functions. The BitBake datastore has an API that allows you this
-access. Here is a list of available operations:
-.. list-table::
-   :widths: auto
-   :header-rows: 1
-   * - *Operation*
-     - *Description*
-   * - ``d.getVar("X", expand)``
-     - Returns the value of variable "X". Using "expand=True" expands the
-       value. Returns "None" if the variable "X" does not exist.
-   * - ``d.setVar("X", "value")``
-     - Sets the variable "X" to "value"
-   * - ``d.appendVar("X", "value")``
-     - Adds "value" to the end of the variable "X". Acts like ``d.setVar("X",
-       "value")`` if the variable "X" does not exist.
-   * - ``d.prependVar("X", "value")``
-     - Adds "value" to the start of the variable "X". Acts like
-       ``d.setVar("X","value")`` if the variable "X" does not exist.
-   * - ``d.delVar("X")``
-     - Deletes the variable "X" from the datastore. Does nothing if the variable
-       "X" does not exist.
-   * - ``d.renameVar("X", "Y")``
-     - Renames the variable "X" to "Y". Does nothing if the variable "X" does
-       not exist.
-   * - ``d.getVarFlag("X", flag, expand)``
-     - Returns the value of variable "X". Using "expand=True" expands the
-       value. Returns "None" if either the variable "X" or the named flag does
-       not exist.
-   * - ``d.setVarFlag("X", flag, "value")``
-     - Sets the named flag for variable "X" to "value".
-   * - ``d.appendVarFlag("X", flag, "value")``
-     - Appends "value" to the named flag on the variable "X". Acts like
-       ``d.setVarFlag("X", flag, "value")`` if the named flag does not exist.
-   * - ``d.prependVarFlag("X", flag, "value")``
-     - Prepends "value" to the named flag on the variable "X". Acts like
-       ``d.setVarFlag("X", flag, "value")`` if the named flag does not exist.
-   * - ``d.delVarFlag("X", flag)``
-     - Deletes the named flag on the variable "X" from the datastore.
-   * - ``d.setVarFlags("X", flagsdict)``
-     - Sets the flags specified in the ``flagsdict()``
-       parameter. ``setVarFlags`` does not clear previous flags. Think of this
-       operation as ``addVarFlags``.
-   * - ``d.getVarFlags("X")``
-     - Returns a ``flagsdict`` of the flags for the variable "X". Returns "None"
-       if the variable "X" does not exist.
-   * - ``d.delVarFlags("X")``
-     - Deletes all the flags for the variable "X". Does nothing if the variable
-       "X" does not exist.
-   * - ``d.expand(expression)``
-     - Expands variable references in the specified string
-       expression. References to variables that do not exist are left as is. For
-       example, ``d.expand("foo ${X}")`` expands to the literal string "foo
-       ${X}" if the variable "X" does not exist.
-Other Functions
---------------
-Other functions are documented in the
-:doc:`/bitbake-user-manual/bitbake-user-manual-library-functions` document.
-Extending Python Library Code
-----------------------------
-If you wish to add your own Python library code (e.g. to provide
-functions/classes you can use from Python functions in the metadata)
-you can do so from any layer using the ``addpylib`` directive.
-This directive is typically added to your layer configuration (
-``conf/layer.conf``) although it will be handled in any ``.conf`` file.
-Usage is of the form::
-   addpylib <directory> <namespace>
-Where <directory> specifies the directory to add to the library path.
-The specified <namespace> is imported automatically, and if the imported
-module specifies an attribute named ``BBIMPORTS``, that list of
-sub-modules is iterated and imported too.
-Testing and Debugging BitBake Python code
-----------------------------------------
-The OpenEmbedded build system implements a convenient ``pydevshell`` target which
-you can use to access the BitBake datastore and experiment with your own Python
-code. See :yocto_docs:`Using a Python Development Shell
-</dev-manual/python-development-shell.html#using-a-python-development-shell>` in the Yocto
-Project manual for details.
-Task Checksums and Setscene
-===========================
-BitBake uses checksums (or signatures) along with the setscene to
-determine if a task needs to be run. This section describes the process.
-To help understand how BitBake does this, the section assumes an
-OpenEmbedded metadata-based example.
-These checksums are stored in :term:`STAMP`. You can
-examine the checksums using the following BitBake command::
-   $ bitbake-dumpsigs
-This command returns the signature data in a readable
-format that allows you to examine the inputs used when the OpenEmbedded
-build system generates signatures. For example, using
-``bitbake-dumpsigs`` allows you to examine the ``do_compile`` task's
-"sigdata" for a C application (e.g. ``bash``). Running the command also
-reveals that the "CC" variable is part of the inputs that are hashed.
-Any changes to this variable would invalidate the stamp and cause the
-``do_compile`` task to run.
-The following list describes related variables:
-  :term:`BB_HASHCHECK_FUNCTION`:
-   Specifies the name of the function to call during the "setscene" part
-   of the task's execution in order to validate the list of task hashes.
-  :term:`BB_SETSCENE_DEPVALID`:
-   Specifies a function BitBake calls that determines whether BitBake
-   requires a setscene dependency to be met.
-  :term:`BB_TASKHASH`: Within an executing task,
-   this variable holds the hash of the task as returned by the currently
-   enabled signature generator.
-  :term:`STAMP`: The base path to create stamp files.
-  :term:`STAMPCLEAN`: Again, the base path to
-   create stamp files but can use wildcards for matching a range of
-   files for clean operations.
-Wildcard Support in Variables
-=============================
-Support for wildcard use in variables varies depending on the context in
-which it is used. For example, some variables and filenames allow
-limited use of wildcards through the "``%``" and "``*``" characters.
-Other variables or names support Python's
-`glob <https://docs.python.org/3/library/glob.html>`_ syntax,
-`fnmatch <https://docs.python.org/3/library/fnmatch.html#module-fnmatch>`_
-syntax, or
-`Regular Expression (re) <https://docs.python.org/3/library/re.html>`_
-syntax.
-For variables that have wildcard suport, the documentation describes
-which form of wildcard, its use, and its limitations.
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables-context.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables-context.rst
deleted file mode 100644
index e9c454ba11..0000000000
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables-context.rst
+++ /dev/null
@@ -1,91 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-================
-Variable Context
-================
-|
-Variables might only have an impact or can be used in certain contexts. Some
-should only be used in global files like ``.conf``, while others are intended only
-for local files like ``.bb``. This chapter aims to describe some important variable
-contexts.
-.. _ref-varcontext-configuration:
-BitBake's own configuration
-===========================
-Variables starting with ``BB_`` usually configure the behaviour of BitBake itself.
-For example, one could configure:
- System resources, like disk space to be used (:term:`BB_DISKMON_DIRS`),
-  or the number of tasks to be run in parallel by BitBake (:term:`BB_NUMBER_THREADS`).
- How the fetchers shall behave, e.g., :term:`BB_FETCH_PREMIRRORONLY` is used
-  by BitBake to determine if BitBake's fetcher shall search only
-  :term:`PREMIRRORS` for files.
-Those variables are usually configured globally.
-BitBake configuration
-=====================
-There are variables:
- Like :term:`B` or :term:`T`, that are used to specify directories used by
-  BitBake during the build of a particular recipe. Those variables are
-  specified in ``bitbake.conf``. Some, like :term:`B`, are quite often
-  overwritten in recipes.
- Starting with ``FAKEROOT``, to configure how the ``fakeroot`` command is
-  handled. Those are usually set by ``bitbake.conf`` and might get adapted in a
-  ``bbclass``.
- Detailing where BitBake will store and fetch information from, for
-  data reuse between build runs like :term:`CACHE`, :term:`DL_DIR` or
-  :term:`PERSISTENT_DIR`. Those are usually global.
-Layers and files
-================
-Variables starting with ``LAYER`` configure how BitBake handles layers.
-Additionally, variables starting with ``BB`` configure how layers and files are
-handled. For example:
- :term:`LAYERDEPENDS` is used to configure on which layers a given layer
-  depends.
- The configured layers are contained in :term:`BBLAYERS` and files in
-  :term:`BBFILES`.
-Those variables are often used in the files ``layer.conf`` and ``bblayers.conf``.
-Recipes and packages
-====================
-Variables handling recipes and packages can be split into:
- :term:`PN`, :term:`PV` or :term:`PF` for example, contain information about
-  the name or revision of a recipe or package. Usually, the default set in
-  ``bitbake.conf`` is used, but those are from time to time overwritten in
-  recipes.
- :term:`SUMMARY`, :term:`DESCRIPTION`, :term:`LICENSE` or :term:`HOMEPAGE`
-  contain the expected information and should be set specifically for every
-  recipe.
- In recipes, variables are also used to control build and runtime
-  dependencies between recipes/packages with other recipes/packages. The
-  most common should be: :term:`PROVIDES`, :term:`RPROVIDES`, :term:`DEPENDS`,
-  and :term:`RDEPENDS`.
- There are further variables starting with ``SRC`` that specify the sources in
-  a recipe like :term:`SRC_URI` or :term:`SRCDATE`. Those are also usually set
-  in recipes.
- Which version or provider of a recipe should be given preference when
-  multiple recipes would provide the same item, is controlled by variables
-  starting with ``PREFERRED_``. Those are normally set in the configuration
-  files of a ``MACHINE`` or ``DISTRO``.
diff --git a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst b/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
deleted file mode 100644
index 810f886897..0000000000
--- a/bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst
+++ /dev/null
@@ -1,1699 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-==================
-Variables Glossary
-==================
-|
-This chapter lists common variables used by BitBake and gives an
-overview of their function and contents.
-.. note::
-   Following are some points regarding the variables listed in this
-   glossary:
-   -  The variables listed in this glossary are specific to BitBake.
-      Consequently, the descriptions are limited to that context.
-   -  Also, variables exist in other systems that use BitBake (e.g. The
-      Yocto Project and OpenEmbedded) that have names identical to those
-      found in this glossary. For such cases, the variables in those
-      systems extend the functionality of the variable as it is
-      described here in this glossary.
-.. glossary::
-   :sorted:
-   :term:`ASSUME_PROVIDED`
-      Lists recipe names (:term:`PN` values) BitBake does not
-      attempt to build. Instead, BitBake assumes these recipes have already
-      been built.
-      In OpenEmbedded-Core, :term:`ASSUME_PROVIDED` mostly specifies native
-      tools that should not be built. An example is ``git-native``, which
-      when specified allows for the Git binary from the host to be used
-      rather than building ``git-native``.
-   :term:`AZ_SAS`
-      Azure Storage Shared Access Signature, when using the
-      :ref:`Azure Storage fetcher <bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`
-      This variable can be defined to be used by the fetcher to authenticate
-      and gain access to non-public artifacts::
-         AZ_SAS = ""se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>""
-      For more information see Microsoft's Azure Storage documentation at
-      https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview
-   :term:`B`
-      The directory in which BitBake executes functions during a recipe's
-      build process.
-   :term:`BB_ALLOWED_NETWORKS`
-      Specifies a space-delimited list of hosts that the fetcher is allowed
-      to use to obtain the required source code. Following are
-      considerations surrounding this variable:
-      -  This host list is only used if
-         :term:`BB_NO_NETWORK` is either not set or
-         set to "0".
-      -  Limited support for the "``*``" wildcard character for matching
-         against the beginning of host names exists. For example, the
-         following setting matches ``git.gnu.org``, ``ftp.gnu.org``, and
-         ``foo.git.gnu.org``. ::
-            BB_ALLOWED_NETWORKS = "\*.gnu.org"
-         .. important::
-            The use of the "``*``" character only works at the beginning of
-            a host name and it must be isolated from the remainder of the
-            host name. You cannot use the wildcard character in any other
-            location of the name or combined with the front part of the
-            name.
-            For example, ``*.foo.bar`` is supported, while ``*aa.foo.bar``
-            is not.
-      -  Mirrors not in the host list are skipped and logged in debug.
-      -  Attempts to access networks not in the host list cause a failure.
-      Using :term:`BB_ALLOWED_NETWORKS` in conjunction with
-      :term:`PREMIRRORS` is very useful. Adding the
-      host you want to use to :term:`PREMIRRORS` results in the source code
-      being fetched from an allowed location and avoids raising an error
-      when a host that is not allowed is in a
-      :term:`SRC_URI` statement. This is because the
-      fetcher does not attempt to use the host listed in :term:`SRC_URI` after
-      a successful fetch from the :term:`PREMIRRORS` occurs.
-   :term:`BB_BASEHASH_IGNORE_VARS`
-      Lists variables that are excluded from checksum and dependency data.
-      Variables that are excluded can therefore change without affecting
-      the checksum mechanism. A common example would be the variable for
-      the path of the build. BitBake's output should not (and usually does
-      not) depend on the directory in which it was built.
-   :term:`BB_CACHEDIR`
-      Specifies the code parser cache directory (distinct from :term:`CACHE`
-      and :term:`PERSISTENT_DIR` although they can be set to the same value
-      if desired). The default value is "${TOPDIR}/cache".
-   :term:`BB_CHECK_SSL_CERTS`
-      Specifies if SSL certificates should be checked when fetching. The default
-      value is ``1`` and certificates are not checked if the value is set to ``0``.
-   :term:`BB_HASH_CODEPARSER_VALS`
-      Specifies values for variables to use when populating the codeparser cache.
-      This can be used selectively to set dummy values for variables to avoid
-      the codeparser cache growing on every parse. Variables that would typically
-      be included are those where the value is not significant for where the
-      codeparser cache is used (i.e. when calculating variable dependencies for
-      code fragments.) The value is space-separated without quoting values, for
-      example::
-         BB_HASH_CODEPARSER_VALS = "T=/ WORKDIR=/ DATE=1234 TIME=1234"
-   :term:`BB_CONSOLELOG`
-      Specifies the path to a log file into which BitBake's user interface
-      writes output during the build.
-   :term:`BB_CURRENTTASK`
-      Contains the name of the currently running task. The name does not
-      include the ``do_`` prefix.
-   :term:`BB_CURRENT_MC`
-      Contains the name of the current multiconfig a task is being run under.
-      The name is taken from the multiconfig configuration file (a file
-      ``mc1.conf`` would make this variable equal to ``mc1``).
-   :term:`BB_DEFAULT_TASK`
-      The default task to use when none is specified (e.g. with the ``-c``
-      command line option). The task name specified should not include the
-      ``do_`` prefix.
-   :term:`BB_DEFAULT_UMASK`
-      The default umask to apply to tasks if specified and no task specific
-      umask flag is set.
-   :term:`BB_DEFER_BBCLASSES`
-      The classes listed in this variable have their :ref:`inherit
-      <ref-bitbake-user-manual-metadata-inherit>` calls automatically promoted
-      to deferred inherits. See :ref:`inherit_defer
-      <ref-bitbake-user-manual-metadata-inherit-defer>` for more information on
-      deferred inherits.
-      This means that if :term:`BB_DEFER_BBCLASSES` is set as follows::
-         BB_DEFER_BBCLASSES = "foo"
-      The following statement::
-         inherit foo
-      Will automatically be equal to calling::
-         inherit_defer foo
-   :term:`BB_DISKMON_DIRS`
-      Monitors disk space and available inodes during the build and allows
-      you to control the build based on these parameters.
-      Disk space monitoring is disabled by default. When setting this
-      variable, use the following form::
-         BB_DISKMON_DIRS = "<action>,<dir>,<threshold> [...]"
-         where:
-            <action> is:
-               HALT:      Immediately halt the build when
-                          a threshold is broken.
-               STOPTASKS: Stop the build after the currently
-                          executing tasks have finished when
-                          a threshold is broken.
-               WARN:      Issue a warning but continue the
-                          build when a threshold is broken.
-                          Subsequent warnings are issued as
-                          defined by the
-                          BB_DISKMON_WARNINTERVAL variable,
-                          which must be defined.
-            <dir> is:
-               Any directory you choose. You can specify one or
-               more directories to monitor by separating the
-               groupings with a space.  If two directories are
-               on the same device, only the first directory
-               is monitored.
-            <threshold> is:
-               Either the minimum available disk space,
-               the minimum number of free inodes, or
-               both.  You must specify at least one.  To
-               omit one or the other, simply omit the value.
-               Specify the threshold using G, M, K for Gbytes,
-               Mbytes, and Kbytes, respectively. If you do
-               not specify G, M, or K, Kbytes is assumed by
-               default.  Do not use GB, MB, or KB.
-      Here are some examples::
-         BB_DISKMON_DIRS = "HALT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K"
-         BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G"
-         BB_DISKMON_DIRS = "HALT,${TMPDIR},,100K"
-      The first example works only if you also set the
-      :term:`BB_DISKMON_WARNINTERVAL`
-      variable. This example causes the build system to immediately halt
-      when either the disk space in ``${TMPDIR}`` drops below 1 Gbyte or
-      the available free inodes drops below 100 Kbytes. Because two
-      directories are provided with the variable, the build system also
-      issues a warning when the disk space in the ``${SSTATE_DIR}``
-      directory drops below 1 Gbyte or the number of free inodes drops
-      below 100 Kbytes. Subsequent warnings are issued during intervals as
-      defined by the :term:`BB_DISKMON_WARNINTERVAL` variable.
-      The second example stops the build after all currently executing
-      tasks complete when the minimum disk space in the ``${TMPDIR}``
-      directory drops below 1 Gbyte. No disk monitoring occurs for the free
-      inodes in this case.
-      The final example immediately halts the build when the number of
-      free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No
-      disk space monitoring for the directory itself occurs in this case.
-   :term:`BB_DISKMON_WARNINTERVAL`
-      Defines the disk space and free inode warning intervals.
-      If you are going to use the :term:`BB_DISKMON_WARNINTERVAL` variable, you
-      must also use the :term:`BB_DISKMON_DIRS`
-      variable and define its action as "WARN". During the build,
-      subsequent warnings are issued each time disk space or number of free
-      inodes further reduces by the respective interval.
-      If you do not provide a :term:`BB_DISKMON_WARNINTERVAL` variable and you
-      do use :term:`BB_DISKMON_DIRS` with the "WARN" action, the disk
-      monitoring interval defaults to the following:
-      BB_DISKMON_WARNINTERVAL = "50M,5K"
-      When specifying the variable in your configuration file, use the
-      following form::
-         BB_DISKMON_WARNINTERVAL = "<disk_space_interval>,<disk_inode_interval>"
-         where:
-            <disk_space_interval> is:
-               An interval of memory expressed in either
-               G, M, or K for Gbytes, Mbytes, or Kbytes,
-               respectively. You cannot use GB, MB, or KB.
-            <disk_inode_interval> is:
-               An interval of free inodes expressed in either
-               G, M, or K for Gbytes, Mbytes, or Kbytes,
-               respectively. You cannot use GB, MB, or KB.
-      Here is an example::
-         BB_DISKMON_DIRS = "WARN,${SSTATE_DIR},1G,100K"
-         BB_DISKMON_WARNINTERVAL = "50M,5K"
-      These variables cause BitBake to
-      issue subsequent warnings each time the available disk space further
-      reduces by 50 Mbytes or the number of free inodes further reduces by
-      5 Kbytes in the ``${SSTATE_DIR}`` directory. Subsequent warnings
-      based on the interval occur each time a respective interval is
-      reached beyond the initial warning (i.e. 1 Gbytes and 100 Kbytes).
-   :term:`BB_ENV_PASSTHROUGH`
-      Specifies the internal list of variables to allow through from
-      the external environment into BitBake's datastore. If the value of
-      this variable is not specified (which is the default), the following
-      list is used: :term:`BBPATH`, :term:`BB_PRESERVE_ENV`,
-      :term:`BB_ENV_PASSTHROUGH`, and :term:`BB_ENV_PASSTHROUGH_ADDITIONS`.
-      .. note::
-         You must set this variable in the external environment in order
-         for it to work.
-   :term:`BB_ENV_PASSTHROUGH_ADDITIONS`
-      Specifies an additional set of variables to allow through from the
-      external environment into BitBake's datastore. This list of variables
-      are on top of the internal list set in
-      :term:`BB_ENV_PASSTHROUGH`.
-      .. note::
-         You must set this variable in the external environment in order
-         for it to work.
-   :term:`BB_FETCH_PREMIRRORONLY`
-      When set to "1", causes BitBake's fetcher module to only search
-      :term:`PREMIRRORS` for files. BitBake will not
-      search the main :term:`SRC_URI` or
-      :term:`MIRRORS`.
-   :term:`BB_FILENAME`
-      Contains the filename of the recipe that owns the currently running
-      task. For example, if the ``do_fetch`` task that resides in the
-      ``my-recipe.bb`` is executing, the :term:`BB_FILENAME` variable contains
-      "/foo/path/my-recipe.bb".
-   :term:`BB_GENERATE_MIRROR_TARBALLS`
-      Causes tarballs of the Git repositories, including the Git metadata,
-      to be placed in the :term:`DL_DIR` directory. Anyone
-      wishing to create a source mirror would want to enable this variable.
-      For performance reasons, creating and placing tarballs of the Git
-      repositories is not the default action by BitBake. ::
-         BB_GENERATE_MIRROR_TARBALLS = "1"
-   :term:`BB_GENERATE_SHALLOW_TARBALLS`
-      Setting this variable to "1" when :term:`BB_GIT_SHALLOW` is also set to
-      "1" causes bitbake to generate shallow mirror tarballs when fetching git
-      repositories. The number of commits included in the shallow mirror
-      tarballs is controlled by :term:`BB_GIT_SHALLOW_DEPTH`.
-      If both :term:`BB_GIT_SHALLOW` and :term:`BB_GENERATE_MIRROR_TARBALLS` are
-      enabled, bitbake will generate shallow mirror tarballs by default for git
-      repositories. This separate variable exists so that shallow tarball
-      generation can be enabled without needing to also enable normal mirror
-      generation if it is not desired.
-      For example usage, see :term:`BB_GIT_SHALLOW`.
-   :term:`BB_GIT_DEFAULT_DESTSUFFIX`
-      The default destination directory where the :ref:`Git fetcher
-      <git-fetcher>` unpacks the source code. If this variable is not set, the
-      source code is unpacked in a directory named "git".
-   :term:`BB_GIT_SHALLOW`
-      Setting this variable to "1" enables the support for fetching, using and
-      generating mirror tarballs of `shallow git repositories <https://riptutorial.com/git/example/4584/shallow-clone>`_.
-      The external `git-make-shallow <https://git.openembedded.org/bitbake/tree/bin/git-make-shallow>`_
-      script is used for shallow mirror tarball creation.
-      When :term:`BB_GIT_SHALLOW` is enabled, bitbake will attempt to fetch a shallow
-      mirror tarball. If the shallow mirror tarball cannot be fetched, it will
-      try to fetch the full mirror tarball and use that.
-      This setting causes an initial shallow clone instead of an initial full bare clone.
-      The amount of data transferred during the initial clone will be significantly reduced.
-      However, every time the source revision (referenced in :term:`SRCREV`)
-      changes, regardless of whether the cache within the download directory
-      (defined by :term:`DL_DIR`) has been cleaned up or not,
-      the data transfer may be significantly higher because entirely
-      new shallow clones are required for each source revision change.
-      Over time, numerous shallow clones may cumulatively transfer
-      the same amount of data as an initial full bare clone.
-      This is especially the case with very large repositories.
-      Existing initial full bare clones, created without this setting,
-      will still be utilized.
-      If the Git error "Server does not allow request for unadvertised object"
-      occurs, an initial full bare clone is fetched automatically.
-      This may happen if the Git server does not allow the request
-      or if the Git client has issues with this functionality.
-      See also :term:`BB_GIT_SHALLOW_DEPTH` and
-      :term:`BB_GENERATE_SHALLOW_TARBALLS`.
-      Example usage::
-         BB_GIT_SHALLOW ?= "1"
-         # Keep only the top commit
-         BB_GIT_SHALLOW_DEPTH ?= "1"
-         # This defaults to enabled if both BB_GIT_SHALLOW and
-         # BB_GENERATE_MIRROR_TARBALLS are enabled
-         BB_GENERATE_SHALLOW_TARBALLS ?= "1"
-   :term:`BB_GIT_SHALLOW_DEPTH`
-      When used with :term:`BB_GENERATE_SHALLOW_TARBALLS`, this variable sets
-      the number of commits to include in generated shallow mirror tarballs.
-      With a depth of 1, only the commit referenced in :term:`SRCREV` is
-      included in the shallow mirror tarball. Increasing the depth includes
-      additional parent commits, working back through the commit history.
-      If this variable is unset, bitbake will default to a depth of 1 when
-      generating shallow mirror tarballs.
-      For example usage, see :term:`BB_GIT_SHALLOW`.
-   :term:`BB_GLOBAL_PYMODULES`
-      Specifies the list of Python modules to place in the global namespace.
-      It is intended that only the core layer should set this and it is meant
-      to be a very small list, typically just ``os`` and ``sys``.
-      :term:`BB_GLOBAL_PYMODULES` is expected to be set before the first
-      ``addpylib`` directive.
-      See also ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:extending python library code`".
-   :term:`BB_HASHCHECK_FUNCTION`
-      Specifies the name of the function to call during the "setscene" part
-      of the task's execution in order to validate the list of task hashes.
-      The function returns the list of setscene tasks that should be
-      executed.
-      At this point in the execution of the code, the objective is to
-      quickly verify if a given setscene function is likely to work or not.
-      It's easier to check the list of setscene functions in one pass than
-      to call many individual tasks. The returned list need not be
-      completely accurate. A given setscene task can still later fail.
-      However, the more accurate the data returned, the more efficient the
-      build will be.
-   :term:`BB_HASHCONFIG_IGNORE_VARS`
-      Lists variables that are excluded from base configuration checksum,
-      which is used to determine if the cache can be reused.
-      One of the ways BitBake determines whether to re-parse the main
-      metadata is through checksums of the variables in the datastore of
-      the base configuration data. There are variables that you typically
-      want to exclude when checking whether or not to re-parse and thus
-      rebuild the cache. As an example, you would usually exclude ``TIME``
-      and ``DATE`` because these variables are always changing. If you did
-      not exclude them, BitBake would never reuse the cache.
-   :term:`BB_HASHSERVE`
-      Specifies the Hash Equivalence server to use.
-      If set to ``auto``, BitBake automatically starts its own server
-      over a UNIX domain socket. An option is to connect this server
-      to an upstream one, by setting :term:`BB_HASHSERVE_UPSTREAM`.
-      If set to ``unix://path``, BitBake will connect to an existing
-      hash server available over a UNIX domain socket.
-      If set to ``host:port``, BitBake will connect to a remote server on the
-      specified host. This allows multiple clients to share the same
-      hash equivalence data.
-      The remote server can be started manually through
-      the ``bin/bitbake-hashserv`` script provided by BitBake,
-      which supports UNIX domain sockets too. This script also allows
-      to start the server in read-only mode, to avoid accepting
-      equivalences that correspond to Share State caches that are
-      only available on specific clients.
-   :term:`BB_HASHSERVE_UPSTREAM`
-      Specifies an upstream Hash Equivalence server.
-      This optional setting is only useful when a local Hash Equivalence
-      server is started (setting :term:`BB_HASHSERVE` to ``auto``),
-      and you wish the local server to query an upstream server for
-      Hash Equivalence data.
-      Example usage::
-         BB_HASHSERVE_UPSTREAM = "hashserv.yoctoproject.org:8686"
-   :term:`BB_INVALIDCONF`
-      Used in combination with the ``ConfigParsed`` event to trigger
-      re-parsing the base metadata (i.e. all the recipes). The
-      ``ConfigParsed`` event can set the variable to trigger the re-parse.
-      You must be careful to avoid recursive loops with this functionality.
-   :term:`BB_LOADFACTOR_MAX`
-      Setting this to a value will cause BitBake to check the system load
-      average before executing new tasks. If the load average is above the
-      the number of CPUs multipled by this factor, no new task will be started
-      unless there is no task executing. A value of "1.5" has been found to
-      work reasonably. This is helpful for systems which don't have pressure
-      regulation enabled, which is more granular. Pressure values take
-      precedence over loadfactor.
-   :term:`BB_LOGCONFIG`
-      Specifies the name of a config file that contains the user logging
-      configuration. See
-      :ref:`bitbake-user-manual/bitbake-user-manual-execution:logging`
-      for additional information
-   :term:`BB_LOGFMT`
-      Specifies the name of the log files saved into
-      ``${``\ :term:`T`\ ``}``. By default, the :term:`BB_LOGFMT`
-      variable is undefined and the log filenames get created using the
-      following form::
-         log.{task}.{pid}
-      If you want to force log files to take a specific name, you can set this
-      variable in a configuration file.
-   :term:`BB_MULTI_PROVIDER_ALLOWED`
-      Allows you to suppress BitBake warnings caused when building two
-      separate recipes that provide the same output.
-      BitBake normally issues a warning when building two different recipes
-      where each provides the same output. This scenario is usually
-      something the user does not want. However, cases do exist where it
-      makes sense, particularly in the ``virtual/*`` namespace. You can use
-      this variable to suppress BitBake's warnings.
-      To use the variable, list provider names (e.g. recipe names,
-      ``virtual/kernel``, and so forth).
-   :term:`BB_NICE_LEVEL`
-      Allows BitBake to run at a specific priority (i.e. nice level).
-      System permissions usually mean that BitBake can reduce its priority
-      but not raise it again. See :term:`BB_TASK_NICE_LEVEL` for
-      additional information.
-   :term:`BB_NO_NETWORK`
-      Disables network access in the BitBake fetcher modules. With this
-      access disabled, any command that attempts to access the network
-      becomes an error.
-      Disabling network access is useful for testing source mirrors,
-      running builds when not connected to the Internet, and when operating
-      in certain kinds of firewall environments.
-   :term:`BB_NUMBER_PARSE_THREADS`
-      Sets the number of threads BitBake uses when parsing. By default, the
-      number of threads is equal to the number of cores on the system.
-   :term:`BB_NUMBER_THREADS`
-      The maximum number of tasks BitBake should run in parallel at any one
-      time. If your host development system supports multiple cores, a good
-      rule of thumb is to set this variable to twice the number of cores.
-   :term:`BB_ORIGENV`
-      Contains a copy of the original external environment in which BitBake
-      was run. The copy is taken before any variable values configured to
-      pass through from the external environment are filtered into BitBake's
-      datastore.
-      .. note::
-         The contents of this variable is a datastore object that can be
-         queried using the normal datastore operations.
-   :term:`BB_PRESERVE_ENV`
-      Disables environment filtering and instead allows all variables through
-      from the external environment into BitBake's datastore.
-      .. note::
-         You must set this variable in the external environment in order
-         for it to work.
-   :term:`BB_PRESSURE_MAX_CPU`
-      Specifies a maximum CPU pressure threshold, above which BitBake's
-      scheduler will not start new tasks (providing there is at least
-      one active task). If no value is set, CPU pressure is not
-      monitored when starting tasks.
-      The pressure data is calculated based upon what Linux kernels since
-      version 4.20 expose under ``/proc/pressure``. The threshold represents
-      the difference in "total" pressure from the previous second. The
-      minimum value is 1.0 (extremely slow builds) and the maximum is
-      1000000 (a pressure value unlikely to ever be reached). See
-      https://docs.kernel.org/accounting/psi.html for more information.
-      A default value to limit the CPU pressure to be set in ``conf/local.conf``
-      could be::
-         BB_PRESSURE_MAX_CPU = "15000"
-      Multiple values should be tested on the build host to determine what suits
-      best, depending on the need for performance versus load average during
-      the build.
-      .. note::
-         You may see numerous messages printed by BitBake in case the
-         :term:`BB_PRESSURE_MAX_CPU` is too low::
-            Pressure status changed to CPU: True, IO: False, Mem: False (CPU: 1105.9/2.0, IO: 0.0/2.0, Mem: 0.0/2.0) - using 1/64 bitbake threads
-         This means that the :term:`BB_PRESSURE_MAX_CPU` should be increased to
-         a reasonable value for limiting the CPU pressure on the system.
-         Monitor the varying value after ``CPU:`` above to set a sensible value.
-   :term:`BB_PRESSURE_MAX_IO`
-      Specifies a maximum I/O pressure threshold, above which BitBake's
-      scheduler will not start new tasks (providing there is at least
-      one active task). If no value is set, I/O pressure is not
-      monitored when starting tasks.
-      The pressure data is calculated based upon what Linux kernels since
-      version 4.20 expose under ``/proc/pressure``. The threshold represents
-      the difference in "total" pressure from the previous second. The
-      minimum value is 1.0 (extremely slow builds) and the maximum is
-      1000000 (a pressure value unlikely to ever be reached). See
-      https://docs.kernel.org/accounting/psi.html for more information.
-      At this point in time, experiments show that IO pressure tends to
-      be short-lived and regulating just the CPU with
-      :term:`BB_PRESSURE_MAX_CPU` can help to reduce it.
-      A default value to limit the IO pressure to be set in ``conf/local.conf``
-      could be::
-         BB_PRESSURE_MAX_IO = "15000"
-      Multiple values should be tested on the build host to determine what suits
-      best, depending on the need for performance versus I/O usage during the
-      build.
-      .. note::
-         You may see numerous messages printed by BitBake in case the
-         :term:`BB_PRESSURE_MAX_IO` is too low::
-            Pressure status changed to CPU: None, IO: True, Mem: False (CPU: 2236.0/None, IO: 153.6/2.0, Mem: 0.0/2.0) - using 19/64 bitbake threads
-         This means that the :term:`BB_PRESSURE_MAX_IO` should be increased to
-         a reasonable value for limiting the I/O pressure on the system.
-         Monitor the varying value after ``IO:`` above to set a sensible value.
-   :term:`BB_PRESSURE_MAX_MEMORY`
-      Specifies a maximum memory pressure threshold, above which BitBake's
-      scheduler will not start new tasks (providing there is at least
-      one active task). If no value is set, memory pressure is not
-      monitored when starting tasks.
-      The pressure data is calculated based upon what Linux kernels since
-      version 4.20 expose under ``/proc/pressure``. The threshold represents
-      the difference in "total" pressure from the previous second. The
-      minimum value is 1.0 (extremely slow builds) and the maximum is
-      1000000 (a pressure value unlikely to ever be reached). See
-      https://docs.kernel.org/accounting/psi.html for more information.
-      Memory pressure is experienced when time is spent swapping,
-      refaulting pages from the page cache or performing direct reclaim.
-      This is why memory pressure is rarely seen, but setting this variable
-      might be useful as a last resort to prevent OOM errors if they are
-      occurring during builds.
-      A default value to limit the memory pressure to be set in
-      ``conf/local.conf`` could be::
-         BB_PRESSURE_MAX_MEMORY = "15000"
-      Multiple values should be tested on the build host to determine what suits
-      best, depending on the need for performance versus memory consumption
-      during the build.
-      .. note::
-         You may see numerous messages printed by BitBake in case the
-         :term:`BB_PRESSURE_MAX_MEMORY` is too low::
-            Pressure status changed to CPU: None, IO: False, Mem: True (CPU: 29.5/None, IO: 0.0/2.0, Mem: 2553.3/2.0) - using 17/64 bitbake threads
-         This means that the :term:`BB_PRESSURE_MAX_MEMORY` should be increased to
-         a reasonable value for limiting the memory pressure on the system.
-         Monitor the varying value after ``Mem:`` above to set a sensible value.
-   :term:`BB_RUNFMT`
-      Specifies the name of the executable script files (i.e. run files)
-      saved into ``${``\ :term:`T`\ ``}``. By default, the
-      :term:`BB_RUNFMT` variable is undefined and the run filenames get
-      created using the following form::
-         run.{func}.{pid}
-      If you want to force run files to take a specific name, you can set this
-      variable in a configuration file.
-   :term:`BB_RUNTASK`
-      Contains the name of the currently executing task. The value includes
-      the "do\_" prefix. For example, if the currently executing task is
-      ``do_config``, the value is "do_config".
-   :term:`BB_SCHEDULER`
-      Selects the name of the scheduler to use for the scheduling of
-      BitBake tasks. Three options exist:
-      -  *basic* --- the basic framework from which everything derives. Using
-         this option causes tasks to be ordered numerically as they are
-         parsed.
-      -  *speed* --- executes tasks first that have more tasks depending on
-         them. The "speed" option is the default.
-      -  *completion* --- causes the scheduler to try to complete a given
-         recipe once its build has started.
-   :term:`BB_SCHEDULERS`
-      Defines custom schedulers to import. Custom schedulers need to be
-      derived from the ``RunQueueScheduler`` class.
-      For information how to select a scheduler, see the
-      :term:`BB_SCHEDULER` variable.
-   :term:`BB_SETSCENE_DEPVALID`
-      Specifies a function BitBake calls that determines whether BitBake
-      requires a setscene dependency to be met.
-      When running a setscene task, BitBake needs to know which
-      dependencies of that setscene task also need to be run. Whether
-      dependencies also need to be run is highly dependent on the metadata.
-      The function specified by this variable returns a "True" or "False"
-      depending on whether the dependency needs to be met.
-   :term:`BB_SIGNATURE_EXCLUDE_FLAGS`
-      Lists variable flags (varflags) that can be safely excluded from
-      checksum and dependency data for keys in the datastore. When
-      generating checksum or dependency data for keys in the datastore, the
-      flags set against that key are normally included in the checksum.
-      For more information on varflags, see the
-      ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variable flags`"
-      section.
-   :term:`BB_SIGNATURE_HANDLER`
-      Defines the name of the signature handler BitBake uses. The signature
-      handler defines the way stamp files are created and handled, if and
-      how the signature is incorporated into the stamps, and how the
-      signature itself is generated.
-      A new signature handler can be added by injecting a class derived
-      from the ``SignatureGenerator`` class into the global namespace.
-   :term:`BB_SRCREV_POLICY`
-      Defines the behavior of the fetcher when it interacts with source
-      control systems and dynamic source revisions. The
-      :term:`BB_SRCREV_POLICY` variable is useful when working without a
-      network.
-      The variable can be set using one of two policies:
-      -  *cache* --- retains the value the system obtained previously rather
-         than querying the source control system each time.
-      -  *clear* --- queries the source controls system every time. With this
-         policy, there is no cache. The "clear" policy is the default.
-   :term:`BB_STRICT_CHECKSUM`
-      Sets a more strict checksum mechanism for non-local URLs. Setting
-      this variable to a value causes BitBake to report an error if it
-      encounters a non-local URL that does not have at least one checksum
-      specified.
-   :term:`BB_TASK_IONICE_LEVEL`
-      Allows adjustment of a task's Input/Output priority. During
-      Autobuilder testing, random failures can occur for tasks due to I/O
-      starvation. These failures occur during various QEMU runtime
-      timeouts. You can use the :term:`BB_TASK_IONICE_LEVEL` variable to adjust
-      the I/O priority of these tasks.
-      .. note::
-         This variable works similarly to the :term:`BB_TASK_NICE_LEVEL`
-         variable except with a task's I/O priorities.
-      Set the variable as follows::
-         BB_TASK_IONICE_LEVEL = "class.prio"
-      For *class*, the default value is "2", which is a best effort. You can use
-      "1" for realtime and "3" for idle. If you want to use realtime, you
-      must have superuser privileges.
-      For *prio*, you can use any value from "0", which is the highest
-      priority, to "7", which is the lowest. The default value is "4". You
-      do not need any special privileges to use this range of priority
-      values.
-      .. note::
-         In order for your I/O priority settings to take effect, you need the
-         Budget Fair Queuing (BFQ) Scheduler selected for the backing block
-         device. To select the scheduler, use the following command form where
-         device is the device (e.g. sda, sdb, and so forth)::
-            $ sudo sh -c "echo bfq > /sys/block/device/queue/scheduler"
-   :term:`BB_TASK_NICE_LEVEL`
-      Allows specific tasks to change their priority (i.e. nice level).
-      You can use this variable in combination with task overrides to raise
-      or lower priorities of specific tasks. For example, on the `Yocto
-      Project <https://www.yoctoproject.org>`__ autobuilder, QEMU emulation
-      in images is given a higher priority as compared to build tasks to
-      ensure that images do not suffer timeouts on loaded systems.
-   :term:`BB_TASKHASH`
-      Within an executing task, this variable holds the hash of the task as
-      returned by the currently enabled signature generator.
-   :term:`BB_USE_HOME_NPMRC`
-      Controls whether or not BitBake uses the user's .npmrc file within their
-      home directory within the npm fetcher. This can be used for authentication
-      of private NPM registries, among other uses. This is turned off by default
-      and requires the user to explicitly set it to "1" to enable.
-   :term:`BB_VERBOSE_LOGS`
-      Controls how verbose BitBake is during builds. If set, shell scripts
-      echo commands and shell script output appears on standard out
-      (stdout).
-   :term:`BB_WORKERCONTEXT`
-      Specifies if the current context is executing a task. BitBake sets
-      this variable to "1" when a task is being executed. The value is not
-      set when the task is in server context during parsing or event
-      handling.
-   :term:`BBCLASSEXTEND`
-      Allows you to extend a recipe so that it builds variants of the
-      software. Some examples of these variants for recipes from the
-      OpenEmbedded-Core metadata are "natives" such as ``quilt-native``,
-      which is a copy of Quilt built to run on the build system; "crosses"
-      such as ``gcc-cross``, which is a compiler built to run on the build
-      machine but produces binaries that run on the target ``MACHINE``;
-      "nativesdk", which targets the SDK machine instead of ``MACHINE``;
-      and "mulitlibs" in the form "``multilib:``\ multilib_name".
-      To build a different variant of the recipe with a minimal amount of
-      code, it usually is as simple as adding the variable to your recipe.
-      Here are two examples. The "native" variants are from the
-      OpenEmbedded-Core metadata::
-         BBCLASSEXTEND =+ "native nativesdk"
-         BBCLASSEXTEND =+ "multilib:multilib_name"
-      .. note::
-         Internally, the :term:`BBCLASSEXTEND` mechanism generates recipe
-         variants by rewriting variable values and applying overrides such
-         as ``_class-native``. For example, to generate a native version of
-         a recipe, a :term:`DEPENDS` on "foo" is
-         rewritten to a :term:`DEPENDS` on "foo-native".
-         Even when using :term:`BBCLASSEXTEND`, the recipe is only parsed once.
-         Parsing once adds some limitations. For example, it is not
-         possible to include a different file depending on the variant,
-         since ``include`` statements are processed when the recipe is
-         parsed.
-   :term:`BBDEBUG`
-      Sets the BitBake debug output level to a specific value as
-      incremented by the ``-D`` command line option.
-      .. note::
-         You must set this variable in the external environment in order
-         for it to work.
-   :term:`BBFILE_COLLECTIONS`
-      Lists the names of configured layers. These names are used to find
-      the other ``BBFILE_*`` variables. Typically, each layer appends its
-      name to this variable in its ``conf/layer.conf`` file.
-   :term:`BBFILE_PATTERN`
-      Variable that expands to match files from
-      :term:`BBFILES` in a particular layer. This
-      variable is used in the ``conf/layer.conf`` file and must be suffixed
-      with the name of the specific layer (e.g.
-      ``BBFILE_PATTERN_emenlow``).
-   :term:`BBFILE_PRIORITY`
-      Assigns the priority for recipe files in each layer.
-      This variable is used in the ``conf/layer.conf`` file and must be
-      suffixed with a `_` followed by the name of the specific layer (e.g.
-      ``BBFILE_PRIORITY_emenlow``). Colon as separator is not supported.
-      This variable is useful in situations where the same recipe appears
-      in more than one layer. Setting this variable allows you to
-      prioritize a layer against other layers that contain the same recipe
-      --- effectively letting you control the precedence for the multiple
-      layers. The precedence established through this variable stands
-      regardless of a recipe's version (:term:`PV` variable).
-      For example, a layer that has a recipe with a higher :term:`PV` value but
-      for which the :term:`BBFILE_PRIORITY` is set to have a lower precedence
-      still has a lower precedence.
-      A larger value for the :term:`BBFILE_PRIORITY` variable results in a
-      higher precedence. For example, the value 6 has a higher precedence
-      than the value 5. If not specified, the :term:`BBFILE_PRIORITY` variable
-      is set based on layer dependencies (see the :term:`LAYERDEPENDS` variable
-      for more information). The default priority, if unspecified for a
-      layer with no dependencies, is the lowest defined priority + 1 (or 1
-      if no priorities are defined).
-      .. tip::
-         You can use the command bitbake-layers show-layers to list all
-         configured layers along with their priorities.
-   :term:`BBFILES`
-      A space-separated list of recipe files BitBake uses to build
-      software.
-      When specifying recipe files, you can pattern match using Python's
-      `glob <https://docs.python.org/3/library/glob.html>`_ syntax.
-      For details on the syntax, see the documentation by following the
-      previous link.
-   :term:`BBFILES_DYNAMIC`
-      Activates content depending on presence of identified layers.  You
-      identify the layers by the collections that the layers define.
-      Use the :term:`BBFILES_DYNAMIC` variable to avoid ``.bbappend`` files whose
-      corresponding ``.bb`` file is in a layer that attempts to modify other
-      layers through ``.bbappend`` but does not want to introduce a hard
-      dependency on those other layers.
-      Additionally you can prefix the rule with "!" to add ``.bbappend`` and
-      ``.bb`` files in case a layer is not present.  Use this avoid hard
-      dependency on those other layers.
-      Use the following form for :term:`BBFILES_DYNAMIC`::
-         collection_name:filename_pattern
-      The following example identifies two collection names and two filename
-      patterns::
-         BBFILES_DYNAMIC += "\
-             clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \
-             core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \
-         "
-      When the collection name is prefixed with "!" it will add the file pattern in case
-      the layer is absent::
-         BBFILES_DYNAMIC += "\
-             !clang-layer:${LAYERDIR}/backfill/meta-clang/*/*/*.bb \
-         "
-      This next example shows an error message that occurs because invalid
-      entries are found, which cause parsing to fail::
-         ERROR: BBFILES_DYNAMIC entries must be of the form {!}<collection name>:<filename pattern>, not:
-         /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend
-         /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend
-   :term:`BBINCLUDED`
-      Contains a space-separated list of all of all files that BitBake's
-      parser included during parsing of the current file.
-   :term:`BBINCLUDELOGS`
-      If set to a value, enables printing the task log when reporting a
-      failed task.
-   :term:`BBINCLUDELOGS_LINES`
-      If :term:`BBINCLUDELOGS` is set, specifies
-      the maximum number of lines from the task log file to print when
-      reporting a failed task. If you do not set :term:`BBINCLUDELOGS_LINES`,
-      the entire log is printed.
-   :term:`BBLAYERS`
-      Lists the layers to enable during the build. This variable is defined
-      in the ``bblayers.conf`` configuration file in the build directory.
-      Here is an example::
-         BBLAYERS = " \
-             /home/scottrif/poky/meta \
-             /home/scottrif/poky/meta-yocto \
-             /home/scottrif/poky/meta-yocto-bsp \
-             /home/scottrif/poky/meta-mykernel \
-         "
-      This example enables four layers, one of which is a custom, user-defined
-      layer named ``meta-mykernel``.
-   :term:`BBLAYERS_FETCH_DIR`
-      Sets the base location where layers are stored. This setting is used
-      in conjunction with ``bitbake-layers layerindex-fetch`` and tells
-      ``bitbake-layers`` where to place the fetched layers.
-   :term:`BBMASK`
-      Prevents BitBake from processing recipes and recipe append files.
-      You can use the :term:`BBMASK` variable to "hide" these ``.bb`` and
-      ``.bbappend`` files. BitBake ignores any recipe or recipe append
-      files that match any of the expressions. It is as if BitBake does not
-      see them at all. Consequently, matching files are not parsed or
-      otherwise used by BitBake.
-      The values you provide are passed to Python's regular expression
-      compiler. Consequently, the syntax follows Python's Regular
-      Expression (re) syntax. The expressions are compared against the full
-      paths to the files. For complete syntax information, see Python's
-      documentation at http://docs.python.org/3/library/re.html.
-      The following example uses a complete regular expression to tell
-      BitBake to ignore all recipe and recipe append files in the
-      ``meta-ti/recipes-misc/`` directory::
-         BBMASK = "meta-ti/recipes-misc/"
-      If you want to mask out multiple directories or recipes, you can
-      specify multiple regular expression fragments. This next example
-      masks out multiple directories and individual recipes::
-         BBMASK += "/meta-ti/recipes-misc/ meta-ti/recipes-ti/packagegroup/"
-         BBMASK += "/meta-oe/recipes-support/"
-         BBMASK += "/meta-foo/.*/openldap"
-         BBMASK += "opencv.*\.bbappend"
-         BBMASK += "lzma"
-      .. note::
-         When specifying a directory name, use the trailing slash character
-         to ensure you match just that directory name.
-   :term:`BBMULTICONFIG`
-      Enables BitBake to perform multiple configuration builds and lists
-      each separate configuration (multiconfig). You can use this variable
-      to cause BitBake to build multiple targets where each target has a
-      separate configuration. Define :term:`BBMULTICONFIG` in your
-      ``conf/local.conf`` configuration file.
-      As an example, the following line specifies three multiconfigs, each
-      having a separate configuration file::
-         BBMULTIFONFIG = "configA configB configC"
-      Each configuration file you use must reside in the
-      build directory within a directory named ``conf/multiconfig`` (e.g.
-      build_directory\ ``/conf/multiconfig/configA.conf``).
-      For information on how to use :term:`BBMULTICONFIG` in an environment
-      that supports building targets with multiple configurations, see the
-      ":ref:`bitbake-user-manual/bitbake-user-manual-intro:executing a multiple configuration build`"
-      section.
-   :term:`BBPATH`
-      A colon-separated list used by BitBake to locate class (``.bbclass``)
-      and configuration (``.conf``) files. This variable is analogous to the
-      ``PATH`` variable.
-      If you run BitBake from a directory outside of the build directory,
-      you must be sure to set :term:`BBPATH` to point to the build directory.
-      Set the variable as you would any environment variable and then run
-      BitBake::
-         $ BBPATH="build_directory"
-         $ export BBPATH
-         $ bitbake target
-   :term:`BBSERVER`
-      Points to the server that runs memory-resident BitBake. The variable
-      is only used when you employ memory-resident BitBake.
-   :term:`BBTARGETS`
-      Allows you to use a configuration file to add to the list of
-      command-line target recipes you want to build.
-   :term:`BITBAKE_UI`
-      Used to specify the UI module to use when running BitBake. Using this
-      variable is equivalent to using the ``-u`` command-line option.
-      .. note::
-         You must set this variable in the external environment in order
-         for it to work.
-   :term:`BUILDNAME`
-      A name assigned to the build. The name defaults to a datetime stamp
-      of when the build was started but can be defined by the metadata.
-   :term:`BZRDIR`
-      The directory in which files checked out of a Bazaar system are
-      stored.
-   :term:`CACHE`
-      Specifies the directory BitBake uses to store a cache of the metadata
-      so it does not need to be parsed every time BitBake is started.
-   :term:`CVSDIR`
-      The directory in which files checked out under the CVS system are
-      stored.
-   :term:`DEFAULT_PREFERENCE`
-      Specifies a weak bias for recipe selection priority.
-      The most common usage of this is variable is to set it to "-1" within
-      a recipe for a development version of a piece of software. Using the
-      variable in this way causes the stable version of the recipe to build
-      by default in the absence of :term:`PREFERRED_VERSION` being used to
-      build the development version.
-      .. note::
-         The bias provided by DEFAULT_PREFERENCE is weak and is overridden by
-         :term:`BBFILE_PRIORITY` if that variable is different between two
-         layers that contain different versions of the same recipe.
-   :term:`DEPENDS`
-      Lists a recipe's build-time dependencies (i.e. other recipe files).
-      Consider this simple example for two recipes named "a" and "b" that
-      produce similarly named packages. In this example, the :term:`DEPENDS`
-      statement appears in the "a" recipe::
-         DEPENDS = "b"
-      Here, the dependency is such that the ``do_configure`` task for recipe "a"
-      depends on the ``do_populate_sysroot`` task of recipe "b". This means
-      anything that recipe "b" puts into sysroot is available when recipe "a" is
-      configuring itself.
-      For information on runtime dependencies, see the :term:`RDEPENDS`
-      variable.
-   :term:`DESCRIPTION`
-      A long description for the recipe.
-   :term:`DL_DIR`
-      The central download directory used by the build process to store
-      downloads. By default, :term:`DL_DIR` gets files suitable for mirroring for
-      everything except Git repositories. If you want tarballs of Git
-      repositories, use the :term:`BB_GENERATE_MIRROR_TARBALLS` variable.
-   :term:`EXCLUDE_FROM_WORLD`
-      Directs BitBake to exclude a recipe from world builds (i.e.
-      ``bitbake world``). During world builds, BitBake locates, parses and
-      builds all recipes found in every layer exposed in the
-      ``bblayers.conf`` configuration file.
-      To exclude a recipe from a world build using this variable, set the
-      variable to "1" in the recipe. Set it to "0" to add it back to world build.
-      .. note::
-         Recipes added to :term:`EXCLUDE_FROM_WORLD` may still be built during a world
-         build in order to satisfy dependencies of other recipes. Adding a
-         recipe to :term:`EXCLUDE_FROM_WORLD` only ensures that the recipe is not
-         explicitly added to the list of build targets in a world build.
-   :term:`FAKEROOT`
-      Contains the command to use when running a shell script in a fakeroot
-      environment. The :term:`FAKEROOT` variable is obsolete and has been
-      replaced by the other ``FAKEROOT*`` variables. See these entries in
-      the glossary for more information.
-   :term:`FAKEROOTBASEENV`
-      Lists environment variables to set when executing the command defined
-      by :term:`FAKEROOTCMD` that starts the
-      bitbake-worker process in the fakeroot environment.
-   :term:`FAKEROOTCMD`
-      Contains the command that starts the bitbake-worker process in the
-      fakeroot environment.
-   :term:`FAKEROOTDIRS`
-      Lists directories to create before running a task in the fakeroot
-      environment.
-   :term:`FAKEROOTENV`
-      Lists environment variables to set when running a task in the
-      fakeroot environment. For additional information on environment
-      variables and the fakeroot environment, see the
-      :term:`FAKEROOTBASEENV` variable.
-   :term:`FAKEROOTNOENV`
-      Lists environment variables to set when running a task that is not in
-      the fakeroot environment. For additional information on environment
-      variables and the fakeroot environment, see the
-      :term:`FAKEROOTENV` variable.
-   :term:`FETCHCMD`
-      Defines the command the BitBake fetcher module executes when running
-      fetch operations. You need to use an override suffix when you use the
-      variable (e.g. ``FETCHCMD_git`` or ``FETCHCMD_svn``).
-   :term:`FILE`
-      Points at the current file. BitBake sets this variable during the
-      parsing process to identify the file being parsed. BitBake also sets
-      this variable when a recipe is being executed to identify the recipe
-      file.
-   :term:`FILESPATH`
-      Specifies directories BitBake uses when searching for patches and
-      files. The "local" fetcher module uses these directories when
-      handling ``file://`` URLs. The variable behaves like a shell ``PATH``
-      environment variable. The value is a colon-separated list of
-      directories that are searched left-to-right in order.
-   :term:`FILE_LAYERNAME`
-      During parsing and task execution, this is set to the name of the
-      layer containing the recipe file. Code can use this to identify which
-      layer a recipe is from.
-   :term:`GITDIR`
-      The directory in which a local copy of a Git repository is stored
-      when it is cloned.
-   :term:`HGDIR`
-      The directory in which files checked out of a Mercurial system are
-      stored.
-   :term:`HOMEPAGE`
-      Website where more information about the software the recipe is
-      building can be found.
-   :term:`INHERIT`
-      Causes the named class or classes to be inherited globally. Anonymous
-      functions in the class or classes are not executed for the base
-      configuration and in each individual recipe. The OpenEmbedded build
-      system ignores changes to :term:`INHERIT` in individual recipes.
-      For more information on :term:`INHERIT`, see the
-      ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`"
-      section.
-   :term:`LAYERDEPENDS`
-      Lists the layers, separated by spaces, upon which this recipe
-      depends. Optionally, you can specify a specific layer version for a
-      dependency by adding it to the end of the layer name with a colon,
-      (e.g. "anotherlayer:3" to be compared against
-      :term:`LAYERVERSION`\ ``_anotherlayer`` in
-      this case). BitBake produces an error if any dependency is missing or
-      the version numbers do not match exactly (if specified).
-      You use this variable in the ``conf/layer.conf`` file. You must also
-      use the specific layer name as a suffix to the variable (e.g.
-      ``LAYERDEPENDS_mylayer``).
-   :term:`LAYERDIR`
-      When used inside the ``layer.conf`` configuration file, this variable
-      provides the path of the current layer. This variable is not
-      available outside of ``layer.conf`` and references are expanded
-      immediately when parsing of the file completes.
-   :term:`LAYERDIR_RE`
-      When used inside the ``layer.conf`` configuration file, this variable
-      provides the path of the current layer, escaped for use in a regular
-      expression (:term:`BBFILE_PATTERN`). This
-      variable is not available outside of ``layer.conf`` and references
-      are expanded immediately when parsing of the file completes.
-   :term:`LAYERSERIES_COMPAT`
-      Lists the versions of the OpenEmbedded-Core (OE-Core) for which
-      a layer is compatible. Using the :term:`LAYERSERIES_COMPAT` variable
-      allows the layer maintainer to indicate which combinations of the
-      layer and OE-Core can be expected to work. The variable gives the
-      system a way to detect when a layer has not been tested with new
-      releases of OE-Core (e.g. the layer is not maintained).
-      To specify the OE-Core versions for which a layer is compatible, use
-      this variable in your layer's ``conf/layer.conf`` configuration file.
-      For the list, use the Yocto Project release name (e.g. "kirkstone",
-      "mickledore"). To specify multiple OE-Core versions for the layer, use
-      a space-separated list::
-         LAYERSERIES_COMPAT_layer_root_name = "kirkstone mickledore"
-      .. note::
-         Setting :term:`LAYERSERIES_COMPAT` is required by the Yocto Project
-         Compatible version 2 standard.
-         The OpenEmbedded build system produces a warning if the variable
-         is not set for any given layer.
-   :term:`LAYERVERSION`
-      Optionally specifies the version of a layer as a single number. You
-      can use this variable within
-      :term:`LAYERDEPENDS` for another layer in
-      order to depend on a specific version of the layer.
-      You use this variable in the ``conf/layer.conf`` file. You must also
-      use the specific layer name as a suffix to the variable (e.g.
-      ``LAYERDEPENDS_mylayer``).
-   :term:`LICENSE`
-      The list of source licenses for the recipe.
-   :term:`MIRRORS`
-      Specifies additional paths from which BitBake gets source code. When
-      the build system searches for source code, it first tries the local
-      download directory. If that location fails, the build system tries
-      locations defined by :term:`PREMIRRORS`, the
-      upstream source, and then locations specified by :term:`MIRRORS` in that
-      order.
-   :term:`OVERRIDES`
-      A colon-separated list that BitBake uses to control what variables are
-      overridden after BitBake parses recipes and configuration files.
-      Following is a simple example that uses an overrides list based on
-      machine architectures: OVERRIDES = "arm:x86:mips:powerpc" You can
-      find information on how to use :term:`OVERRIDES` in the
-      ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax
-      (overrides)`" section.
-   :term:`P4DIR`
-      The directory in which a local copy of a Perforce depot is stored
-      when it is fetched.
-   :term:`PACKAGES`
-      The list of packages the recipe creates.
-   :term:`PACKAGES_DYNAMIC`
-      A promise that your recipe satisfies runtime dependencies for
-      optional modules that are found in other recipes.
-      :term:`PACKAGES_DYNAMIC` does not actually satisfy the dependencies, it
-      only states that they should be satisfied. For example, if a hard,
-      runtime dependency (:term:`RDEPENDS`) of another
-      package is satisfied during the build through the
-      :term:`PACKAGES_DYNAMIC` variable, but a package with the module name is
-      never actually produced, then the other package will be broken.
-   :term:`PE`
-      The epoch of the recipe. By default, this variable is unset. The
-      variable is used to make upgrades possible when the versioning scheme
-      changes in some backwards incompatible way.
-   :term:`PERSISTENT_DIR`
-      Specifies the directory BitBake uses to store data that should be
-      preserved between builds. In particular, the data stored is the data
-      that uses BitBake's persistent data API and the data used by the PR
-      Server and PR Service.
-   :term:`PF`
-      Specifies the recipe or package name and includes all version and
-      revision numbers (i.e. ``eglibc-2.13-r20+svnr15508/`` and
-      ``bash-4.2-r1/``).
-   :term:`PN`
-      The recipe name.
-   :term:`PR`
-      The revision of the recipe.
-   :term:`PREFERRED_PROVIDER`
-      Determines which recipe should be given preference when multiple
-      recipes provide the same item. You should always suffix the variable
-      with the name of the provided item, and you should set it to the
-      :term:`PN` of the recipe to which you want to give
-      precedence. Some examples::
-         PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-         PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
-         PREFERRED_PROVIDER_virtual/libgl ?= "mesa"
-   :term:`PREFERRED_PROVIDERS`
-      Determines which recipe should be given preference for cases where
-      multiple recipes provide the same item. Functionally,
-      :term:`PREFERRED_PROVIDERS` is identical to
-      :term:`PREFERRED_PROVIDER`. However, the :term:`PREFERRED_PROVIDERS` variable
-      lets you define preferences for multiple situations using the following
-      form::
-         PREFERRED_PROVIDERS = "xxx:yyy aaa:bbb ..."
-      This form is a convenient replacement for the following::
-         PREFERRED_PROVIDER_xxx = "yyy"
-         PREFERRED_PROVIDER_aaa = "bbb"
-   :term:`PREFERRED_VERSION`
-      If there are multiple versions of a recipe available, this variable
-      determines which version should be given preference. You must always
-      suffix the variable with the :term:`PN` you want to
-      select, and you should set :term:`PV` accordingly for
-      precedence.
-      The :term:`PREFERRED_VERSION` variable supports limited wildcard use
-      through the "``%``" character. You can use the character to match any
-      number of characters, which can be useful when specifying versions
-      that contain long revision numbers that potentially change. Here are
-      two examples::
-         PREFERRED_VERSION_python = "2.7.3"
-         PREFERRED_VERSION_linux-yocto = "4.12%"
-      .. important::
-         The use of the " % " character is limited in that it only works at the
-         end of the string. You cannot use the wildcard character in any other
-         location of the string.
-      If a recipe with the specified version is not available, a warning
-      message will be shown. See :term:`REQUIRED_VERSION` if you want this
-      to be an error instead.
-   :term:`PREMIRRORS`
-      Specifies additional paths from which BitBake gets source code. When
-      the build system searches for source code, it first tries the local
-      download directory. If that location fails, the build system tries
-      locations defined by :term:`PREMIRRORS`, the upstream source, and then
-      locations specified by :term:`MIRRORS` in that order.
-      Typically, you would add a specific server for the build system to
-      attempt before any others by adding something like the following to
-      your configuration::
-         PREMIRRORS:prepend = "\
-         git://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \
-         ftp://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \
-         http://.*/.* http://downloads.yoctoproject.org/mirror/sources/ \
-         https://.*/.* http://downloads.yoctoproject.org/mirror/sources/"
-      These changes cause the build system to intercept Git, FTP, HTTP, and
-      HTTPS requests and direct them to the ``http://`` sources mirror. You can
-      use ``file://`` URLs to point to local directories or network shares as
-      well.
-   :term:`PROVIDES`
-      A list of aliases by which a particular recipe can be known. By
-      default, a recipe's own :term:`PN` is implicitly already in its
-      :term:`PROVIDES` list. If a recipe uses :term:`PROVIDES`, the additional
-      aliases are synonyms for the recipe and can be useful satisfying
-      dependencies of other recipes during the build as specified by
-      :term:`DEPENDS`.
-      Consider the following example :term:`PROVIDES` statement from a recipe
-      file ``libav_0.8.11.bb``::
-         PROVIDES += "libpostproc"
-      The :term:`PROVIDES` statement results in the "libav" recipe also being known
-      as "libpostproc".
-      In addition to providing recipes under alternate names, the
-      :term:`PROVIDES` mechanism is also used to implement virtual targets. A
-      virtual target is a name that corresponds to some particular
-      functionality (e.g. a Linux kernel). Recipes that provide the
-      functionality in question list the virtual target in :term:`PROVIDES`.
-      Recipes that depend on the functionality in question can include the
-      virtual target in :term:`DEPENDS` to leave the
-      choice of provider open.
-      Conventionally, virtual targets have names on the form
-      "virtual/function" (e.g. "virtual/kernel"). The slash is simply part
-      of the name and has no syntactical significance.
-   :term:`PRSERV_HOST`
-      The network based :term:`PR` service host and port.
-      Following is an example of how the :term:`PRSERV_HOST` variable is set::
-         PRSERV_HOST = "localhost:0"
-      You must set the variable if you want to automatically start a local PR
-      service. You can set :term:`PRSERV_HOST` to other values to use a remote PR
-      service.
-   :term:`PV`
-      The version of the recipe.
-   :term:`RDEPENDS`
-      Lists a package's runtime dependencies (i.e. other packages) that
-      must be installed in order for the built package to run correctly. If
-      a package in this list cannot be found during the build, you will get
-      a build error.
-      Because the :term:`RDEPENDS` variable applies to packages being built,
-      you should always use the variable in a form with an attached package
-      name. For example, suppose you are building a development package
-      that depends on the ``perl`` package. In this case, you would use the
-      following :term:`RDEPENDS` statement::
-         RDEPENDS:${PN}-dev += "perl"
-      In the example, the development package depends on the ``perl`` package.
-      Thus, the :term:`RDEPENDS` variable has the ``${PN}-dev`` package name as part
-      of the variable.
-      BitBake supports specifying versioned dependencies. Although the
-      syntax varies depending on the packaging format, BitBake hides these
-      differences from you. Here is the general syntax to specify versions
-      with the :term:`RDEPENDS` variable::
-         RDEPENDS:${PN} = "package (operator version)"
-      For ``operator``, you can specify the following::
-         =
-         <
-         >
-         <=
-         >=
-      For example, the following sets up a dependency on version 1.2 or
-      greater of the package ``foo``::
-         RDEPENDS:${PN} = "foo (>= 1.2)"
-      For information on build-time dependencies, see the :term:`DEPENDS`
-      variable.
-   :term:`REPODIR`
-      The directory in which a local copy of a ``google-repo`` directory is
-      stored when it is synced.
-   :term:`REQUIRED_VERSION`
-      If there are multiple versions of a recipe available, this variable
-      determines which version should be given preference. :term:`REQUIRED_VERSION`
-      works in exactly the same manner as :term:`PREFERRED_VERSION`, except
-      that if the specified version is not available then an error message
-      is shown and the build fails immediately.
-      If both :term:`REQUIRED_VERSION` and :term:`PREFERRED_VERSION` are set for
-      the same recipe, the :term:`REQUIRED_VERSION` value applies.
-   :term:`RPROVIDES`
-      A list of package name aliases that a package also provides. These
-      aliases are useful for satisfying runtime dependencies of other
-      packages both during the build and on the target (as specified by
-      :term:`RDEPENDS`).
-      As with all package-controlling variables, you must always use the
-      variable in conjunction with a package name override. Here is an
-      example::
-         RPROVIDES:${PN} = "widget-abi-2"
-   :term:`RRECOMMENDS`
-      A list of packages that extends the usability of a package being
-      built. The package being built does not depend on this list of
-      packages in order to successfully build, but needs them for the
-      extended usability. To specify runtime dependencies for packages, see
-      the :term:`RDEPENDS` variable.
-      BitBake supports specifying versioned recommends. Although the syntax
-      varies depending on the packaging format, BitBake hides these
-      differences from you. Here is the general syntax to specify versions
-      with the :term:`RRECOMMENDS` variable::
-         RRECOMMENDS:${PN} = "package (operator version)"
-      For ``operator``, you can specify the following::
-         =
-         <
-         >
-         <=
-         >=
-      For example, the following sets up a recommend on version
-      1.2 or greater of the package ``foo``::
-         RRECOMMENDS:${PN} = "foo (>= 1.2)"
-   :term:`SECTION`
-      The section in which packages should be categorized.
-   :term:`SRC_URI`
-      The list of source files --- local or remote. This variable tells
-      BitBake which bits to pull for the build and how to pull them. For
-      example, if the recipe or append file needs to fetch a single tarball
-      from the Internet, the recipe or append file uses a :term:`SRC_URI`
-      entry that specifies that tarball. On the other hand, if the recipe or
-      append file needs to fetch a tarball, apply two patches, and include
-      a custom file, the recipe or append file needs an :term:`SRC_URI`
-      variable that specifies all those sources.
-      The following list explains the available URI protocols. URI
-      protocols are highly dependent on particular BitBake Fetcher
-      submodules. Depending on the fetcher BitBake uses, various URL
-      parameters are employed. For specifics on the supported Fetchers, see
-      the :ref:`bitbake-user-manual/bitbake-user-manual-fetching:fetchers`
-      section.
-      -  ``az://``: Fetches files from an Azure Storage account using HTTPS.
-      -  ``bzr://``: Fetches files from a Bazaar revision control
-         repository.
-      -  ``ccrc://``: Fetches files from a ClearCase repository.
-      -  ``cvs://``: Fetches files from a CVS revision control
-         repository.
-      -  ``file://``: Fetches files, which are usually files shipped
-         with the Metadata, from the local machine.
-         The path is relative to the :term:`FILESPATH`
-         variable. Thus, the build system searches, in order, from the
-         following directories, which are assumed to be a subdirectories of
-         the directory in which the recipe file (``.bb``) or append file
-         (``.bbappend``) resides:
-         -  ``${BPN}``: the base recipe name without any special suffix
-            or version numbers.
-         -  ``${BP}`` - ``${BPN}-${PV}``: the base recipe name and
-            version but without any special package name suffix.
-         -  ``files``: files within a directory, which is named ``files``
-            and is also alongside the recipe or append file.
-      -  ``ftp://``: Fetches files from the Internet using FTP.
-      -  ``git://``: Fetches files from a Git revision control
-         repository.
-      -  ``gitsm://``: Fetches submodules from a Git revision control
-         repository.
-      -  ``hg://``: Fetches files from a Mercurial (``hg``) revision
-         control repository.
-      -  ``http://``: Fetches files from the Internet using HTTP.
-      -  ``https://``: Fetches files from the Internet using HTTPS.
-      -  ``npm://``: Fetches JavaScript modules from a registry.
-      -  ``osc://``: Fetches files from an OSC (OpenSUSE Build service)
-         revision control repository.
-      -  ``p4://``: Fetches files from a Perforce (``p4``) revision
-         control repository.
-      -  ``repo://``: Fetches files from a repo (Git) repository.
-      -  ``ssh://``: Fetches files from a secure shell.
-      -  ``svn://``: Fetches files from a Subversion (``svn``) revision
-         control repository.
-      Here are some additional options worth mentioning:
-      -  ``downloadfilename``: Specifies the filename used when storing
-         the downloaded file.
-      -  ``name``: Specifies a name to be used for association with
-         :term:`SRC_URI` checksums or :term:`SRCREV` when you have more than one
-         file or git repository specified in :term:`SRC_URI`. For example::
-            SRC_URI = "git://example.com/foo.git;branch=main;name=first \
-                       git://example.com/bar.git;branch=main;name=second \
-                       http://example.com/file.tar.gz;name=third"
-            SRCREV_first = "f1d2d2f924e986ac86fdf7b36c94bcdf32beec15"
-            SRCREV_second = "e242ed3bffccdf271b7fbaf34ed72d089537b42f"
-            SRC_URI[third.sha256sum] = "13550350a8681c84c861aac2e5b440161c2b33a3e4f302ac680ca5b686de48de"
-      -  ``subdir``: Places the file (or extracts its contents) into the
-         specified subdirectory. This option is useful for unusual tarballs
-         or other archives that do not have their files already in a
-         subdirectory within the archive.
-      -  ``subpath``: Limits the checkout to a specific subpath of the
-         tree when using the Git fetcher is used.
-      -  ``unpack``: Controls whether or not to unpack the file if it is
-         an archive. The default action is to unpack the file.
-   :term:`SRCDATE`
-      The date of the source code used to build the package. This variable
-      applies only if the source was fetched from a Source Code Manager
-      (SCM).
-   :term:`SRCREV`
-      The revision of the source code used to build the package. This
-      variable applies only when using Subversion, Git, Mercurial and
-      Bazaar. If you want to build a fixed revision and you want to avoid
-      performing a query on the remote repository every time BitBake parses
-      your recipe, you should specify a :term:`SRCREV` that is a full revision
-      identifier and not just a tag.
-   :term:`SRCREV_FORMAT`
-      Helps construct valid :term:`SRCREV` values when
-      multiple source controlled URLs are used in
-      :term:`SRC_URI`.
-      The system needs help constructing these values under these
-      circumstances. Each component in the :term:`SRC_URI` is assigned a name
-      and these are referenced in the :term:`SRCREV_FORMAT` variable. Consider
-      an example with URLs named "machine" and "meta". In this case,
-      :term:`SRCREV_FORMAT` could look like "machine_meta" and those names
-      would have the SCM versions substituted into each position. Only one
-      ``AUTOINC`` placeholder is added and if needed. And, this placeholder
-      is placed at the start of the returned string.
-   :term:`STAMP`
-      Specifies the base path used to create recipe stamp files. The path
-      to an actual stamp file is constructed by evaluating this string and
-      then appending additional information.
-   :term:`STAMPCLEAN`
-      Specifies the base path used to create recipe stamp files. Unlike the
-      :term:`STAMP` variable, :term:`STAMPCLEAN` can contain
-      wildcards to match the range of files a clean operation should
-      remove. BitBake uses a clean operation to remove any other stamps it
-      should be removing when creating a new stamp.
-   :term:`SUMMARY`
-      A short summary for the recipe, which is 72 characters or less.
-   :term:`SVNDIR`
-      The directory in which files checked out of a Subversion system are
-      stored.
-   :term:`T`
-      Points to a directory were BitBake places temporary files, which
-      consist mostly of task logs and scripts, when building a particular
-      recipe.
-   :term:`TOPDIR`
-      Points to the build directory. BitBake automatically sets this
-      variable.
diff --git a/bitbake/doc/bitbake-user-manual/figures/bb_multiconfig_files.png b/bitbake/doc/bitbake-user-manual/figures/bb_multiconfig_files.png
deleted file mode 100644
index 041f06403b..0000000000
--- a/bitbake/doc/bitbake-user-manual/figures/bb_multiconfig_files.png
+++ /dev/null
Binary files differ
diff --git a/bitbake/doc/bitbake-user-manual/figures/bitbake-title.png b/bitbake/doc/bitbake-user-manual/figures/bitbake-title.png
deleted file mode 100644
index cb290154da..0000000000
--- a/bitbake/doc/bitbake-user-manual/figures/bitbake-title.png
+++ /dev/null
Binary files differ
diff --git a/bitbake/doc/bitbake.1 b/bitbake/doc/bitbake.1
deleted file mode 100644
index 7fc1652ecd..0000000000
--- a/bitbake/doc/bitbake.1
+++ /dev/null
@@ -1,142 +0,0 @@
-.\"                                      Hey, EMACS: -*- nroff -*-
-.\" First parameter, NAME, should be all caps
-.\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
-.\" other parameters are allowed: see man(7), man(1)
-.TH BITBAKE 1 "November 19, 2006"
-.\" Please adjust this date whenever revising the manpage.
-.\"
-.\" Some roff macros, for reference:
-.\" .nh        disable hyphenation
-.\" .hy        enable hyphenation
-.\" .ad l      left justify
-.\" .ad b      justify to both left and right margins
-.\" .nf        disable filling
-.\" .fi        enable filling
-.\" .br        insert line break
-.\" .sp <n>    insert n+1 empty lines
-.\" for manpage-specific macros, see man(7)
-.SH NAME
-BitBake \- simple tool for the execution of tasks
-.SH SYNOPSIS
-.B bitbake
-.RI [ options ] " packagenames"
-.br
-.SH DESCRIPTION
-This manual page documents briefly the
-.B bitbake
-command.
-.PP
-.\" TeX users may be more comfortable with the \fB<whatever>\fP and
-.\" \fI<whatever>\fP escape sequences to invode bold face and italics, 
-.\" respectively.
-\fBbitbake\fP is a program that executes the specified task (default is 'build')
-for a given set of BitBake files.
-.br
-It expects that BBFILES is defined, which is a space separated list of files to
-be executed. BBFILES does support wildcards.
-.br
-Default BBFILES are the .bb files in the current directory.
-.SH OPTIONS
-This program follow the usual GNU command line syntax, with long
-options starting with two dashes (`-').
-.TP
-.B \-h, \-\-help
-Show summary of options.
-.TP
-.B \-\-version
-Show version of program.
-.TP
-.B \-bBUILDFILE, \-\-buildfile=BUILDFILE
-execute the task against this .bb file, rather than a package from BBFILES.
-.TP
-.B \-k, \-\-continue
-continue as much as possible after an error. While the target that failed, and
-those that depend on it, cannot be remade, the other dependencies of these
-targets can be processed all the same.
-.TP
-.B \-a, \-\-tryaltconfigs
-continue with builds by trying to use alternative providers where possible.
-.TP
-.B \-f, \-\-force
-force run of specified cmd, regardless of stamp status
-.TP
-.B \-i, \-\-interactive
-drop into the interactive mode also called the BitBake shell.
-.TP
-.B \-cCMD, \-\-cmd=CMD
-Specify task to execute. Note that this only executes the specified task for
-the providee and the packages it depends on, i.e. 'compile' does not implicitly
-call stage for the dependencies (IOW: use only if you know what you are doing).
-Depending on the base.bbclass a listtasks task is defined and will show
-available tasks.
-.TP
-.B \-rFILE, \-\-read=FILE 
-read the specified file before bitbake.conf
-.TP
-.B \-v, \-\-verbose
-output more chit-chat to the terminal
-.TP
-.B \-D, \-\-debug
-Increase the debug level. You can specify this more than once.
-.TP
-.B \-n, \-\-dry-run
-don't execute, just go through the motions
-.TP
-.B \-p, \-\-parse-only
-quit after parsing the BB files (developers only)
-.TP
-.B \-s, \-\-show-versions
-show current and preferred versions of all packages
-.TP
-.B \-e, \-\-environment
-show the global or per-recipe environment (this is what used to be bbread)
-.TP
-.B \-g, \-\-graphviz
-emit the dependency trees of the specified packages in the dot syntax
-.TP
-.B \-IIGNORED\_DOT\_DEPS, \-\-ignore-deps=IGNORED_DOT_DEPS
-Stop processing at the given list of dependencies when generating dependency
-graphs. This can help to make the graph more appealing
-.TP
-.B \-lDEBUG_DOMAINS, \-\-log-domains=DEBUG_DOMAINS
-Show debug logging for the specified logging domains
-.TP
-.B \-P, \-\-profile
-profile the command and print a report
-.TP
-.B \-uUI, \-\-ui=UI
-User interface to use. Currently, knotty, taskexp or ncurses can be specified as UI.
-.TP
-.B \-tSERVERTYPE, \-\-servertype=SERVERTYPE
-Choose which server to use, none, process or xmlrpc.
-.TP
-.B \-\-revisions-changed
-Set the exit code depending on whether upstream floating revisions have changed or not.
-.TP
-.B \-\-server-only
-Run bitbake without UI,  the frontend can connect with bitbake server itself.
-.TP
-.B \-BBIND, \-\-bind=BIND
-The name/address for the bitbake server to bind to.
-.TP
-.B \-\-no\-setscene
-Do not run any setscene tasks, forces builds.
-.SH ENVIRONMENT VARIABLES
-bitbake uses the following environment variables to control its
-operation:
-.TP
-.B BITBAKE_UI
-The bitbake user interface; overridden by the \fB-u\fP commandline option.
-.SH AUTHORS
-BitBake was written by 
-Phil Blundell,
-Holger Freyther,
-Chris Larson,
-Mickey Lauer,
-Richard Purdie,
-Holger Schurig
-.PP
-This manual page was written by Marcin Juszkiewicz <marcin@hrw.one.pl>
-for the Debian project (but may be used by others).
diff --git a/bitbake/doc/conf.py b/bitbake/doc/conf.py
deleted file mode 100644
index f61241e28b..0000000000
--- a/bitbake/doc/conf.py
+++ /dev/null
@@ -1,108 +0,0 @@
-# Configuration file for the Sphinx documentation builder.
-#
-# This file only contains a selection of the most common options. For a full
-# list see the documentation:
-# https://www.sphinx-doc.org/en/master/usage/configuration.html
-# -- Path setup --------------------------------------------------------------
-# If extensions (or modules to document with autodoc) are in another directory,
-# add these directories to sys.path here. If the directory is relative to the
-# documentation root, use os.path.abspath to make it absolute, like shown here.
-#
-# import os
-# import sys
-# sys.path.insert(0, os.path.abspath('.'))
-import sys
-import datetime
-from pathlib import Path
-current_version = "dev"
-# String used in sidebar
-version = 'Version: ' + current_version
-if current_version == 'dev':
-    version = 'Version: Current Development'
-# Version seen in documentation_options.js and hence in js switchers code
-release = current_version
-# -- Project information -----------------------------------------------------
-project = 'Bitbake'
-copyright = '2004-%s, Richard Purdie, Chris Larson, and Phil Blundell' \
-    % datetime.datetime.now().year
-author = 'Richard Purdie, Chris Larson, and Phil Blundell'
-# external links and substitutions
-extlinks = {
-    'yocto_docs': ('https://docs.yoctoproject.org%s', None),
-    'oe_lists': ('https://lists.openembedded.org%s', None),
-}
-# -- General configuration ---------------------------------------------------
-# Add any Sphinx extension module names here, as strings. They can be
-# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
-# ones.
-extensions = [
-    'sphinx.ext.autosectionlabel',
-    'sphinx.ext.extlinks',
-    'sphinx.ext.autodoc',
-]
-autosectionlabel_prefix_document = True
-# Add any paths that contain templates here, relative to this directory.
-templates_path = ['_templates']
-# List of patterns, relative to source directory, that match files and
-# directories to ignore when looking for source files.
-# This pattern also affects html_static_path and html_extra_path.
-exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store']
-# master document name. The default changed from contents to index. so better
-# set it ourselves.
-master_doc = 'index'
-# create substitution for project configuration variables
-rst_prolog = """
-.. |project_name| replace:: %s
-.. |copyright| replace:: %s
-.. |author| replace:: %s
-""" % (project, copyright, author)
-# -- Options for HTML output -------------------------------------------------
-# The theme to use for HTML and HTML Help pages.  See the documentation for
-# a list of builtin themes.
-#
-try:
-    import sphinx_rtd_theme
-    html_theme = 'sphinx_rtd_theme'
-except ImportError:
-    sys.stderr.write("The Sphinx sphinx_rtd_theme HTML theme was not found.\
-    \nPlease make sure to install the sphinx_rtd_theme python package.\n")
-    sys.exit(1)
-# Add any paths that contain custom static files (such as style sheets) here,
-# relative to this directory. They are copied after the builtin static files,
-# so a file named "default.css" will overwrite the builtin "default.css".
-html_static_path = ['sphinx-static']
-# Add customm CSS and JS files
-html_css_files = ['theme_overrides.css']
-html_js_files = ['switchers.js']
-# Hide 'Created using Sphinx' text
-html_show_sphinx = False
-# Add 'Last updated' on each page
-html_last_updated_fmt = '%b %d, %Y'
-# Remove the trailing 'dot' in section numbers
-html_secnumber_suffix = " "
-# autoconf needs the modules available to auto-generate documentation from the
-# code
-sys.path.insert(0, str(Path('..', 'lib').resolve()))
diff --git a/bitbake/doc/genindex.rst b/bitbake/doc/genindex.rst
deleted file mode 100644
index a4af06f656..0000000000
--- a/bitbake/doc/genindex.rst
+++ /dev/null
@@ -1,3 +0,0 @@
-=====
-Index
-=====
diff --git a/bitbake/doc/index.rst b/bitbake/doc/index.rst
deleted file mode 100644
index 546ef36c16..0000000000
--- a/bitbake/doc/index.rst
+++ /dev/null
@@ -1,40 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-===================
-BitBake User Manual
-===================
-|
-.. toctree::
-   :caption: Table of Contents
-   :numbered:
-   bitbake-user-manual/bitbake-user-manual-intro
-   bitbake-user-manual/bitbake-user-manual-execution
-   bitbake-user-manual/bitbake-user-manual-metadata
-   bitbake-user-manual/bitbake-user-manual-ref-variables-context
-   bitbake-user-manual/bitbake-user-manual-fetching
-   bitbake-user-manual/bitbake-user-manual-ref-variables
-   bitbake-user-manual/bitbake-user-manual-library-functions
-   bitbake-user-manual/bitbake-user-manual-hello
-.. toctree::
-   :maxdepth: 1
-   :hidden:
-   genindex
-   releases
----
-.. include:: <xhtml1-lat1.txt>
-| BitBake Community
-| Copyright |copy| |copyright|
-| <bitbake-devel@lists.openembedded.org>
-This work is licensed under the Creative Commons Attribution License.  To view a
-copy of this license, visit http://creativecommons.org/licenses/by/2.5/ or send
-a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View,
-California 94041, USA.
diff --git a/bitbake/doc/releases.rst b/bitbake/doc/releases.rst
deleted file mode 100644
index 676db66ec5..0000000000
--- a/bitbake/doc/releases.rst
+++ /dev/null
@@ -1,193 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-=================================
-BitBake Supported Release Manuals
-=================================
-******************************
-Release Series 5.2 (walnascar)
-******************************
- :yocto_docs:`BitBake 2.12 User Manual </bitbake/2.12/>`
-*******************************
-Release Series 5.0 (scarthgap)
-*******************************
- :yocto_docs:`BitBake 2.8 User Manual </bitbake/2.8/>`
-******************************
-Release Series 4.0 (kirkstone)
-******************************
- :yocto_docs:`BitBake 2.0 User Manual </bitbake/2.0/>`
-================================
-BitBake Outdated Release Manuals
-================================
-****************************
-Release Series 5.1 (styhead)
-****************************
- :yocto_docs:`BitBake 2.10 User Manual </bitbake/2.10/>`
-*******************************
-Release Series 4.3 (nanbield)
-*******************************
- :yocto_docs:`BitBake 2.6 User Manual </bitbake/2.6/>`
-*******************************
-Release Series 4.2 (mickledore)
-*******************************
- :yocto_docs:`BitBake 2.4 User Manual </bitbake/2.4/>`
-*****************************
-Release Series 4.1 (langdale)
-*****************************
- :yocto_docs:`BitBake 2.2 User Manual </bitbake/2.2/>`
-******************************
-Release Series 3.4 (honister)
-******************************
- :yocto_docs:`BitBake 1.52 User Manual </bitbake/1.52/>`
-******************************
-Release Series 3.3 (hardknott)
-******************************
- :yocto_docs:`BitBake 1.50 User Manual </bitbake/1.50/>`
-*******************************
-Release Series 3.2 (gatesgarth)
-*******************************
- :yocto_docs:`BitBake 1.48 User Manual </bitbake/1.48/>`
-****************************
-Release Series 3.1 (dunfell)
-****************************
- :yocto_docs:`BitBake 1.46 User Manual </bitbake/1.46/>`
- :yocto_docs:`3.1 BitBake User Manual </3.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.1.1 BitBake User Manual </3.1.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.1.2 BitBake User Manual </3.1.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.1.3 BitBake User Manual </3.1.3/bitbake-user-manual/bitbake-user-manual.html>`
-*************************
-Release Series 3.0 (zeus)
-*************************
- :yocto_docs:`3.0 BitBake User Manual </3.0/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.0.1 BitBake User Manual </3.0.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.0.2 BitBake User Manual </3.0.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.0.3 BitBake User Manual </3.0.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`3.0.4 BitBake User Manual </3.0.4/bitbake-user-manual/bitbake-user-manual.html>`
-****************************
-Release Series 2.7 (warrior)
-****************************
- :yocto_docs:`2.7 BitBake User Manual </2.7/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.7.1 BitBake User Manual </2.7.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.7.2 BitBake User Manual </2.7.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.7.3 BitBake User Manual </2.7.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.7.4 BitBake User Manual </2.7.4/bitbake-user-manual/bitbake-user-manual.html>`
-*************************
-Release Series 2.6 (thud)
-*************************
- :yocto_docs:`2.6 BitBake User Manual </2.6/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.6.1 BitBake User Manual </2.6.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.6.2 BitBake User Manual </2.6.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.6.3 BitBake User Manual </2.6.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.6.4 BitBake User Manual </2.6.4/bitbake-user-manual/bitbake-user-manual.html>`
-*************************
-Release Series 2.5 (sumo)
-*************************
- :yocto_docs:`2.5 Documentation </2.5>`
- :yocto_docs:`2.5.1 Documentation </2.5.1>`
- :yocto_docs:`2.5.2 Documentation </2.5.2>`
- :yocto_docs:`2.5.3 Documentation </2.5.3>`
-**************************
-Release Series 2.4 (rocko)
-**************************
- :yocto_docs:`2.4 BitBake User Manual </2.4/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.4.1 BitBake User Manual </2.4.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.4.2 BitBake User Manual </2.4.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.4.3 BitBake User Manual </2.4.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.4.4 BitBake User Manual </2.4.4/bitbake-user-manual/bitbake-user-manual.html>`
-*************************
-Release Series 2.3 (pyro)
-*************************
- :yocto_docs:`2.3 BitBake User Manual </2.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.3.1 BitBake User Manual </2.3.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.3.2 BitBake User Manual </2.3.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.3.3 BitBake User Manual </2.3.3/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.3.4 BitBake User Manual </2.3.4/bitbake-user-manual/bitbake-user-manual.html>`
-**************************
-Release Series 2.2 (morty)
-**************************
- :yocto_docs:`2.2 BitBake User Manual </2.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.2.1 BitBake User Manual </2.2.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.2.2 BitBake User Manual </2.2.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.2.3 BitBake User Manual </2.2.3/bitbake-user-manual/bitbake-user-manual.html>`
-****************************
-Release Series 2.1 (krogoth)
-****************************
- :yocto_docs:`2.1 BitBake User Manual </2.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.1.1 BitBake User Manual </2.1.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.1.2 BitBake User Manual </2.1.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.1.3 BitBake User Manual </2.1.3/bitbake-user-manual/bitbake-user-manual.html>`
-***************************
-Release Series 2.0 (jethro)
-***************************
- :yocto_docs:`1.9 BitBake User Manual </1.9/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.0 BitBake User Manual </2.0/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.0.1 BitBake User Manual </2.0.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.0.2 BitBake User Manual </2.0.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`2.0.3 BitBake User Manual </2.0.3/bitbake-user-manual/bitbake-user-manual.html>`
-*************************
-Release Series 1.8 (fido)
-*************************
- :yocto_docs:`1.8 BitBake User Manual </1.8/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.8.1 BitBake User Manual </1.8.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.8.2 BitBake User Manual </1.8.2/bitbake-user-manual/bitbake-user-manual.html>`
-**************************
-Release Series 1.7 (dizzy)
-**************************
- :yocto_docs:`1.7 BitBake User Manual </1.7/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.7.1 BitBake User Manual </1.7.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.7.2 BitBake User Manual </1.7.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.7.3 BitBake User Manual </1.7.3/bitbake-user-manual/bitbake-user-manual.html>`
-**************************
-Release Series 1.6 (daisy)
-**************************
- :yocto_docs:`1.6 BitBake User Manual </1.6/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.6.1 BitBake User Manual </1.6.1/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.6.2 BitBake User Manual </1.6.2/bitbake-user-manual/bitbake-user-manual.html>`
- :yocto_docs:`1.6.3 BitBake User Manual </1.6.3/bitbake-user-manual/bitbake-user-manual.html>`
diff --git a/bitbake/doc/sphinx-static/switchers.js b/bitbake/doc/sphinx-static/switchers.js
deleted file mode 100644
index 32113cfa96..0000000000
--- a/bitbake/doc/sphinx-static/switchers.js
+++ /dev/null
@@ -1,233 +0,0 @@
-(function() {
-  'use strict';
-  var all_versions = {
-    'dev': 'dev (3.2)',
-    '3.1.2': '3.1.2',
-    '3.0.3': '3.0.3',
-    '2.7.4': '2.7.4',
-  };
-  var all_doctypes = {
-      'single': 'Individual Webpages',
-      'mega': "All-in-one 'Mega' Manual",
-  };
-  // Simple version comparision
-  // Return 1 if a > b
-  // Return -1 if a < b
-  // Return 0 if a == b
-  function ver_compare(a, b) {
-    if (a == "dev") {
-       return 1;
-    }
-    if (a === b) {
-       return 0;
-    }
-    var a_components = a.split(".");
-    var b_components = b.split(".");
-    var len = Math.min(a_components.length, b_components.length);
-    // loop while the components are equal
-    for (var i = 0; i < len; i++) {
-        // A bigger than B
-        if (parseInt(a_components[i]) > parseInt(b_components[i])) {
-            return 1;
-        }
-        // B bigger than A
-        if (parseInt(a_components[i]) < parseInt(b_components[i])) {
-            return -1;
-        }
-    }
-    // If one's a prefix of the other, the longer one is greater.
-    if (a_components.length > b_components.length) {
-        return 1;
-    }
-    if (a_components.length < b_components.length) {
-        return -1;
-    }
-    // Otherwise they are the same.
-    return 0;
-  }
-  function build_version_select(current_series, current_version) {
-    var buf = ['<select>'];
-    $.each(all_versions, function(version, title) {
-      var series = version.substr(0, 3);
-      if (series == current_series) {
-        if (version == current_version)
-            buf.push('<option value="' + version + '" selected="selected">' + title + '</option>');
-        else
-            buf.push('<option value="' + version + '">' + title + '</option>');
-        if (version != current_version)
-            buf.push('<option value="' + current_version + '" selected="selected">' + current_version + '</option>');
-      } else {
-        buf.push('<option value="' + version + '">' + title + '</option>');
-      }
-    });
-    buf.push('</select>');
-    return buf.join('');
-  }
-  function build_doctype_select(current_doctype) {
-    var buf = ['<select>'];
-    $.each(all_doctypes, function(doctype, title) {
-      if (doctype == current_doctype)
-        buf.push('<option value="' + doctype + '" selected="selected">' +
-                 all_doctypes[current_doctype] + '</option>');
-      else
-        buf.push('<option value="' + doctype + '">' + title + '</option>');
-    });
-    if (!(current_doctype in all_doctypes)) {
-        // In case we're browsing a doctype that is not yet in all_doctypes.
-        buf.push('<option value="' + current_doctype + '" selected="selected">' +
-                 current_doctype + '</option>');
-        all_doctypes[current_doctype] = current_doctype;
-    }
-    buf.push('</select>');
-    return buf.join('');
-  }
-  function navigate_to_first_existing(urls) {
-    // Navigate to the first existing URL in urls.
-    var url = urls.shift();
-    // Web browsers won't redirect file:// urls to file urls using ajax but
-    // its useful for local testing
-    if (url.startsWith("file://")) {
-      window.location.href = url;
-      return;
-    }
-    if (urls.length == 0) {
-      window.location.href = url;
-      return;
-    }
-    $.ajax({
-      url: url,
-      success: function() {
-        window.location.href = url;
-      },
-      error: function() {
-        navigate_to_first_existing(urls);
-      }
-    });
-  }
-  function get_docroot_url() {
-    var url = window.location.href;
-    var root = DOCUMENTATION_OPTIONS.URL_ROOT;
-    var urlarray = url.split('/');
-    // Trim off anything after '/'
-    urlarray.pop();
-    var depth = (root.match(/\.\.\//g) || []).length;
-    for (var i = 0; i < depth; i++) {
-      urlarray.pop();
-    }
-    return urlarray.join('/') + '/';
-  }
-  function on_version_switch() {
-    var selected_version = $(this).children('option:selected').attr('value');
-    var url = window.location.href;
-    var current_version = DOCUMENTATION_OPTIONS.VERSION;
-    var docroot = get_docroot_url()
-    var new_versionpath = selected_version + '/';
-    if (selected_version == "dev")
-        new_versionpath = '';
-    // dev versions have no version prefix
-    if (current_version == "dev") {
-        var new_url = docroot + new_versionpath + url.replace(docroot, "");
-        var fallback_url = docroot + new_versionpath;
-    } else {
-        var new_url = url.replace('/' + current_version + '/', '/' + new_versionpath);
-        var fallback_url = new_url.replace(url.replace(docroot, ""), "");
-    }
-    console.log(get_docroot_url())
-    console.log(url + " to url " + new_url);
-    console.log(url + " to fallback " + fallback_url);
-    if (new_url != url) {
-      navigate_to_first_existing([
-        new_url,
-        fallback_url,
-        'https://www.yoctoproject.org/docs/',
-      ]);
-    }
-  }
-  function on_doctype_switch() {
-    var selected_doctype = $(this).children('option:selected').attr('value');
-    var url = window.location.href;
-    if (selected_doctype == 'mega') {
-      var docroot = get_docroot_url()
-      var current_version = DOCUMENTATION_OPTIONS.VERSION;
-      // Assume manuals before 3.2 are using old docbook mega-manual
-      if (ver_compare(current_version, "3.2") < 0) {
-        var new_url = docroot + "mega-manual/mega-manual.html";
-      } else {
-        var new_url = docroot + "singleindex.html";
-      }
-    } else {
-      var new_url = url.replace("singleindex.html", "index.html")
-    }
-    if (new_url != url) {
-      navigate_to_first_existing([
-        new_url,
-        'https://www.yoctoproject.org/docs/',
-      ]);
-    }
-  }
-  // Returns the current doctype based upon the url
-  function doctype_segment_from_url(url) {
-    if (url.includes("singleindex") || url.includes("mega-manual"))
-      return "mega";
-    return "single";
-  }
-  $(document).ready(function() {
-    var release = DOCUMENTATION_OPTIONS.VERSION;
-    var current_doctype = doctype_segment_from_url(window.location.href);
-    var current_series = release.substr(0, 3);
-    var version_select = build_version_select(current_series, release);
-    $('.version_switcher_placeholder').html(version_select);
-    $('.version_switcher_placeholder select').bind('change', on_version_switch);
-    var doctype_select = build_doctype_select(current_doctype);
-    $('.doctype_switcher_placeholder').html(doctype_select);
-    $('.doctype_switcher_placeholder select').bind('change', on_doctype_switch);
-    if (ver_compare(release, "3.1") < 0) {
-      $('#outdated-warning').html('Version ' + release + ' of the project is now considered obsolete, please select and use a more recent version');
-      $('#outdated-warning').css('padding', '.5em');
-    } else if (release != "dev") {
-      $.each(all_versions, function(version, title) {
-        var series = version.substr(0, 3);
-        if (series == current_series && version != release) {
-          $('#outdated-warning').html('This document is for outdated version ' + release + ', you should select the latest release version in this series, ' + version + '.');
-          $('#outdated-warning').css('padding', '.5em');
-        }
-      });
-    }
-  });
-})();
diff --git a/bitbake/doc/sphinx-static/theme_overrides.css b/bitbake/doc/sphinx-static/theme_overrides.css
deleted file mode 100644
index e362677a7f..0000000000
--- a/bitbake/doc/sphinx-static/theme_overrides.css
+++ /dev/null
@@ -1,162 +0,0 @@
-/*
-    SPDX-License-Identifier: CC-BY-2.0-UK
-*/
-body {
-  font-family: Verdana, Sans, sans-serif;
-  margin:  0em auto;
-  color: #333;
-}
-h1,h2,h3,h4,h5,h6,h7 {
-  font-family: Arial, Sans;
-  color: #00557D;
-  clear: both;
-}
-h1 {
-  font-size: 2em;
-  text-align: left;
-  padding: 0em 0em 0em 0em;
-  margin: 2em 0em 0em 0em;
-}
-h2.subtitle {
-  margin: 0.10em 0em 3.0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 1.8em;
-  padding-left: 20%;
-  font-weight: normal;
-  font-style: italic;
-}
-h2 {
-  margin: 2em 0em 0.66em 0em;
-  padding: 0.5em 0em 0em 0em;
-  font-size: 1.5em;
-  font-weight: bold;
-}
-h3.subtitle {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 142.14%;
-  text-align: right;
-}
-h3 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 140%;
-  font-weight: bold;
-}
-h4 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 120%;
-  font-weight: bold;
-}
-h5 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-h6 {
-  margin: 1em 0em 0em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-em {
-  font-weight: bold;
-}
-.pre {
-  font-size: medium;
-  font-family: Courier, monospace;
-}
-.wy-nav-content a {
-  text-decoration: underline;
-  color: #444;
-  background: transparent;
-}
-.wy-nav-content a:hover {
-  text-decoration: underline;
-  background-color: #dedede;
-}
-.wy-nav-content a:visited {
-  color: #444;
-}
-[alt='Permalink'] { color: #eee; }
-[alt='Permalink']:hover { color: black; }
-@media screen {
-    /* content column
-     *
-     * RTD theme's default is 800px as max width for the content, but we have
-     * tables with tons of columns, which need the full width of the view-port.
-     */
-    .wy-nav-content{max-width: none; }
-    /* inline literal: drop the borderbox, padding and red color */
-    code, .rst-content tt, .rst-content code {
-        color: inherit;
-        border: none;
-        padding: unset;
-        background: inherit;
-        font-size: 85%;
-    }
-    .rst-content tt.literal,.rst-content tt.literal,.rst-content code.literal {
-        color: inherit;
-    }
-    /* Admonition should be gray, not blue or green */
-    .rst-content .note .admonition-title,
-    .rst-content .tip .admonition-title,
-    .rst-content .warning .admonition-title,
-    .rst-content .caution .admonition-title,
-    .rst-content .important .admonition-title {
-        background: #f0f0f2;
-        color: #00557D;
-    }
-    .rst-content .note,
-    .rst-content .tip,
-    .rst-content .important,
-    .rst-content .warning,
-    .rst-content .caution  {
-        background: #f0f0f2;
-    }
-    /* Remove the icon in front of note/tip element, and before the logo */
-    .icon-home:before, .rst-content .admonition-title:before {
-        display: none
-    }
-    /* a custom informalexample container is used in some doc */
-    .informalexample {
-        border: 1px solid;
-        border-color: #aaa;
-        margin: 1em 0em;
-        padding: 1em;
-        page-break-inside: avoid;
-    }
-    /* Remove the blue background in the top left corner, around the logo */
-    .wy-side-nav-search {
-        background: inherit;
-    }
-}
diff --git a/bitbake/doc/template/Vera.ttf b/bitbake/doc/template/Vera.ttf
deleted file mode 100644
index 58cd6b5e61..0000000000
--- a/bitbake/doc/template/Vera.ttf
+++ /dev/null
Binary files differ
diff --git a/bitbake/doc/template/VeraMoBd.ttf b/bitbake/doc/template/VeraMoBd.ttf
deleted file mode 100644
index 9be6547ed6..0000000000
--- a/bitbake/doc/template/VeraMoBd.ttf
+++ /dev/null
Binary files differ
diff --git a/bitbake/doc/template/VeraMono.ttf b/bitbake/doc/template/VeraMono.ttf
deleted file mode 100644
index 139f0b4311..0000000000
--- a/bitbake/doc/template/VeraMono.ttf
+++ /dev/null
Binary files differ
diff --git a/bitbake/doc/template/draft.png b/bitbake/doc/template/draft.png
deleted file mode 100644
index 53051a9ddd..0000000000
--- a/bitbake/doc/template/draft.png
+++ /dev/null
Binary files differ