diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst index e25f0b278c..04066e9202 100644 --- a/documentation/ref-manual/faq.rst +++ b/documentation/ref-manual/faq.rst @@ -4,9 +4,9 @@ FAQ *** -**Q:** How does Poky differ from `OpenEmbedded <&OE_HOME_URL;>`__? +**Q:** How does Poky differ from `OpenEmbedded `__? -**A:** The term "`Poky <#>`__" refers to the specific reference build +**A:** The term ``Poky`` refers to the specific reference build system that the Yocto Project provides. Poky is based on :term:`OpenEmbedded-Core (OE-Core)` and :term:`BitBake`. Thus, the generic term used here for the build system is the "OpenEmbedded build @@ -44,11 +44,10 @@ steps on how to update your build tools. **A:** Support for an additional board is added by creating a Board Support Package (BSP) layer for it. For more information on how to -create a BSP layer, see the "`Understanding and Creating -Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__" -section in the Yocto Project Development Tasks Manual and the `Yocto -Project Board Support Package (BSP) Developer's -Guide <&YOCTO_DOCS_BSP_URL;>`__. +create a BSP layer, see the +":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`" +section in the Yocto Project Development Tasks Manual and the +:doc:`../bsp-guide/bsp-guide`. Usually, if the board is not completely exotic, adding support in the Yocto Project is fairly straightforward. @@ -73,8 +72,8 @@ device. **Q:** How do I add my package to the Yocto Project? **A:** To add a package, you need to create a BitBake recipe. For -information on how to create a BitBake recipe, see the "`Writing a New -Recipe <&YOCTO_DOCS_DEV_URL;#new-recipe-writing-a-new-recipe>`__" +information on how to create a BitBake recipe, see the +":ref:`dev-manual/dev-manual-common-tasks:writing a new recipe`" section in the Yocto Project Development Tasks Manual. **Q:** Do I have to reflash my entire board with a new Yocto Project @@ -126,12 +125,18 @@ file. Following is the applicable code for setting various proxy types in the ``.wgetrc`` file. By default, these settings are disabled with comments. -To use them, remove the comments: # You can set the default proxies for -Wget to use for http, https, and ftp. # They will override the value in -the environment. #https_proxy = http://proxy.yoyodyne.com:18023/ -#http_proxy = http://proxy.yoyodyne.com:18023/ #ftp_proxy = -http://proxy.yoyodyne.com:18023/ # If you do not want to use proxy at -all, set this to off. #use_proxy = on The Yocto Project also includes a +To use them, remove the comments: :: + + # You can set the default proxies for Wget to use for http, https, and ftp. + # They will override the value in the environment. + #https_proxy = http://proxy.yoyodyne.com:18023/ + #http_proxy = http://proxy.yoyodyne.com:18023/ + #ftp_proxy = http://proxy.yoyodyne.com:18023/ + + # If you do not want to use proxy at all, set this to off. + #use_proxy = on + +The Yocto Project also includes a ``meta-poky/conf/site.conf.sample`` file that shows how to configure CVS and Git proxy servers if needed. For more information on setting up various proxy types and configuring proxy servers, see the @@ -167,8 +172,12 @@ always been traced back to hardware or virtualization issues. **A:** If you get an error message that indicates GNU ``libiconv`` is not in use but ``iconv.h`` has been included from ``libiconv``, you need to check to see if you have a previously installed version of the header -file in ``/usr/local/include``. #error GNU libiconv not in use but -included iconv.h is from libiconv If you find a previously installed +file in ``/usr/local/include``. +:: + + #error GNU libiconv not in use but included iconv.h is from libiconv + +If you find a previously installed file, you should either uninstall it or temporarily rename it and try the build again. @@ -189,20 +198,21 @@ and also any configuration information about how that package was configured and built. You can find more information on licensing in the -"`Licensing <&YOCTO_DOCS_OM_URL;#licensing>`__" section in the Yocto -Project Overview and Concepts Manual and also in the "`Maintaining Open -Source License Compliance During Your Product's -Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__" +":ref:`overview-manual/overview-manual-development-environment:licensing`" +section in the Yocto +Project Overview and Concepts Manual and also in the +":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`" section in the Yocto Project Development Tasks Manual. **Q:** How do I disable the cursor on my touchscreen device? **A:** You need to create a form factor file as described in the -"`Miscellaneous BSP-Specific Recipe -Files <&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes>`__" section in +":ref:`bsp-filelayout-misc-recipes`" section in the Yocto Project Board Support Packages (BSP) Developer's Guide. Set the ``HAVE_TOUCHSCREEN`` variable equal to one as follows: -HAVE_TOUCHSCREEN=1 +:: + + HAVE_TOUCHSCREEN=1 **Q:** How do I make sure connected network interfaces are brought up by default? @@ -210,14 +220,14 @@ default? **A:** The default interfaces file provided by the netbase recipe does not automatically bring up network interfaces. Therefore, you will need to add a BSP-specific netbase that includes an interfaces file. See the -"`Miscellaneous BSP-Specific Recipe -Files <&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes>`__" section in +":ref:`bsp-filelayout-misc-recipes`" section in the Yocto Project Board Support Packages (BSP) Developer's Guide for information on creating these types of miscellaneous recipe files. -For example, add the following files to your layer: -meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces -meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend +For example, add the following files to your layer: :: + + meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces + meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend **Q:** How do I create images with more free space? @@ -260,7 +270,7 @@ controls which ``tcmode-*.inc`` file to include from the The default value of ``TCMODE`` is "default", which tells the OpenEmbedded build system to use its internally built toolchain (i.e. ``tcmode-default.inc``). However, other patterns are accepted. In -particular, "external-*" refers to external toolchains. One example is +particular, "external-\*" refers to external toolchains. One example is the Sourcery G++ Toolchain. The support for this toolchain resides in the separate ``meta-sourcery`` layer at http://github.com/MentorEmbedded/meta-sourcery/. @@ -290,11 +300,13 @@ fail. As an example, you could add a specific server for the build system to attempt before any others by adding something like the following to the -``local.conf`` configuration file: PREMIRRORS_prepend = "\\ git://.*/.\* -http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\* -http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\* -http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\* -http://www.yoctoproject.org/sources/ \\n" +``local.conf`` configuration file: :: + + PREMIRRORS_prepend = "\ + git://.*/.* http://www.yoctoproject.org/sources/ \n \ + ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ + http://.*/.* http://www.yoctoproject.org/sources/ \n \ + https://.*/.* http://www.yoctoproject.org/sources/ \n" These changes cause the build system to intercept Git, FTP, HTTP, and HTTPS requests and direct them to the ``http://`` sources mirror. You @@ -302,25 +314,43 @@ can use ``file://`` URLs to point to local directories or network shares as well. Aside from the previous technique, these options also exist: -BB_NO_NETWORK = "1" This statement tells BitBake to issue an error +:: + + BB_NO_NETWORK = "1" + +This statement tells BitBake to issue an error instead of trying to access the Internet. This technique is useful if you want to ensure code builds only from local sources. -Here is another technique: BB_FETCH_PREMIRRORONLY = "1" This statement +Here is another technique: +:: + + BB_FETCH_PREMIRRORONLY = "1" + +This statement limits the build system to pulling source from the ``PREMIRRORS`` only. Again, this technique is useful for reproducing builds. -Here is another technique: BB_GENERATE_MIRROR_TARBALLS = "1" This +Here is another technique: +:: + + BB_GENERATE_MIRROR_TARBALLS = "1" + +This statement tells the build system to generate mirror tarballs. This technique is useful if you want to create a mirror server. If not, however, the technique can simply waste time during the build. Finally, consider an example where you are behind an HTTP-only firewall. You could make the following changes to the ``local.conf`` configuration -file as long as the ``PREMIRRORS`` server is current: PREMIRRORS_prepend -= "\\ ftp://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ -http://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\* -http://www.yoctoproject.org/sources/ \\n" BB_FETCH_PREMIRRORONLY = "1" +file as long as the ``PREMIRRORS`` server is current: :: + + PREMIRRORS_prepend = "\ + ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ + http://.*/.* http://www.yoctoproject.org/sources/ \n \ + https://.*/.* http://www.yoctoproject.org/sources/ \n" + BB_FETCH_PREMIRRORONLY = "1" + These changes would cause the build system to successfully fetch source over HTTP and any network accesses to anything other than the ``PREMIRRORS`` would fail. @@ -384,18 +414,21 @@ that program is never installed directly to the build machine's root file system. Consequently, the build system uses paths within the Build Directory for ``DESTDIR``, ``bindir`` and related variables. To better understand this, consider the following two paths where the first is -relatively normal and the second is not: +relatively normal and the second is not: :: + + /home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/ + 1.2.8-r0/sysroot-destdir/usr/bin + + /home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/ + zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/ + build/tmp/sysroots/x86_64-linux/usr/bin .. note:: Due to these lengthy examples, the paths are artificially broken across lines for readability. -/home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/ -1.2.8-r0/sysroot-destdir/usr/bin -/home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/ -zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/ -build/tmp/sysroots/x86_64-linux/usr/bin Even if the paths look unusual, +Even if the paths look unusual, they both are correct - the first for a target and the second for a native recipe. These paths are a consequence of the ``DESTDIR`` mechanism and while they appear strange, they are correct and in diff --git a/documentation/ref-manual/migration.rst b/documentation/ref-manual/migration.rst index f834ba7004..d0d8f47932 100644 --- a/documentation/ref-manual/migration.rst +++ b/documentation/ref-manual/migration.rst @@ -15,7 +15,9 @@ Some considerations are not tied to a specific Yocto Project release. This section presents information you should consider when migrating to any new Yocto Project release. -- *Dealing with Customized Recipes*: Issues could arise if you take +- *Dealing with Customized Recipes*: + + Issues could arise if you take older recipes that contain customizations and simply copy them forward expecting them to work after you migrate to new Yocto Project metadata. For example, suppose you have a recipe in your layer that @@ -39,7 +41,9 @@ any new Yocto Project release. use an append file. A good example of this is when introducing a newer or older version of a recipe in another layer. -- *Updating Append Files*: Since append files generally only contain +- *Updating Append Files*: + + Since append files generally only contain your customizations, they often do not need to be adjusted for new releases. However, if the ``.bbappend`` file is specific to a particular version of the recipe (i.e. its name does not use the % @@ -85,8 +89,9 @@ location (either local or remote) and then point to it in :term:`SSTATE_MIRRORS`, you need to append "PATH" to the end of the mirror URL so that the path used by BitBake before the mirror substitution is appended to the path used to access the mirror. -Here is an example: SSTATE_MIRRORS = "file://.\* -http://someserver.tld/share/sstate/PATH" +Here is an example: :: + + SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH" .. _migration-1.3-bblayers-conf: @@ -107,18 +112,6 @@ Recipes Differences include changes for the following: -- Python function whitespace - -- ``proto=`` in ``SRC_URI`` - -- ``nativesdk`` - -- Task recipes - -- ``IMAGE_FEATURES`` - -- Removed recipes - .. _migration-1.3-python-function-whitespace: Python Function Whitespace @@ -205,26 +198,26 @@ unlikely that you would have any references to them in your own :term:`Metadata`. However, you should check your metadata against this list to be sure: -- *``libx11-trim``*: Replaced by ``libx11``, which has a negligible +- ``libx11-trim``: Replaced by ``libx11``, which has a negligible size difference with modern Xorg. -- *``xserver-xorg-lite``*: Use ``xserver-xorg``, which has a negligible +- ``xserver-xorg-lite``: Use ``xserver-xorg``, which has a negligible size difference when DRI and GLX modules are not installed. -- *``xserver-kdrive``*: Effectively unmaintained for many years. +- ``xserver-kdrive``: Effectively unmaintained for many years. -- *``mesa-xlib``*: No longer serves any purpose. +- ``mesa-xlib``: No longer serves any purpose. -- *``galago``*: Replaced by telepathy. +- ``galago``: Replaced by telepathy. -- *``gail``*: Functionality was integrated into GTK+ 2.13. +- ``gail``: Functionality was integrated into GTK+ 2.13. -- *``eggdbus``*: No longer needed. +- ``eggdbus``: No longer needed. -- *``gcc-*-intermediate``*: The build has been restructured to avoid +- ``gcc-*-intermediate``: The build has been restructured to avoid the need for this step. -- *``libgsmd``*: Unmaintained for many years. Functionality now +- ``libgsmd``: Unmaintained for many years. Functionality now provided by ``ofono`` instead. - *contacts, dates, tasks, eds-tools*: Largely unmaintained PIM @@ -238,8 +231,9 @@ recipes were not parsed in the default configuration. Many of these recipes are already provided in an updated and maintained form within the OpenEmbedded community layers such as ``meta-oe`` and ``meta-gnome``. For the remainder, you can now find them in the -``meta-extras`` repository, which is in the Yocto Project `Source -Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__. +``meta-extras`` repository, which is in the +:yocto_git:`Source Repositories <>` at +http://git.yoctoproject.org/cgit/cgit.cgi/meta-extras/. .. _1.3-linux-kernel-naming: @@ -248,13 +242,15 @@ Linux Kernel Naming The naming scheme for kernel output binaries has been changed to now include :term:`PE` as part of the filename: -KERNEL_IMAGE_BASE_NAME ?= -"${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}" +:: + + KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}" Because the ``PE`` variable is not set by default, these binary files could result with names that include two dash characters. Here is an -example: -bzImage--3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin +example: :: + + bzImage--3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin Moving to the Yocto Project 1.4 Release ======================================= @@ -298,8 +294,12 @@ Differences include the following: - *Shared State Code:* The shared state code has been optimized to avoid running unnecessary tasks. For example, the following no longer - populates the target sysroot since that is not necessary: $ bitbake - -c rootfs some-image Instead, the system just needs to extract the + populates the target sysroot since that is not necessary: + :: + + $ bitbake -c rootfs some-image + + Instead, the system just needs to extract the output package contents, re-create the packages, and construct the root filesystem. This change is unlikely to cause any problems unless you have missing declared dependencies. @@ -337,9 +337,9 @@ creating an append file for the ``netbase`` recipe, you now need to create an append file for the ``init-ifupdown`` recipe instead, which you can find in the :term:`Source Directory` at ``meta/recipes-core/init-ifupdown``. For information on how to use -append files, see the "`Using .bbappend -Files <&YOCTO_DOCS_DEV_URL;#using-bbappend-files>`__" section in the -Yocto Project Development Tasks Manual. +append files, see the +":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`" +section in the Yocto Project Development Tasks Manual. .. _migration-1.4-remote-debugging: @@ -360,7 +360,7 @@ Variables The following variables have changed: -- *``SANITY_TESTED_DISTROS``:* This variable now uses a distribution +- ``SANITY_TESTED_DISTROS``: This variable now uses a distribution ID, which is composed of the host distributor ID followed by the release. Previously, :term:`SANITY_TESTED_DISTROS` was @@ -369,7 +369,7 @@ The following variables have changed: you are not specifically setting this variable, or if you are specifically setting it to "". -- *``SRC_URI``:* The ``${``\ :term:`PN`\ ``}``, +- ``SRC_URI``: The ``${``\ :term:`PN`\ ``}``, ``${``\ :term:`PF`\ ``}``, ``${``\ :term:`P`\ ``}``, and ``FILE_DIRNAME`` directories have been dropped from the default value of the @@ -390,7 +390,10 @@ Target Package Management with RPM If runtime package management is enabled and the RPM backend is selected, Smart is now installed for package download, dependency resolution, and upgrades instead of Zypper. For more information on how -to use Smart, run the following command on the target: smart --help +to use Smart, run the following command on the target: +:: + + smart --help .. _migration-1.4-recipes-moved: @@ -400,29 +403,29 @@ Recipes Moved The following recipes were moved from their previous locations because they are no longer used by anything in the OpenEmbedded-Core: -- *``clutter-box2d``:* Now resides in the ``meta-oe`` layer. +- ``clutter-box2d``: Now resides in the ``meta-oe`` layer. -- *``evolution-data-server``:* Now resides in the ``meta-gnome`` layer. +- ``evolution-data-server``: Now resides in the ``meta-gnome`` layer. -- *``gthumb``:* Now resides in the ``meta-gnome`` layer. +- ``gthumb``: Now resides in the ``meta-gnome`` layer. -- *``gtkhtml2``:* Now resides in the ``meta-oe`` layer. +- ``gtkhtml2``: Now resides in the ``meta-oe`` layer. -- *``gupnp``:* Now resides in the ``meta-multimedia`` layer. +- ``gupnp``: Now resides in the ``meta-multimedia`` layer. -- *``gypsy``:* Now resides in the ``meta-oe`` layer. +- ``gypsy``: Now resides in the ``meta-oe`` layer. -- *``libcanberra``:* Now resides in the ``meta-gnome`` layer. +- ``libcanberra``: Now resides in the ``meta-gnome`` layer. -- *``libgdata``:* Now resides in the ``meta-gnome`` layer. +- ``libgdata``: Now resides in the ``meta-gnome`` layer. -- *``libmusicbrainz``:* Now resides in the ``meta-multimedia`` layer. +- ``libmusicbrainz``: Now resides in the ``meta-multimedia`` layer. -- *``metacity``:* Now resides in the ``meta-gnome`` layer. +- ``metacity``: Now resides in the ``meta-gnome`` layer. -- *``polkit``:* Now resides in the ``meta-oe`` layer. +- ``polkit``: Now resides in the ``meta-oe`` layer. -- *``zeroconf``:* Now resides in the ``meta-networking`` layer. +- ``zeroconf``: Now resides in the ``meta-networking`` layer. .. _migration-1.4-removals-and-renames: @@ -431,58 +434,58 @@ Removals and Renames The following list shows what has been removed or renamed: -- *``evieext``:* Removed because it has been removed from ``xserver`` +- ``evieext``: Removed because it has been removed from ``xserver`` since 2008. - *Gtk+ DirectFB:* Removed support because upstream Gtk+ no longer supports it as of version 2.18. -- *``libxfontcache / xfontcacheproto``:* Removed because they were +- ``libxfontcache / xfontcacheproto``: Removed because they were removed from the Xorg server in 2008. -- *``libxp / libxprintapputil / libxprintutil / printproto``:* Removed +- ``libxp / libxprintapputil / libxprintutil / printproto``: Removed because the XPrint server was removed from Xorg in 2008. -- *``libxtrap / xtrapproto``:* Removed because their functionality was +- ``libxtrap / xtrapproto``: Removed because their functionality was broken upstream. - *linux-yocto 3.0 kernel:* Removed with linux-yocto 3.8 kernel being added. The linux-yocto 3.2 and linux-yocto 3.4 kernels remain as part of the release. -- *``lsbsetup``:* Removed with functionality now provided by +- ``lsbsetup``: Removed with functionality now provided by ``lsbtest``. -- *``matchbox-stroke``:* Removed because it was never more than a +- ``matchbox-stroke``: Removed because it was never more than a proof-of-concept. -- *``matchbox-wm-2 / matchbox-theme-sato-2``:* Removed because they are +- ``matchbox-wm-2 / matchbox-theme-sato-2``: Removed because they are not maintained. However, ``matchbox-wm`` and ``matchbox-theme-sato`` are still provided. -- *``mesa-dri``:* Renamed to ``mesa``. +- ``mesa-dri``: Renamed to ``mesa``. -- *``mesa-xlib``:* Removed because it was no longer useful. +- ``mesa-xlib``: Removed because it was no longer useful. -- *``mutter``:* Removed because nothing ever uses it and the recipe is +- ``mutter``: Removed because nothing ever uses it and the recipe is very old. -- *``orinoco-conf``:* Removed because it has become obsolete. +- ``orinoco-conf``: Removed because it has become obsolete. -- *``update-modules``:* Removed because it is no longer used. The +- ``update-modules``: Removed because it is no longer used. The kernel module ``postinstall`` and ``postrm`` scripts can now do the same task without the use of this script. -- *``web``:* Removed because it is not maintained. Superseded by +- ``web``: Removed because it is not maintained. Superseded by ``web-webkit``. -- *``xf86bigfontproto``:* Removed because upstream it has been disabled +- ``xf86bigfontproto``: Removed because upstream it has been disabled by default since 2007. Nothing uses ``xf86bigfontproto``. -- *``xf86rushproto``:* Removed because its dependency in ``xserver`` +- ``xf86rushproto``: Removed because its dependency in ``xserver`` was spurious and it was removed in 2005. -- *``zypper / libzypp / sat-solver``:* Removed and been functionally +- ``zypper / libzypp / sat-solver``: Removed and been functionally replaced with Smart (``python-smartpm``) when RPM packaging is used and package management is enabled on the target. @@ -735,8 +738,7 @@ A new automated image testing framework has been added through the framework replaces the older ``imagetest-qemu`` framework. You can learn more about performing automated image tests in the -"`Performing Automated Runtime -Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" +":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" section in the Yocto Project Development Tasks Manual. .. _migration-1.5-build-history: @@ -758,9 +760,8 @@ Following are changes to Build History: utilities have improved command-line handling. Use the ``--help`` option for each utility for more information on the new syntax. -For more information on Build History, see the "`Maintaining Build -Output -Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__" +For more information on Build History, see the +":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`" section in the Yocto Project Development Tasks Manual. .. _migration-1.5-udev: @@ -836,7 +837,7 @@ Following is a list of short entries describing other changes: - ``image.bbclass``: Move ``runtime_mapping_rename`` to avoid conflict with ``multilib``. See - ```YOCTO #4993`https://bugzilla.yoctoproject.org/show_bug.cgi?id=4993 + `YOCTO #4993 `_ in Bugzilla for more information. - ``linux-dtb``: Use kernel build system to generate the ``dtb`` files. @@ -856,9 +857,8 @@ Project 1.6 Release from the prior release. The :ref:`archiver ` class has been rewritten and its configuration has been simplified. For more details on the -source archiver, see the "`Maintaining Open Source License Compliance -During Your Product's -Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__" +source archiver, see the +":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`" section in the Yocto Project Development Tasks Manual. .. _migration-1.6-packaging-changes: @@ -992,9 +992,8 @@ NFS mount, an error occurs. The ``PRINC`` variable has been deprecated and triggers a warning if detected during a build. For :term:`PR` increments on changes, use the PR service instead. You can find out more about this service in -the "`Working With a PR -Service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__" section in -the Yocto Project Development Tasks Manual. +the ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`" +section in the Yocto Project Development Tasks Manual. .. _migration-1.6-variable-changes-IMAGE_TYPES: @@ -1039,19 +1038,25 @@ Preprocess and Post Process Command Variable Behavior The following variables now expect a semicolon separated list of functions to call and not arbitrary shell commands: -:term:`ROOTFS_PREPROCESS_COMMAND` -:term:`ROOTFS_POSTPROCESS_COMMAND` -:term:`SDK_POSTPROCESS_COMMAND` -:term:`POPULATE_SDK_POST_TARGET_COMMAND` -:term:`POPULATE_SDK_POST_HOST_COMMAND` -:term:`IMAGE_POSTPROCESS_COMMAND` -:term:`IMAGE_PREPROCESS_COMMAND` -:term:`ROOTFS_POSTUNINSTALL_COMMAND` -:term:`ROOTFS_POSTINSTALL_COMMAND` For + + - :term:`ROOTFS_PREPROCESS_COMMAND` + - :term:`ROOTFS_POSTPROCESS_COMMAND` + - :term:`SDK_POSTPROCESS_COMMAND` + - :term:`POPULATE_SDK_POST_TARGET_COMMAND` + - :term:`POPULATE_SDK_POST_HOST_COMMAND` + - :term:`IMAGE_POSTPROCESS_COMMAND` + - :term:`IMAGE_PREPROCESS_COMMAND` + - :term:`ROOTFS_POSTUNINSTALL_COMMAND` + - :term:`ROOTFS_POSTINSTALL_COMMAND` + +For migration purposes, you can simply wrap shell commands in a shell -function and then call the function. Here is an example: -my_postprocess_function() { echo "hello" > ${IMAGE_ROOTFS}/hello.txt } -ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; " +function and then call the function. Here is an example: :: + + my_postprocess_function() { + echo "hello" > ${IMAGE_ROOTFS}/hello.txt + } + ROOTFS_POSTPROCESS_COMMAND += "my_postprocess_function; " .. _migration-1.6-package-test-ptest: @@ -1059,9 +1064,9 @@ Package Test (ptest) -------------------- Package Tests (ptest) are built but not installed by default. For -information on using Package Tests, see the "`Testing Packages with -ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in -the Yocto Project Development Tasks Manual. For information on the +information on using Package Tests, see the +":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`" +section in the Yocto Project Development Tasks Manual. For information on the ``ptest`` class, see the ":ref:`ptest.bbclass `" section. @@ -1087,8 +1092,11 @@ the ``autotools`` or ``autotools_stage``\ classes. ``qemu-native`` now builds without SDL-based graphical output support by default. The following additional lines are needed in your -``local.conf`` to enable it: PACKAGECONFIG_pn-qemu-native = "sdl" -ASSUME_PROVIDED += "libsdl-native" +``local.conf`` to enable it: +:: + + PACKAGECONFIG_pn-qemu-native = "sdl" + ASSUME_PROVIDED += "libsdl-native" .. note:: @@ -1270,15 +1278,18 @@ means that existing ``local.conf`` files will need to be be modified to append to ``PACKAGECONFIG`` for ``qemu-native`` and ``nativesdk-qemu`` instead of setting it. In other words, to enable graphical output for QEMU, you should now have these lines in ``local.conf``: -PACKAGECONFIG_append_pn-qemu-native = " sdl" -PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" +:: + + PACKAGECONFIG_append_pn-qemu-native = " sdl" + PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl" .. _migration-1.7-minimum-git-version: Minimum Git version ------------------- -The minimum `Git <&YOCTO_DOCS_OM_URL;#git>`__ version required on the +The minimum :ref:`overview-manual/overview-manual-development-environment:git` +version required on the build host is now 1.7.8 because the ``--list`` option is now required by BitBake's Git fetcher. As always, if your host distribution does not provide a version of Git that meets this requirement, you can use the @@ -1308,8 +1319,8 @@ occurred: the :ref:`autotools-brokensep ` class instead of the ``autotools`` or ``autotools_stage`` classes. -- *The ``--foreign`` option is no longer passed to ``automake`` when - running ``autoconf``:* This option tells ``automake`` that a +- The ``--foreign`` option is no longer passed to ``automake`` when + running ``autoconf``: This option tells ``automake`` that a particular software package does not follow the GNU standards and therefore should not be expected to distribute certain files such as ``ChangeLog``, ``AUTHORS``, and so forth. Because the majority of @@ -1331,15 +1342,31 @@ disable the scripts due to the scripts previously requiring error-prone path substitution. Software that links against these libraries using these scripts should use the much more robust ``pkg-config`` instead. The list of recipes changed in this version (and their configuration -scripts) is as follows: directfb (directfb-config) freetype -(freetype-config) gpgme (gpgme-config) libassuan (libassuan-config) -libcroco (croco-6.0-config) libgcrypt (libgcrypt-config) libgpg-error -(gpg-error-config) libksba (ksba-config) libpcap (pcap-config) libpcre -(pcre-config) libpng (libpng-config, libpng16-config) libsdl -(sdl-config) libusb-compat (libusb-config) libxml2 (xml2-config) libxslt -(xslt-config) ncurses (ncurses-config) neon (neon-config) npth -(npth-config) pth (pth-config) taglib (taglib-config) Additionally, -support for ``pkg-config`` has been added to some recipes in the +scripts) is as follows: +:: + + directfb (directfb-config) + freetype (freetype-config) + gpgme (gpgme-config) + libassuan (libassuan-config) + libcroco (croco-6.0-config) + libgcrypt (libgcrypt-config) + libgpg-error (gpg-error-config) + libksba (ksba-config) + libpcap (pcap-config) + libpcre (pcre-config) + libpng (libpng-config, libpng16-config) + libsdl (sdl-config) + libusb-compat (libusb-config) + libxml2 (xml2-config) + libxslt (xslt-config) + ncurses (ncurses-config) + neon (neon-config) + npth (npth-config) + pth (pth-config) + taglib (taglib-config) + +Additionally, support for ``pkg-config`` has been added to some recipes in the previous list in the rare cases where the upstream software package does not already provide it. @@ -1453,8 +1480,8 @@ The following miscellaneous change occurred: build header as printed by BitBake upon starting the build. You should manually remove old "build-id" files from your existing build history repositories to avoid confusion. For information on the build - history feature, see the "`Maintaining Build Output - Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__" + history feature, see the + ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`" section in the Yocto Project Development Tasks Manual. Moving to the Yocto Project 1.8 Release @@ -1515,11 +1542,12 @@ you can now remove them. Additionally, a ``bluetooth`` class has been added to make selection of the appropriate bluetooth support within a recipe a little easier. If you wish to make use of this class in a recipe, add something such as -the following: inherit bluetooth PACKAGECONFIG ??= -"${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', -d)}" PACKAGECONFIG[bluez4] = -"--enable-bluetooth,--disable-bluetooth,bluez4" PACKAGECONFIG[bluez5] = -"--enable-bluez5,--disable-bluez5,bluez5" +the following: :: + + inherit bluetooth + PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', '${BLUEZ}', '', d)}" + PACKAGECONFIG[bluez4] = "--enable-bluetooth,--disable-bluetooth,bluez4" + PACKAGECONFIG[bluez5] = "--enable-bluez5,--disable-bluez5,bluez5" .. _migration-1.8-kernel-build-changes: @@ -1542,8 +1570,9 @@ where the ``linux.inc`` file in ``meta-oe`` was updated. Recipes that rely on the kernel source code and do not inherit the module classes might need to add explicit dependencies on the -``do_shared_workdir`` kernel task, for example: do_configure[depends] += -"virtual/kernel:do_shared_workdir" +``do_shared_workdir`` kernel task, for example: :: + + do_configure[depends] += "virtual/kernel:do_shared_workdir" .. _migration-1.8-ssl: @@ -1588,8 +1617,9 @@ One of the improvements is to attempt to run "make clean" during the ``do_configure`` task if a ``Makefile`` exists. Some software packages do not provide a working clean target within their make files. If you have such recipes, you need to set -:term:`CLEANBROKEN` to "1" within the recipe, for -example: CLEANBROKEN = "1" +:term:`CLEANBROKEN` to "1" within the recipe, for example: :: + + CLEANBROKEN = "1" .. _migration-1.8-qa-check-and-validation-changes: @@ -1663,7 +1693,10 @@ and the porting guide at https://gcc.gnu.org/gcc-5/porting_to.html. Alternatively, you can switch back to GCC 4.9 or 4.8 by setting -``GCCVERSION`` in your configuration, as follows: GCCVERSION = "4.9%" +``GCCVERSION`` in your configuration, as follows: +:: + + GCCVERSION = "4.9%" .. _migration-2.0-Gstreamer-0.10-removed: @@ -1726,7 +1759,10 @@ unlikely to require any changes to Metadata. However, these minor changes in behavior exist: - All potential overrides are now visible in the variable history as - seen when you run the following: $ bitbake -e + seen when you run the following: + :: + + $ bitbake -e - ``d.delVar('``\ VARNAME\ ``')`` and ``d.setVar('``\ VARNAME\ ``', None)`` result in the variable and all @@ -1833,7 +1869,9 @@ changes. Additionally, work directories for old versions of recipes are now pruned. If you wish to disable pruning old work directories, you can set the following variable in your configuration: -SSTATE_PRUNE_OBSOLETEWORKDIR = "0" +:: + + SSTATE_PRUNE_OBSOLETEWORKDIR = "0" .. _migration-2.0-linux-yocto-kernel-metadata-repository-now-split-from-source: @@ -1952,9 +1990,11 @@ defaulted to False if not specified. Now, however, no default exists so one must be specified. You must change any ``getVar()`` calls that do not specify the final expand parameter to calls that do specify the parameter. You can run the following ``sed`` command at the base of a -layer to make this change: sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' --i \`grep -ril getVar \*\` sed -e 's:\(\.getVarFlag([^,()]*, -[^,()]*\)):\1, False):g' -i \`grep -ril getVarFlag \*\` +layer to make this change: +:: + + sed -e 's:\(\.getVar([^,()]*\)):\1, False):g' -i `grep -ril getVar *` + sed -e 's:\(\.getVarFlag([^,()]*,[^,()]*\)):\1, False):g' -i `grep -ril getVarFlag *` .. note:: @@ -2124,8 +2164,8 @@ The following changes have been made to the build system user interface: - *Hob GTK+-based UI*: Removed because it is unmaintained and based on the outdated GTK+ 2 library. The Toaster web-based UI is much more - capable and is actively maintained. See the "`Using the Toaster Web - Interface <&YOCTO_DOCS_TOAST_URL;#using-the-toaster-web-interface>`__" + capable and is actively maintained. See the + ":ref:`toaster-manual/toaster-manual-setup-and-use:using the toaster web interface`" section in the Toaster User Manual for more information on this interface. @@ -2138,12 +2178,11 @@ ADT Removed ----------- The Application Development Toolkit (ADT) has been removed because its -functionality almost completely overlapped with the `standard -SDK <&YOCTO_DOCS_SDK_URL;#sdk-using-the-standard-sdk>`__ and the -`extensible SDK <&YOCTO_DOCS_SDK_URL;#sdk-extensible>`__. For -information on these SDKs and how to build and use them, see the `Yocto -Project Application Development and the Extensible Software Development -Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual. +functionality almost completely overlapped with the :ref:`standard +SDK ` and the +:ref:`extensible SDK `. For +information on these SDKs and how to build and use them, see the +:doc:`../sdk-manual/sdk-manual` manual. .. note:: @@ -2253,8 +2292,7 @@ This release supports generation of GLib Introspective Repository (GIR) files through GObject introspection, which is the standard mechanism for accessing GObject-based software from runtime environments. You can enable, disable, and test the generation of this data. See the -"`Enabling GObject Introspection -Support <&YOCTO_DOCS_DEV_URL;#enabling-gobject-introspection-support>`__" +":ref:`dev-manual/dev-manual-common-tasks:enabling gobject introspection support`" section in the Yocto Project Development Tasks Manual for more information. @@ -2279,7 +2317,14 @@ These additional changes exist: - Previously, the following list of packages were removed if package-management was not in :term:`IMAGE_FEATURES`, regardless of any - dependencies: update-rc.d base-passwd shadow update-alternatives + dependencies: + :: + + update-rc.d + base-passwd + shadow + update-alternatives + run-postinsts With the Yocto Project 2.1 release, these packages are only removed if "read-only-rootfs" is in ``IMAGE_FEATURES``, since they might still be needed for a read-write image even in the absence @@ -2287,7 +2332,7 @@ These additional changes exist: removed at runtime). - The - ```devtool modify`` <&YOCTO_DOCS_SDK_URL;#sdk-devtool-use-devtool-modify-to-modify-the-source-of-an-existing-component>`__ + :ref:`devtool modify ` command now defaults to extracting the source since that is most commonly expected. The "-x" or "--extract" options are now no-ops. If you wish to provide your own existing source tree, you will now need @@ -2409,10 +2454,15 @@ The metadata is now required to use Python 3 syntax. For help preparing metadata, see any of the many Python 3 porting guides available. Alternatively, you can reference the conversion commits for Bitbake and you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. Following are -particular areas of interest: \* subprocess command-line pipes needing -locale decoding \* the syntax for octal values changed \* the -``iter*()`` functions changed name \* iterators now return views, not -lists \* changed names for Python modules +particular areas of interest: + + - subprocess command-line pipes needing locale decoding + + - the syntax for octal values changed + + - the ``iter*()`` functions changed name \* iterators now return views, not lists + + - changed names for Python modules .. _migration-2.2-target-python-recipes-switched-to-python-3: @@ -2474,7 +2524,12 @@ The new ``runqemu`` is a Python script. Machine knowledge is no longer hardcoded into ``runqemu``. You can choose to use the ``qemuboot`` configuration file to define the BSP's own arguments and to make it bootable with ``runqemu``. If you use a configuration file, use the -following form: image-name-machine.qemuboot.conf The configuration file +following form: +:: + + image-name-machine.qemuboot.conf + +The configuration file enables fine-grained tuning of options passed to QEMU without the ``runqemu`` script hard-coding any knowledge about different machines. Using a configuration file is particularly convenient when trying to use @@ -2485,14 +2540,28 @@ rootfs). QEMU boot arguments can be set in BSP's configuration file and the ``qemuboot`` class will save them to ``qemuboot.conf``. If you want to use ``runqemu`` without a configuration file, use the -following command form: $ runqemu machine rootfs kernel [options] -Supported machines are as follows: qemuarm qemuarm64 qemux86 qemux86-64 -qemuppc qemumips qemumips64 qemumipsel qemumips64el Consider the +following command form: +:: + + $ runqemu machine rootfs kernel [options] + +Supported machines are as follows: + + - qemuarm + - qemuarm64 + - qemux86 + - qemux86-64 + - qemuppc + - qemumips + - qemumips64 + - qemumipsel + - qemumips64el + +Consider the following example, which uses the ``qemux86-64`` machine, provides a -root filesystem, provides an image, and uses the ``nographic`` option: $ -runqemu qemux86-64 -tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 -tmp/deploy/images/qemux86-64/bzImage nographic +root filesystem, provides an image, and uses the ``nographic`` option: :: + + $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic Following is a list of variables that can be set in configuration files such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``: @@ -2501,31 +2570,35 @@ such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``: "QB" means "QEMU Boot". -QB_SYSTEM_NAME: QEMU name (e.g. "qemu-system-i386") QB_OPT_APPEND: -Options to append to QEMU (e.g. "-show-cursor") QB_DEFAULT_KERNEL: -Default kernel to boot (e.g. "bzImage") QB_DEFAULT_FSTYPE: Default -FSTYPE to boot (e.g. "ext4") QB_MEM: Memory (e.g. "-m 512") QB_MACHINE: -QEMU machine (e.g. "-machine virt") QB_CPU: QEMU cpu (e.g. "-cpu -qemu32") QB_CPU_KVM: Similar to QB_CPU except used for kvm support (e.g. -"-cpu kvm64") QB_KERNEL_CMDLINE_APPEND: Options to append to the -kernel's -append option (e.g. "console=ttyS0 console=tty") QB_DTB: QEMU -dtb name QB_AUDIO_DRV: QEMU audio driver (e.g. "alsa", set it when -support audio) QB_AUDIO_OPT: QEMU audio option (e.g. "-soundhw -ac97,es1370"), which is used when QB_AUDIO_DRV is set. QB_KERNEL_ROOT: -Kernel's root (e.g. /dev/vda) QB_TAP_OPT: Network option for 'tap' mode -(e.g. "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no -device -virtio-net-device,netdev=net0"). runqemu will replace "@TAP@" with the -one that is used, such as tap0, tap1 ... QB_SLIRP_OPT: Network option -for SLIRP mode (e.g. "-netdev user,id=net0 -device -virtio-net-device,netdev=net0") QB_ROOTFS_OPT: Used as rootfs (e.g. -"-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device -virtio-blk-device,drive=disk0"). runqemu will replace "@ROOTFS@" with -the one which is used, such as core-image-minimal-qemuarm64.ext4. -QB_SERIAL_OPT: Serial port (e.g. "-serial mon:stdio") QB_TCPSERIAL_OPT: -tcp serial port option (e.g. " -device virtio-serial-device -chardev -socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device -virtconsole,chardev=virtcon" runqemu will replace "@PORT@" with the port -number which is used. +:: + + QB_SYSTEM_NAME: QEMU name (e.g. "qemu-system-i386") + QB_OPT_APPEND: Options to append to QEMU (e.g. "-show-cursor") + QB_DEFAULT_KERNEL: Default kernel to boot (e.g. "bzImage") + QB_DEFAULT_FSTYPE: Default FSTYPE to boot (e.g. "ext4") + QB_MEM: Memory (e.g. "-m 512") + QB_MACHINE: QEMU machine (e.g. "-machine virt") + QB_CPU: QEMU cpu (e.g. "-cpu qemu32") + QB_CPU_KVM: Similar to QB_CPU except used for kvm support (e.g. "-cpu kvm64") + QB_KERNEL_CMDLINE_APPEND: Options to append to the kernel's -append + option (e.g. "console=ttyS0 console=tty") + QB_DTB: QEMU dtb name + QB_AUDIO_DRV: QEMU audio driver (e.g. "alsa", set it when support audio) + QB_AUDIO_OPT: QEMU audio option (e.g. "-soundhw ac97,es1370"), which is used + when QB_AUDIO_DRV is set. + QB_KERNEL_ROOT: Kernel's root (e.g. /dev/vda) + QB_TAP_OPT: Network option for 'tap' mode (e.g. + "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no -device virtio-net-device,netdev=net0"). + runqemu will replace "@TAP@" with the one that is used, such as tap0, tap1 ... + QB_SLIRP_OPT: Network option for SLIRP mode (e.g. "-netdev user,id=net0 -device virtio-net-device,netdev=net0") + QB_ROOTFS_OPT: Used as rootfs (e.g. + "-drive id=disk0,file=@ROOTFS@,if=none,format=raw -device virtio-blk-device,drive=disk0"). + runqemu will replace "@ROOTFS@" with the one which is used, such as + core-image-minimal-qemuarm64.ext4. + QB_SERIAL_OPT: Serial port (e.g. "-serial mon:stdio") + QB_TCPSERIAL_OPT: tcp serial port option (e.g. + " -device virtio-serial-device -chardev socket,id=virtcon,port=@PORT@,host=127.0.0.1 -device virtconsole,chardev=virtcon" + runqemu will replace "@PORT@" with the port number which is used. To use ``runqemu``, set :term:`IMAGE_CLASSES` as follows and run ``runqemu``: @@ -2536,7 +2609,9 @@ follows and run ``runqemu``: runqemu help . -IMAGE_CLASSES += "qemuboot" +:: + + IMAGE_CLASSES += "qemuboot" .. _migration-2.2-default-linker-hash-style-changed: @@ -2551,7 +2626,10 @@ recipes. You need to fix these recipes so that they use the expected ``LDFLAGS``. Depending on how the software is built, the build system used by the software (e.g. a Makefile) might need to be patched. However, sometimes making this fix is as simple as adding the following -to the recipe: TARGET_CC_ARCH += "${LDFLAGS}" +to the recipe: +:: + + TARGET_CC_ARCH += "${LDFLAGS}" .. _migration-2.2-kernel-image-base-name-no-longer-uses-kernel-imagetype: @@ -2562,8 +2640,12 @@ The ``KERNEL_IMAGE_BASE_NAME`` variable no longer uses the :term:`KERNEL_IMAGETYPE` variable to create the image's base name. Because the OpenEmbedded build system can now build multiple kernel image types, this part of the kernel image base name as -been removed leaving only the following: KERNEL_IMAGE_BASE_NAME ?= -"${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" If you have recipes or +been removed leaving only the following: +:: + + KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}" + +If you have recipes or classes that use ``KERNEL_IMAGE_BASE_NAME`` directly, you might need to update the references to ensure they continue to work. @@ -2787,7 +2869,7 @@ Consider the following: ``systemd-systemctl-native`` is added to ``PACKAGE_WRITE_DEPS``, which is also conditional on "systemd" being in ``DISTRO_FEATURES``. -- *Examine Recipes that Use ``SSTATEPOSTINSTFUNCS``:* You need to +- Examine Recipes that Use ``SSTATEPOSTINSTFUNCS``: You need to examine any recipe that uses ``SSTATEPOSTINSTFUNCS`` and determine steps to take. @@ -2800,8 +2882,7 @@ Consider the following: :term:`SYSROOT_PREPROCESS_FUNCS`. For an example, see the ``pixbufcache`` class in ``meta/classes/`` in - the Yocto Project `Source - Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__. + the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`. .. note:: @@ -2866,26 +2947,35 @@ Changes to Scripts The following changes to scripts took place: -- *``oe-find-native-sysroot``:* The usage for the - ``oe-find-native-sysroot`` script has changed to the following: $ . - oe-find-native-sysroot recipe You must now supply a recipe for recipe - as part of the command. Prior to the Yocto Project DISTRO release, it +- ``oe-find-native-sysroot``: The usage for the + ``oe-find-native-sysroot`` script has changed to the following: + :: + + $ . oe-find-native-sysroot recipe + + You must now supply a recipe for recipe + as part of the command. Prior to the Yocto Project &DISTRO; release, it was not necessary to provide the script with the command. -- *``oe-run-native``:* The usage for the ``oe-run-native`` script has - changed to the following: $ oe-run-native native_recipe tool You must +- ``oe-run-native``: The usage for the ``oe-run-native`` script has + changed to the following: + :: + + $ oe-run-native native_recipe tool + + You must supply the name of the native recipe and the tool you want to run as part of the command. Prior to the Yocto Project DISTRO release, it was not necessary to provide the native recipe with the command. -- *``cleanup-workdir``:* The ``cleanup-workdir`` script has been +- ``cleanup-workdir``: The ``cleanup-workdir`` script has been removed because the script was found to be deleting files it should not have, which lead to broken build trees. Rather than trying to delete portions of :term:`TMPDIR` and getting it wrong, it is recommended that you delete ``TMPDIR`` and have it restored from shared state (sstate) on subsequent builds. -- *``wipe-sysroot``:* The ``wipe-sysroot`` script has been removed as +- ``wipe-sysroot``: The ``wipe-sysroot`` script has been removed as it is no longer needed with recipe-specific sysroots. .. _migration-2.3-functions: @@ -2946,8 +3036,8 @@ The following changes took place for BitBake: section in the BitBake User Manual for additional information. -- *``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2`` - Removed:* Because the mechanism they were part of is no longer +- ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2`` + Removed: Because the mechanism they were part of is no longer necessary with recipe-specific sysroots, the ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2`` variables have been removed. @@ -3080,29 +3170,29 @@ Removed Recipes The following recipes have been removed: -- *``linux-yocto 4.8:``* Version 4.8 has been removed. Versions 4.1 +- ``linux-yocto 4.8``: Version 4.8 has been removed. Versions 4.1 (LTSI), 4.4 (LTS), 4.9 (LTS/LTSI) and 4.10 are now present. -- *``python-smartpm:``* Functionally replaced by ``dnf``. +- ``python-smartpm``: Functionally replaced by ``dnf``. -- *``createrepo:``* Replaced by the ``createrepo-c`` recipe. +- ``createrepo``: Replaced by the ``createrepo-c`` recipe. -- *``rpmresolve:``* No longer needed with the move to RPM 4 as RPM +- ``rpmresolve``: No longer needed with the move to RPM 4 as RPM itself is used instead. -- *``gstreamer:``* Removed the GStreamer Git version recipes as they +- ``gstreamer``: Removed the GStreamer Git version recipes as they have been stale. ``1.10.``\ x recipes are still present. -- *``alsa-conf-base:``* Merged into ``alsa-conf`` since ``libasound`` +- ``alsa-conf-base``: Merged into ``alsa-conf`` since ``libasound`` depended on both. Essentially, no way existed to install only one of these. -- *``tremor:``* Moved to ``meta-multimedia``. Fixed-integer Vorbis +- ``tremor``: Moved to ``meta-multimedia``. Fixed-integer Vorbis decoding is not needed by current hardware. Thus, GStreamer's ivorbis plugin has been disabled by default eliminating the need for the ``tremor`` recipe in :term:`OpenEmbedded-Core (OE-Core)`. -- *``gummiboot:``* Replaced by ``systemd-boot``. +- ``gummiboot``: Replaced by ``systemd-boot``. .. _migration-2.3-wic-changes: @@ -3135,7 +3225,7 @@ QA Changes The following QA checks have changed: -- *``unsafe-references-in-binaries``:* The +- ``unsafe-references-in-binaries``: The ``unsafe-references-in-binaries`` QA check, which was disabled by default, has now been removed. This check was intended to detect binaries in ``/bin`` that link to libraries in ``/usr/lib`` and have @@ -3146,7 +3236,7 @@ The following QA checks have changed: separate partition from ``/`` is now a rare configuration. Consequently, ``unsafe-references-in-binaries`` was removed. -- *``file-rdeps``:* The ``file-rdeps`` QA check is now an error by +- ``file-rdeps``: The ``file-rdeps`` QA check is now an error by default instead of a warning. Because it is an error instead of a warning, you need to address missing runtime dependencies. @@ -3202,8 +3292,15 @@ The following miscellaneous changes have occurred: - The ``USE_LDCONFIG`` variable has been replaced with the "ldconfig" ``DISTRO_FEATURES`` feature. Distributions that previously set: - USE_LDCONFIG = "0" should now instead use the following: - DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig" + :: + + USE_LDCONFIG = "0" + + should now instead use the following: + + :: + + DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig" - The default value of :term:`COPYLEFT_LICENSE_INCLUDE` now @@ -3219,7 +3316,10 @@ The following miscellaneous changes have occurred: order to allow module packages from multiple kernel versions to co-exist on a target system. If you wish to return to the previous naming scheme that does not include the version suffix, use the - following: KERNEL_MODULE_PACKAGE_SUFFIX to "" + following: + :: + + KERNEL_MODULE_PACKAGE_SUFFIX to "" - Removal of ``libtool`` ``*.la`` files is now enabled by default. The ``*.la`` files are not actually needed on Linux and relocating them @@ -3285,7 +3385,7 @@ Packaging Changes This section provides information about packaging changes that have occurred: -- *``python3`` Changes:* +- ``python3`` Changes: - The main "python3" package now brings in all of the standard Python 3 distribution rather than a subset. This behavior matches @@ -3293,16 +3393,16 @@ occurred: wish to install a subset of Python 3, specify ``python-core`` plus one or more of the individual packages that are still produced. - - *``python3``:* The ``bz2.py``, ``lzma.py``, and + - ``python3``: The ``bz2.py``, ``lzma.py``, and ``_compression.py`` scripts have been moved from the ``python3-misc`` package to the ``python3-compression`` package. -- *``binutils``:* The ``libbfd`` library is now packaged in a separate +- ``binutils``: The ``libbfd`` library is now packaged in a separate "libbfd" package. This packaging saves space when certain tools (e.g. ``perf``) are installed. In such cases, the tools only need ``libbfd`` rather than all the packages in ``binutils``. -- *``util-linux`` Changes:* +- ``util-linux`` Changes: - The ``su`` program is now packaged in a separate "util-linux-su" package, which is only built when "pam" is listed in the @@ -3326,7 +3426,7 @@ occurred: recommended runtime dependency (i.e. ``RRECOMMENDS``) on the ``util-linux-ionice`` package. -- *``initscripts``:* The ``sushell`` program is now packaged in a +- ``initscripts``: The ``sushell`` program is now packaged in a separate "initscripts-sushell" package. This packaging change allows systems to pull ``sushell`` in when ``selinux`` is enabled. The change also eliminates needing to pull in the entire ``initscripts`` @@ -3334,7 +3434,7 @@ occurred: (i.e. ``RDEPENDS``) on the ``sushell`` package when "selinux" is in ``DISTRO_FEATURES``. -- *``glib-2.0``:* The ``glib-2.0`` package now has a recommended +- ``glib-2.0``: The ``glib-2.0`` package now has a recommended runtime dependency (i.e. ``RRECOMMENDS``) on the ``shared-mime-info`` package, since large portions of GIO are not useful without the MIME database. You can remove the dependency by using the @@ -3351,102 +3451,102 @@ Removed Recipes The following recipes have been removed: -- *``acpitests``:* This recipe is not maintained. +- ``acpitests``: This recipe is not maintained. -- *``autogen-native``:* No longer required by Grub, oe-core, or +- ``autogen-native``: No longer required by Grub, oe-core, or meta-oe. -- *``bdwgc``:* Nothing in OpenEmbedded-Core requires this recipe. It +- ``bdwgc``: Nothing in OpenEmbedded-Core requires this recipe. It has moved to meta-oe. -- *``byacc``:* This recipe was only needed by rpm 5.x and has moved to +- ``byacc``: This recipe was only needed by rpm 5.x and has moved to meta-oe. -- *``gcc (5.4)``:* The 5.4 series dropped the recipe in favor of 6.3 / +- ``gcc (5.4)``: The 5.4 series dropped the recipe in favor of 6.3 / 7.2. -- *``gnome-common``:* Deprecated upstream and no longer needed. +- ``gnome-common``: Deprecated upstream and no longer needed. -- *``go-bootstrap-native``:* Go 1.9 does its own bootstrapping so this +- ``go-bootstrap-native``: Go 1.9 does its own bootstrapping so this recipe has been removed. -- *``guile``:* This recipe was only needed by ``autogen-native`` and +- ``guile``: This recipe was only needed by ``autogen-native`` and ``remake``. The recipe is no longer needed by either of these programs. -- *``libclass-isa-perl``:* This recipe was previously needed for LSB 4, +- ``libclass-isa-perl``: This recipe was previously needed for LSB 4, no longer needed. -- *``libdumpvalue-perl``:* This recipe was previously needed for LSB 4, +- ``libdumpvalue-perl``: This recipe was previously needed for LSB 4, no longer needed. -- *``libenv-perl``:* This recipe was previously needed for LSB 4, no +- ``libenv-perl``: This recipe was previously needed for LSB 4, no longer needed. -- *``libfile-checktree-perl``:* This recipe was previously needed for +- ``libfile-checktree-perl``: This recipe was previously needed for LSB 4, no longer needed. -- *``libi18n-collate-perl``:* This recipe was previously needed for LSB +- ``libi18n-collate-perl``: This recipe was previously needed for LSB 4, no longer needed. -- *``libiconv``:* This recipe was only needed for ``uclibc``, which was +- ``libiconv``: This recipe was only needed for ``uclibc``, which was removed in the previous release. ``glibc`` and ``musl`` have their own implementations. ``meta-mingw`` still needs ``libiconv``, so it has been moved to ``meta-mingw``. -- *``libpng12``:* This recipe was previously needed for LSB. The +- ``libpng12``: This recipe was previously needed for LSB. The current ``libpng`` is 1.6.x. -- *``libpod-plainer-perl``:* This recipe was previously needed for LSB +- ``libpod-plainer-perl``: This recipe was previously needed for LSB 4, no longer needed. -- *``linux-yocto (4.1)``:* This recipe was removed in favor of 4.4, +- ``linux-yocto (4.1)``: This recipe was removed in favor of 4.4, 4.9, 4.10 and 4.12. -- *``mailx``:* This recipe was previously only needed for LSB +- ``mailx``: This recipe was previously only needed for LSB compatibility, and upstream is defunct. -- *``mesa (git version only)``:* The git version recipe was stale with +- ``mesa (git version only)``: The git version recipe was stale with respect to the release version. -- *``ofono (git version only)``:* The git version recipe was stale with +- ``ofono (git version only)``: The git version recipe was stale with respect to the release version. -- *``portmap``:* This recipe is obsolete and is superseded by +- ``portmap``: This recipe is obsolete and is superseded by ``rpcbind``. -- *``python3-pygpgme``:* This recipe is old and unmaintained. It was +- ``python3-pygpgme``: This recipe is old and unmaintained. It was previously required by ``dnf``, which has switched to official ``gpgme`` Python bindings. -- *``python-async``:* This recipe has been removed in favor of the +- ``python-async``: This recipe has been removed in favor of the Python 3 version. -- *``python-gitdb``:* This recipe has been removed in favor of the +- ``python-gitdb``: This recipe has been removed in favor of the Python 3 version. -- *``python-git``:* This recipe was removed in favor of the Python 3 +- ``python-git``: This recipe was removed in favor of the Python 3 version. -- *``python-mako``:* This recipe was removed in favor of the Python 3 +- ``python-mako``: This recipe was removed in favor of the Python 3 version. -- *``python-pexpect``:* This recipe was removed in favor of the Python +- ``python-pexpect``: This recipe was removed in favor of the Python 3 version. -- *``python-ptyprocess``:* This recipe was removed in favor of Python +- ``python-ptyprocess``: This recipe was removed in favor of Python the 3 version. -- *``python-pycurl``:* Nothing is using this recipe in +- ``python-pycurl``: Nothing is using this recipe in OpenEmbedded-Core (i.e. ``meta-oe``). -- *``python-six``:* This recipe was removed in favor of the Python 3 +- ``python-six``: This recipe was removed in favor of the Python 3 version. -- *``python-smmap``:* This recipe was removed in favor of the Python 3 +- ``python-smmap``: This recipe was removed in favor of the Python 3 version. -- *``remake``:* Using ``remake`` as the provider of ``virtual/make`` is +- ``remake``: Using ``remake`` as the provider of ``virtual/make`` is broken. Consequently, this recipe is not needed in OpenEmbedded-Core. .. _migration-2.4-kernel-device-tree-move: @@ -3598,17 +3698,17 @@ Packaging Changes This section provides information about packaging changes that have occurred: -- *``bind-libs``:* The libraries packaged by the bind recipe are in a +- ``bind-libs``: The libraries packaged by the bind recipe are in a separate ``bind-libs`` package. -- *``libfm-gtk``:* The ``libfm`` GTK+ bindings are split into a +- ``libfm-gtk``: The ``libfm`` GTK+ bindings are split into a separate ``libfm-gtk`` package. -- *``flex-libfl``:* The flex recipe splits out libfl into a separate +- ``flex-libfl``: The flex recipe splits out libfl into a separate ``flex-libfl`` package to avoid too many dependencies being pulled in where only the library is needed. -- *``grub-efi``:* The ``grub-efi`` configuration is split into a +- ``grub-efi``: The ``grub-efi`` configuration is split into a separate ``grub-bootconf`` recipe. However, the dependency relationship from ``grub-efi`` is through a virtual/grub-bootconf provider making it possible to have your own recipe provide the @@ -3628,42 +3728,42 @@ Removed Recipes The following recipes have been removed: -- *``gcc``:* The version 6.4 recipes are replaced by 7.x. +- ``gcc``: The version 6.4 recipes are replaced by 7.x. -- *``gst-player``:* Renamed to ``gst-examples`` as per upstream. +- ``gst-player``: Renamed to ``gst-examples`` as per upstream. -- *``hostap-utils``:* This software package is obsolete. +- ``hostap-utils``: This software package is obsolete. -- *``latencytop``:* This recipe is no longer maintained upstream. The +- ``latencytop``: This recipe is no longer maintained upstream. The last release was in 2009. -- *``libpfm4``:* The only file that requires this recipe is +- ``libpfm4``: The only file that requires this recipe is ``oprofile``, which has been removed. -- *``linux-yocto``:* The version 4.4, 4.9, and 4.10 recipes have been +- ``linux-yocto``: The version 4.4, 4.9, and 4.10 recipes have been removed. Versions 4.12, 4.14, and 4.15 remain. -- *``man``:* This recipe has been replaced by modern ``man-db`` +- ``man``: This recipe has been replaced by modern ``man-db`` -- *``mkelfimage``:* This tool has been removed in the upstream coreboot +- ``mkelfimage``: This tool has been removed in the upstream coreboot project, and is no longer needed with the removal of the ELF image type. -- *``nativesdk-postinst-intercept``:* This recipe is not maintained. +- ``nativesdk-postinst-intercept``: This recipe is not maintained. -- *``neon``:* This software package is no longer maintained upstream +- ``neon``: This software package is no longer maintained upstream and is no longer needed by anything in OpenEmbedded-Core. -- *``oprofile``:* The functionality of this recipe is replaced by +- ``oprofile``: The functionality of this recipe is replaced by ``perf`` and keeping compatibility on an ongoing basis with ``musl`` is difficult. -- *``pax``:* This software package is obsolete. +- ``pax``: This software package is obsolete. -- *``stat``:* This software package is not maintained upstream. +- ``stat``: This software package is not maintained upstream. ``coreutils`` provides a modern stat binary. -- *``zisofs-tools-native``:* This recipe is no longer needed because +- ``zisofs-tools-native``: This recipe is no longer needed because the compressed ISO image feature has been removed. .. _migration-2.5-scripts-and-tools-changes: @@ -3673,17 +3773,16 @@ Scripts and Tools Changes The following are changes to scripts and tools: -- *``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer``*: The +- ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer``: The ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer`` scripts previously shipped with poky but not in OpenEmbedded-Core have been removed. These scripts are not maintained and are outdated. In many cases, they are also limited in scope. The ``bitbake-layers create-layer`` command is a direct replacement for ``yocto-layer``. See the documentation to create a BSP or kernel - recipe in the "`BSP Kernel Recipe - Example <&YOCTO_DOCS_BSP_URL;#bsp-kernel-recipe-example>`__" section. + recipe in the ":ref:`bsp-guide/bsp:bsp kernel recipe example`" section. -- *``devtool finish``:* ``devtool finish`` now exits with an error if +- ``devtool finish``: ``devtool finish`` now exits with an error if there are uncommitted changes or a rebase/am in progress in the recipe's source repository. If this error occurs, there might be uncommitted changes that will not be included in updates to the @@ -3691,11 +3790,11 @@ The following are changes to scripts and tools: situations that the uncommitted changes are inconsequential and you want to proceed regardless. -- *``scripts/oe-setup-rpmrepo`` script:* The functionality of +- ``scripts/oe-setup-rpmrepo`` script: The functionality of ``scripts/oe-setup-rpmrepo`` is replaced by ``bitbake package-index``. -- *``scripts/test-dependencies.sh`` script:* The script is largely made +- ``scripts/test-dependencies.sh`` script: The script is largely made obsolete by the recipe-specific sysroots functionality introduced in the previous release. @@ -3725,8 +3824,15 @@ The following are BitBake changes: tree" tasks have been removed (e.g. ``fetchall``, ``checkuriall``, and the ``*all`` tasks provided by the ``distrodata`` and ``archiver`` classes). There is a BitBake option to complete this for - any arbitrary task. For example: bitbake -c fetchall should - now be replaced with: bitbake --runall=fetch + any arbitrary task. For example: + :: + + bitbake -c fetchall + + should now be replaced with: + :: + + bitbake --runall=fetch .. _migration-2.5-python-and-python3-changes: @@ -3749,8 +3855,15 @@ one of the packages provided by the Python recipe. You can no longer run ``bitbake python-foo`` or have a :term:`DEPENDS` on ``python-foo``, but doing either of the following causes the package to work as -expected: IMAGE_INSTALL_append = " python-foo" or RDEPENDS_${PN} = -"python-foo" The earlier build-time provides behavior was a quirk of the +expected: :: + + IMAGE_INSTALL_append = " python-foo" + +or :: + + RDEPENDS_${PN} = "python-foo" + +The earlier build-time provides behavior was a quirk of the way the Python manifest file was created. For more information on this change please see `this commit `__. @@ -3798,17 +3911,36 @@ The following are additional changes: ``bitbake/lib/bb``. These are typically used from recipes and classes. Any references to the old functions must be updated. The following table shows the removed functions and their replacements: - *Removed* *Replacement* ============================ - ============================ base_path_join() oe.path.join() - base_path_relative() oe.path.relative() base_path_out() - oe.path.format_display() base_read_file() oe.utils.read_file() - base_ifelse() oe.utils.ifelse() base_conditional() - oe.utils.conditional() base_less_or_equal() oe.utils.less_or_equal() - base_version_less_or_equal() oe.utils.version_less_or_equal() - base_contains() bb.utils.contains() base_both_contain() - oe.utils.both_contain() base_prune_suffix() oe.utils.prune_suffix() - oe_filter() oe.utils.str_filter() oe_filter_out() - oe.utils.str_filter_out() (or use the \_remove operator). + + +------------------------------+----------------------------------------------------------+ + | *Removed* | *Replacement* | + +==============================+==========================================================+ + | base_path_join() | oe.path.join() | + +------------------------------+----------------------------------------------------------+ + | base_path_relative() | oe.path.relative() | + +------------------------------+----------------------------------------------------------+ + | base_path_out() | oe.path.format_display() | + +------------------------------+----------------------------------------------------------+ + | base_read_file() | oe.utils.read_file() | + +------------------------------+----------------------------------------------------------+ + | base_ifelse() | oe.utils.ifelse() | + +------------------------------+----------------------------------------------------------+ + | base_conditional() | oe.utils.conditional() | + +------------------------------+----------------------------------------------------------+ + | base_less_or_equal() | oe.utils.less_or_equal() | + +------------------------------+----------------------------------------------------------+ + | base_version_less_or_equal() | oe.utils.version_less_or_equal() | + +------------------------------+----------------------------------------------------------+ + | base_contains() | bb.utils.contains() | + +------------------------------+----------------------------------------------------------+ + | base_both_contain() | oe.utils.both_contain() | + +------------------------------+----------------------------------------------------------+ + | base_prune_suffix() | oe.utils.prune_suffix() | + +------------------------------+----------------------------------------------------------+ + | oe_filter() | oe.utils.str_filter() | + +------------------------------+----------------------------------------------------------+ + | oe_filter_out() | oe.utils.str_filter_out() (or use the \_remove operator) | + +------------------------------+----------------------------------------------------------+ - Using ``exit 1`` to explicitly defer a postinstall script until first boot is now deprecated since it is not an obvious mechanism and can @@ -3819,8 +3951,8 @@ The following are additional changes: Any failure of a ``pkg_postinst()`` script (including ``exit 1``) will trigger a warning during ``do_rootfs``. - For more information, see the "`Post-Installation - Scripts <&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts>`__" + For more information, see the + ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`" section in the Yocto Project Development Tasks Manual. - The ``elf`` image type has been removed. This image type was removed @@ -3886,46 +4018,55 @@ your configuration. Removed Recipes --------------- -The following recipes have been removed: *``beecrypt``:* No longer -needed since moving to RPM 4. *``bigreqsproto``:* Replaced by -``xorgproto``. *``calibrateproto``:* Removed in favor of ``xinput``. -*``compositeproto``:* Replaced by ``xorgproto``. *``damageproto``:* -Replaced by ``xorgproto``. *``dmxproto``:* Replaced by ``xorgproto``. -*``dri2proto``:* Replaced by ``xorgproto``. *``dri3proto``:* Replaced by -``xorgproto``. *``eee-acpi-scripts``:* Became obsolete. -*``fixesproto``:* Replaced by ``xorgproto``. *``fontsproto``:* Replaced -by ``xorgproto``. *``fstests``:* Became obsolete. *``gccmakedep``:* No -longer used. *``glproto``:* Replaced by ``xorgproto``. -*``gnome-desktop3``:* No longer needed. This recipe has moved to -``meta-oe``. *``icon-naming-utils``:* No longer used since the Sato -theme was removed in 2016. *``inputproto``:* Replaced by ``xorgproto``. -*``kbproto``:* Replaced by ``xorgproto``. *``libusb-compat``:* Became -obsolete. *``libuser``:* Became obsolete. *``libnfsidmap``:* No longer -an external requirement since ``nfs-utils`` 2.2.1. ``libnfsidmap`` is -now integrated. *``libxcalibrate``:* No longer needed with ``xinput`` -*``mktemp``:* Became obsolete. The ``mktemp`` command is provided by -both ``busybox`` and ``coreutils``. *``ossp-uuid``:* Is not being -maintained and has mostly been replaced by ``uuid.h`` in ``util-linux``. -*``pax-utils``:* No longer needed. Previous QA tests that did use this -recipe are now done at build time. *``pcmciautils``:* Became obsolete. -*``pixz``:* No longer needed. ``xz`` now supports multi-threaded -compression. *``presentproto``:* Replaced by ``xorgproto``. -*``randrproto``:* Replaced by ``xorgproto``. *``recordproto``:* Replaced -by ``xorgproto``. *``renderproto``:* Replaced by ``xorgproto``. -*``resourceproto``:* Replaced by ``xorgproto``. *``scrnsaverproto``:* -Replaced by ``xorgproto``. *``trace-cmd``:* Became obsolete. ``perf`` -replaced this recipe's functionally. *``videoproto``:* Replaced by -``xorgproto``. *``wireless-tools``:* Became obsolete. Superseded by -``iw``. *``xcmiscproto``:* Replaced by ``xorgproto``. *``xextproto``:* -Replaced by ``xorgproto``. *``xf86dgaproto``:* Replaced by -``xorgproto``. *``xf86driproto``:* Replaced by ``xorgproto``. -*``xf86miscproto``:* Replaced by ``xorgproto``. *``xf86-video-omapfb``:* -Became obsolete. Use kernel modesetting driver instead. -*``xf86-video-omap``:* Became obsolete. Use kernel modesetting driver -instead. *``xf86vidmodeproto``:* Replaced by ``xorgproto``. -*``xineramaproto``:* Replaced by ``xorgproto``. *``xproto``:* Replaced -by ``xorgproto``. *``yasm``:* No longer needed since previous usages are -now satisfied by ``nasm``. +The following recipes have been removed: + +- *beecrypt*: No longer needed since moving to RPM 4. +- *bigreqsproto*: Replaced by ``xorgproto``. +- *calibrateproto*: Removed in favor of ``xinput``. +- *compositeproto*: Replaced by ``xorgproto``. +- *damageproto*: Replaced by ``xorgproto``. +- *dmxproto*: Replaced by ``xorgproto``. +- *dri2proto*: Replaced by ``xorgproto``. +- *dri3proto*: Replaced by ``xorgproto``. +- *eee-acpi-scripts*: Became obsolete. +- *fixesproto*: Replaced by ``xorgproto``. +- *fontsproto*: Replaced by ``xorgproto``. +- *fstests*: Became obsolete. +- *gccmakedep*: No longer used. +- *glproto*: Replaced by ``xorgproto``. +- *gnome-desktop3*: No longer needed. This recipe has moved to ``meta-oe``. +- *icon-naming-utils*: No longer used since the Sato theme was removed in 2016. +- *inputproto*: Replaced by ``xorgproto``. +- *kbproto*: Replaced by ``xorgproto``. +- *libusb-compat*: Became obsolete. +- *libuser*: Became obsolete. +- *libnfsidmap*: No longer an external requirement since ``nfs-utils`` 2.2.1. ``libnfsidmap`` is now integrated. +- *libxcalibrate*: No longer needed with ``xinput`` +- *mktemp*: Became obsolete. The ``mktemp`` command is provided by both ``busybox`` and ``coreutils``. +- *ossp-uuid*: Is not being maintained and has mostly been replaced by ``uuid.h`` in ``util-linux``. +- *pax-utils*: No longer needed. Previous QA tests that did use this recipe are now done at build time. +- *pcmciautils*: Became obsolete. +- *pixz*: No longer needed. ``xz`` now supports multi-threaded compression. +- *presentproto*: Replaced by ``xorgproto``. +- *randrproto*: Replaced by ``xorgproto``. +- *recordproto*: Replaced by ``xorgproto``. +- *renderproto*: Replaced by ``xorgproto``. +- *resourceproto*: Replaced by ``xorgproto``. +- *scrnsaverproto*: Replaced by ``xorgproto``. +- *trace-cmd*: Became obsolete. ``perf`` replaced this recipe's functionally. +- *videoproto*: Replaced by ``xorgproto``. +- *wireless-tools*: Became obsolete. Superseded by ``iw``. +- *xcmiscproto*: Replaced by ``xorgproto``. +- *xextproto*: Replaced by ``xorgproto``. +- *xf86dgaproto*: Replaced by ``xorgproto``. +- *xf86driproto*: Replaced by ``xorgproto``. +- *xf86miscproto*: Replaced by ``xorgproto``. +- *xf86-video-omapfb*: Became obsolete. Use kernel modesetting driver instead. +- *xf86-video-omap*: Became obsolete. Use kernel modesetting driver instead. +- *xf86vidmodeproto*: Replaced by ``xorgproto``. +- *xineramaproto*: Replaced by ``xorgproto``. +- *xproto*: Replaced by ``xorgproto``. +- *yasm*: No longer needed since previous usages are now satisfied by ``nasm``. .. _migration-2.6-packaging-changes: @@ -3934,30 +4075,30 @@ Packaging Changes The following packaging changes have been made: -- *``cmake``:* ``cmake.m4`` and ``toolchain`` files have been moved to +- *cmake*: ``cmake.m4`` and ``toolchain`` files have been moved to the main package. -- *``iptables``:* The ``iptables`` modules have been split into +- *iptables*: The ``iptables`` modules have been split into separate packages. -- *``alsa-lib``:* ``libasound`` is now in the main ``alsa-lib`` package +- *alsa-lib*: ``libasound`` is now in the main ``alsa-lib`` package instead of ``libasound``. -- *``glibc``:* ``libnss-db`` is now in its own package along with a +- *glibc*: ``libnss-db`` is now in its own package along with a ``/var/db/makedbs.sh`` script to update databases. -- *``python`` and ``python3``:* The main package has been removed from +- *python and python3*: The main package has been removed from the recipe. You must install specific packages or ``python-modules`` / ``python3-modules`` for everything. -- *``systemtap``:* Moved ``systemtap-exporter`` into its own package. +- *systemtap*: Moved ``systemtap-exporter`` into its own package. .. _migration-2.6-xorg-protocol-dependencies: XOrg Protocol dependencies -------------------------- -The "*proto" upstream repositories have been combined into one +The ``*proto`` upstream repositories have been combined into one "xorgproto" repository. Thus, the corresponding recipes have also been combined into a single ``xorgproto`` recipe. Any recipes that depend upon the older ``*proto`` recipes need to be changed to depend on the @@ -4024,19 +4165,21 @@ The following changes have been made: allows easier and more direct changes. The ``IMAGE_VERSION_SUFFIX`` variable is set in the ``bitbake.conf`` - configuration file as follows: IMAGE_VERSION_SUFFIX = "-${DATETIME}" + configuration file as follows: + :: -- Several variables have changed names for consistency: Old Variable - Name New Variable Name - ======================================================== - KERNEL_IMAGE_BASE_NAME :term:`KERNEL_IMAGE_NAME` - KERNEL_IMAGE_SYMLINK_NAME - :term:`KERNEL_IMAGE_LINK_NAME` - MODULE_TARBALL_BASE_NAME - :term:`MODULE_TARBALL_NAME` - MODULE_TARBALL_SYMLINK_NAME - :term:`MODULE_TARBALL_LINK_NAME` - INITRAMFS_BASE_NAME :term:`INITRAMFS_NAME` + IMAGE_VERSION_SUFFIX = "-${DATETIME}" + +- Several variables have changed names for consistency: + :: + + Old Variable Name New Variable Name + ======================================================== + KERNEL_IMAGE_BASE_NAME :term:`KERNEL_IMAGE_NAME` + KERNEL_IMAGE_SYMLINK_NAME :term:`KERNEL_IMAGE_LINK_NAME` + MODULE_TARBALL_BASE_NAME :term:`MODULE_TARBALL_NAME` + MODULE_TARBALL_SYMLINK_NAME :term:`MODULE_TARBALL_LINK_NAME` + INITRAMFS_BASE_NAME :term:`INITRAMFS_NAME` - The ``MODULE_IMAGE_BASE_NAME`` variable has been removed. The module tarball name is now controlled directly with the @@ -4107,8 +4250,8 @@ Override Changes The following changes have occurred: -- *The ``virtclass-native`` and ``virtclass-nativesdk`` Overrides Have - Been Removed:* The ``virtclass-native`` and ``virtclass-nativesdk`` +- The ``virtclass-native`` and ``virtclass-nativesdk`` Overrides Have + Been Removed: The ``virtclass-native`` and ``virtclass-nativesdk`` overrides have been deprecated since 2012 in favor of ``class-native`` and ``class-nativesdk``, respectively. Both ``virtclass-native`` and ``virtclass-nativesdk`` are now dropped. @@ -4119,8 +4262,8 @@ The following changes have occurred: virtclass-multilib- overrides for multilib are still valid. -- *The ``forcevariable`` Override Now Has a Higher Priority Than - ``libc`` Overrides:* The ``forcevariable`` override is documented to +- The ``forcevariable`` Override Now Has a Higher Priority Than + ``libc`` Overrides: The ``forcevariable`` override is documented to be the highest priority override. However, due to a long-standing quirk of how :term:`OVERRIDES` is set, the ``libc`` overrides (e.g. ``libc-glibc``, ``libc-musl``, and so forth) @@ -4132,7 +4275,7 @@ The following changes have occurred: check how you use ``forcevariable`` and ``libc-*`` overrides in your custom layers and configuration files to ensure they make sense. -- *The ``build-${BUILD_OS}`` Override Has Been Removed:* The +- The ``build-${BUILD_OS}`` Override Has Been Removed: The ``build-${BUILD_OS}``, which is typically ``build-linux``, override has been removed because building on a host operating system other than a recent version of Linux is neither supported nor recommended. @@ -4158,10 +4301,16 @@ where machine-specific configurations need to be applied (e.g. for ``qemu*`` machines). Currently, the new recipe packages the following files: -${sysconfdir}/machine-id ${sysconfdir}/systemd/coredump.conf -${sysconfdir}/systemd/journald.conf ${sysconfdir}/systemd/logind.conf -${sysconfdir}/systemd/system.conf ${sysconfdir}/systemd/user.conf If you -previously used bbappend files to append the ``systemd`` recipe to +:: + + ${sysconfdir}/machine-id + ${sysconfdir}/systemd/coredump.conf + ${sysconfdir}/systemd/journald.conf + ${sysconfdir}/systemd/logind.conf + ${sysconfdir}/systemd/system.conf + ${sysconfdir}/systemd/user.conf + +If you previously used bbappend files to append the ``systemd`` recipe to change any of the listed files, you must do so for the ``systemd-conf`` recipe instead. @@ -4172,13 +4321,13 @@ Automatic Testing Changes This section provides information about automatic testing changes: -- *``TEST_IMAGE`` Variable Removed:* Prior to this release, you set the +- ``TEST_IMAGE`` Variable Removed: Prior to this release, you set the ``TEST_IMAGE`` variable to "1" to enable automatic testing for successfully built images. The ``TEST_IMAGE`` variable no longer exists and has been replaced by the :term:`TESTIMAGE_AUTO` variable. -- *Inheriting the ``testimage`` and ``testsdk`` Classes:* Best +- Inheriting the ``testimage`` and ``testsdk`` Classes: Best practices now dictate that you use the :term:`IMAGE_CLASSES` variable rather than the :term:`INHERIT` variable when you inherit the @@ -4231,8 +4380,7 @@ Any failure of a ``pkg_postinst()`` script (including exit 1) triggers an error during the :ref:`ref-tasks-rootfs` task. For more information on post-installation behavior, see the -"`Post-Installation -Scripts <&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts>`__" +":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`" section in the Yocto Project Development Tasks Manual. .. _migration-2.6-python-3-profile-guided-optimizations: @@ -4253,8 +4401,12 @@ If you wish to disable Python profile-guided optimization regardless of the value of ``MACHINE_FEATURES``, then ensure that :term:`PACKAGECONFIG` for the ``python3`` recipe does not contain "pgo". You could accomplish the latter using the -following at the configuration level: PACKAGECONFIG_remove_pn-python3 = -"pgo" Alternatively, you can set ``PACKAGECONFIG`` using an append file +following at the configuration level: +:: + + PACKAGECONFIG_remove_pn-python3 = "pgo" + +Alternatively, you can set ``PACKAGECONFIG`` using an append file for the ``python3`` recipe. .. _migration-2.6-miscellaneous-changes: @@ -4267,7 +4419,10 @@ The following miscellaneous changes occurred: - Default to using the Thumb-2 instruction set for armv7a and above. If you have any custom recipes that build software that needs to be built with the ARM instruction set, change the recipe to set the - instruction set as follows: ARM_INSTRUCTION_SET = "arm" + instruction set as follows: + :: + + ARM_INSTRUCTION_SET = "arm" - ``run-postinsts`` no longer uses ``/etc/*-postinsts`` for ``dpkg/opkg`` in favor of built-in postinst support. RPM behavior @@ -4385,10 +4540,11 @@ License Value Corrections ------------------------- The following corrections have been made to the -:term:`LICENSE` values set by recipes: *socat*: Corrected -``LICENSE`` to be "GPLv2" rather than "GPLv2+". *libgfortran*: Set -license to "GPL-3.0-with-GCC-exception". *elfutils*: Removed -"Elfutils-Exception" and set to "GPLv2" for shared libraries +:term:`LICENSE` values set by recipes: + +- *socat*: Corrected ``LICENSE`` to be "GPLv2" rather than "GPLv2+". +- *libgfortran*: Set license to "GPL-3.0-with-GCC-exception". +- *elfutils*: Removed "Elfutils-Exception" and set to "GPLv2" for shared libraries .. _migration-2.7-packaging-changes: @@ -4439,26 +4595,28 @@ This section provides information about packaging changes. Removed Recipes --------------- -The following recipes have been removed: *gcc*: Drop version 7.3 -recipes. Version 8.3 now remains. *linux-yocto*: Drop versions 4.14 and -4.18 recipes. Versions 4.19 and 5.0 remain. *go*: Drop version 1.9 -recipes. Versions 1.11 and 1.12 remain. *xvideo-tests*: Became obsolete. -*libart-lgpl*: Became obsolete. *gtk-icon-utils-native*: These tools are -now provided by gtk+3-native *gcc-cross-initial*: No longer needed. -gcc-cross/gcc-crosssdk is now used instead. *gcc-crosssdk-initial*: No -longer needed. gcc-cross/gcc-crosssdk is now used instead. -*glibc-initial*: Removed because the benefits of having it for -site_config are currently outweighed by the cost of building the recipe. +The following recipes have been removed: + +- *gcc*: Drop version 7.3 recipes. Version 8.3 now remains. +- *linux-yocto*: Drop versions 4.14 and 4.18 recipes. Versions 4.19 and 5.0 remain. +- *go*: Drop version 1.9 recipes. Versions 1.11 and 1.12 remain. +- *xvideo-tests*: Became obsolete. +- *libart-lgpl*: Became obsolete. +- *gtk-icon-utils-native*: These tools are now provided by gtk+3-native +- *gcc-cross-initial*: No longer needed. gcc-cross/gcc-crosssdk is now used instead. +- *gcc-crosssdk-initial*: No longer needed. gcc-cross/gcc-crosssdk is now used instead. +- *glibc-initial*: Removed because the benefits of having it for site_config are currently outweighed by the cost of building the recipe. .. _migration-2.7-removed-classes: Removed Classes --------------- -The following classes have been removed: *distutils-tools*: This class -was never used. *bugzilla.bbclass*: Became obsolete. *distrodata*: This -functionally has been replaced by a more modern tinfoil-based -implementation. +The following classes have been removed: + +- *distutils-tools*: This class was never used. +- *bugzilla.bbclass*: Became obsolete. +- *distrodata*: This functionally has been replaced by a more modern tinfoil-based implementation. .. _migration-2.7-miscellaneous-changes: @@ -4471,7 +4629,7 @@ The following miscellaneous changes occurred: from the top-level ``scripts`` directory. - Perl now builds for the target using - ```perl-cross`http://arsv.github.io/perl-cross/ for better + `perl-cross `_ for better maintainability and improved build performance. This change should not present any problems unless you have heavily customized your Perl recipe. @@ -4883,7 +5041,9 @@ need runtime tests enabled for core components, then it is recommended that you remove "ptest" from :term:`DISTRO_FEATURES` to save a significant amount of build time e.g. by adding the following in your configuration: -DISTRO_FEATURES_remove = "ptest" +:: + + DISTRO_FEATURES_remove = "ptest" .. _migration-3.1-removed-recipes: @@ -4988,12 +5148,15 @@ parameter instead of the earlier ``name`` which overlapped with the generic ``name`` parameter. All recipes using the npm fetcher will need to be changed as a result. -An example of the new scheme: SRC_URI = -"npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \\ -npmsw://${THISDIR}/npm-shrinkwrap.json" Another example where the -sources are fetched from git rather than an npm repository: SRC_URI = -"git://github.com/foo/bar.git;protocol=https \\ -npmsw://${THISDIR}/npm-shrinkwrap.json" +An example of the new scheme: :: + + SRC_URI = "npm://registry.npmjs.org;package=array-flatten;version=1.1.1 \ + npmsw://${THISDIR}/npm-shrinkwrap.json" + +Another example where the sources are fetched from git rather than an npm repository: :: + + SRC_URI = "git://github.com/foo/bar.git;protocol=https \ + npmsw://${THISDIR}/npm-shrinkwrap.json" devtool and recipetool have also been updated to match with the npm fetcher changes. Other than producing working and more complete recipes diff --git a/documentation/ref-manual/ref-classes.rst b/documentation/ref-manual/ref-classes.rst index ace69e15a7..60ce8efd21 100644 --- a/documentation/ref-manual/ref-classes.rst +++ b/documentation/ref-manual/ref-classes.rst @@ -47,7 +47,7 @@ splitting out of debug symbols during packaging). even if the recipes do not produce architecture-specific output. Configuring such recipes for all architectures causes the - ```do_package_write_*`` <#ref-tasks-package_write_deb>`__ tasks to + ```do_package_write_*`` tasks to have different signatures for the machines with different tunings. Additionally, unnecessary rebuilds occur every time an image for a different ``MACHINE`` is built even when the recipe never changes. @@ -67,9 +67,8 @@ inherit the ``allarch`` class. The ``archiver`` class supports releasing source code and other materials with the binaries. -For more details on the source archiver, see the "`Maintaining Open -Source License Compliance During Your Product's -Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__" +For more details on the source archiver, see the +":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`" section in the Yocto Project Development Tasks Manual. You can also see the :term:`ARCHIVER_MODE` variable for information about the variable flags (varflags) that help control archive creation. @@ -86,8 +85,8 @@ standardization. This class defines a set of tasks (e.g. ``configure``, ``compile`` and so forth) that work for all Autotooled packages. It should usually be enough to define a few standard variables and then simply ``inherit autotools``. These classes can also work with software -that emulates Autotools. For more information, see the "`Autotooled -Package <&YOCTO_DOCS_DEV_URL;#new-recipe-autotooled-package>`__" section +that emulates Autotools. For more information, see the +":ref:`new-recipe-autotooled-package`" section in the Yocto Project Development Tasks Manual. By default, the ``autotools*`` classes use out-of-tree builds (i.e. @@ -177,7 +176,7 @@ example use for this class. :: SRC_URI = "git://example.com/downloads/somepackage.rpm;subpath=${BP}" - + See the " Fetchers @@ -229,8 +228,10 @@ value as a variable flag (varflag) and provide a reason, which is reported, if the package is requested to be built as the value. For example, if you want to blacklist a recipe called "exoticware", you add the following to your ``local.conf`` or distribution configuration: -INHERIT += "blacklist" PNBLACKLIST[exoticware] = "Not supported by our -organization." +:: + + INHERIT += "blacklist" + PNBLACKLIST[exoticware] = "Not supported by our organization." .. _ref-classes-buildhistory: @@ -240,8 +241,8 @@ organization." The ``buildhistory`` class records a history of build output metadata, which can be used to detect possible regressions as well as used for analysis of the build output. For more information on using Build -History, see the "`Maintaining Build Output -Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__" +History, see the +":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`" section in the Yocto Project Development Tasks Manual. .. _ref-classes-buildstats: @@ -411,8 +412,7 @@ cross-compilation tools. The ``cross-canadian`` class provides support for the recipes that build the Canadian Cross-compilation tools for SDKs. See the -"`Cross-Development Toolchain -Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__" +":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`" section in the Yocto Project Overview and Concepts Manual for more discussion on these cross-compilation tools. @@ -423,8 +423,7 @@ discussion on these cross-compilation tools. The ``crosssdk`` class provides support for the recipes that build the cross-compilation tools used for building SDKs. See the -"`Cross-Development Toolchain -Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__" +":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`" section in the Yocto Project Overview and Concepts Manual for more discussion on these cross-compilation tools. @@ -465,8 +464,7 @@ staging the files from ``DEPLOYDIR`` to ``DEPLOY_DIR_IMAGE``. ==================== The ``devshell`` class adds the ``do_devshell`` task. Distribution -policy dictates whether to include this class. See the "`Using a -Development Shell <&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell>`__" +policy dictates whether to include this class. See the ":ref:`platdev-appdev-devshell`" section in the Yocto Project Development Tasks Manual for more information about using ``devshell``. @@ -478,16 +476,26 @@ information about using ``devshell``. The ``devupstream`` class uses :term:`BBCLASSEXTEND` to add a variant of the recipe that fetches from an alternative URI (e.g. Git) instead of a -tarball. Following is an example: BBCLASSEXTEND = "devupstream:target" -SRC_URI_class-devupstream = "git://git.example.com/example" -SRCREV_class-devupstream = "abcd1234" Adding the above statements to -your recipe creates a variant that has +tarball. Following is an example: +:: + + BBCLASSEXTEND = "devupstream:target" + SRC_URI_class-devupstream = "git://git.example.com/example" + SRCREV_class-devupstream = "abcd1234" + +Adding the above statements to your recipe creates a variant that has :term:`DEFAULT_PREFERENCE` set to "-1". Consequently, you need to select the variant of the recipe to use it. Any development-specific adjustments can be done by using the ``class-devupstream`` override. Here is an example: -DEPENDS_append_class-devupstream = " gperf-native" -do_configure_prepend_class-devupstream() { touch ${S}/README } The class +:: + + DEPENDS_append_class-devupstream = " gperf-native" + do_configure_prepend_class-devupstream() { + touch ${S}/README + } + +The class currently only supports creating a development variant of the target recipe, not ``native`` or ``nativesdk`` variants. @@ -587,15 +595,19 @@ that use the :term:`B` variable to point to the directory in which the OpenEmbedded build system places the generated objects built from the recipes. By default, the ``B`` directory is set to the following, which is separate from the source directory (``S``): -${WORKDIR}/${BPN}/{PV}/ See these variables for more information: +:: + + ${WORKDIR}/${BPN}/{PV}/ + +See these variables for more information: :term:`WORKDIR`, :term:`BPN`, and :term:`PV`, For more information on the ``externalsrc`` class, see the comments in ``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`. For information on how to use the -``externalsrc`` class, see the "`Building Software from an External -Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__" +``externalsrc`` class, see the +":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`" section in the Yocto Project Development Tasks Manual. .. _ref-classes-extrausers: @@ -619,15 +631,36 @@ be performed using the useradd class to add user and group configuration to a specific recipe. -Here is an example that uses this class in an image recipe: inherit -extrausers EXTRA_USERS_PARAMS = "\\ useradd -p '' tester; \\ groupadd -developers; \\ userdel nobody; \\ groupdel -g video; \\ groupmod -g 1020 -developers; \\ usermod -s /bin/sh tester; \\ " Here is an example that -adds two users named "tester-jim" and "tester-sue" and assigns -passwords: inherit extrausers EXTRA_USERS_PARAMS = "\\ useradd -P -tester01 tester-jim; \\ useradd -P tester01 tester-sue; \\ " Finally, -here is an example that sets the root password to "1876*18": inherit -extrausers EXTRA_USERS_PARAMS = "\\ usermod -P 1876*18 root; \\ " +Here is an example that uses this class in an image recipe: +:: + + inherit extrausers + EXTRA_USERS_PARAMS = "\ + useradd -p '' tester; \ + groupadd developers; \ + userdel nobody; \ + groupdel -g video; \ + groupmod -g 1020 developers; \ + usermod -s /bin/sh tester; \ + " + +Here is an example that adds two users named "tester-jim" and "tester-sue" and assigns +passwords: +:: + + inherit extrausers + EXTRA_USERS_PARAMS = "\ + useradd -P tester01 tester-jim; \ + useradd -P tester01 tester-sue; \ + " + +Finally, here is an example that sets the root password to "1876*18": +:: + + inherit extrausers + EXTRA_USERS_PARAMS = "\ + usermod -P 1876*18 root; \ + " .. _ref-classes-fontcache: @@ -837,8 +870,7 @@ provided by the recipe ``icecc-create-env-native.bb``. .. note:: This script is a modified version and not the one that comes with - icecc - . + icecc. If you do not want the Icecream distributed compile support to apply to specific recipes or classes, you can effectively "blacklist" them by @@ -863,10 +895,18 @@ At the distribution level, you can inherit the ``icecc`` class to be sure that all builders start with the same sstate signatures. After inheriting the class, you can then disable the feature by setting the :term:`ICECC_DISABLED` variable to "1" as follows: -INHERIT_DISTRO_append = " icecc" ICECC_DISABLED ??= "1" This practice +:: + + INHERIT_DISTRO_append = " icecc" + ICECC_DISABLED ??= "1" + +This practice makes sure everyone is using the same signatures but also requires individuals that do want to use Icecream to enable the feature -individually as follows in your ``local.conf`` file: ICECC_DISABLED = "" +individually as follows in your ``local.conf`` file: +:: + + ICECC_DISABLED = "" .. _ref-classes-image: @@ -884,11 +924,11 @@ then one or more image files are created. - The ``IMAGE_INSTALL`` variable controls the list of packages to install into the image. -For information on customizing images, see the "`Customizing -Images <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage>`__" section +For information on customizing images, see the +":ref:`usingpoky-extend-customimage`" section in the Yocto Project Development Tasks Manual. For information on how images are created, see the -"`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" section in the +":ref:`images-dev-environment`" section in the Yocto Project Overview and Concpets Manual. .. _ref-classes-image-buildinfo: @@ -912,19 +952,19 @@ types. By default, the :ref:`image ` class automatically enables the ``image_types`` class. The ``image`` class uses the -``IMGCLASSES`` variable as follows: IMGCLASSES = -"rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}" IMGCLASSES += -"${@['populate_sdk_base', 'populate_sdk_ext']['linux' in -d.getVar("SDK_OS")]}" IMGCLASSES += -"${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', -'image-live', '', d)}" IMGCLASSES += -"${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', -'', d)}" IMGCLASSES += "image_types_wic" IMGCLASSES += -"rootfs-postcommands" IMGCLASSES += "image-postinst-intercepts" inherit -${IMGCLASSES} +``IMGCLASSES`` variable as follows: +:: -The ``image_types`` class also handles conversion and compression of -images. + IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}" + IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}" + IMGCLASSES += "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', 'image-live', '', d)}" + IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', '', d)}" + IMGCLASSES += "image_types_wic" + IMGCLASSES += "rootfs-postcommands" + IMGCLASSES += "image-postinst-intercepts" + inherit ${IMGCLASSES} + +The ``image_types`` class also handles conversion and compression of images. .. note:: @@ -957,7 +997,9 @@ the size of libraries contained in the image. By default, the class is enabled in the ``local.conf.template`` using the :term:`USER_CLASSES` variable as follows: -USER_CLASSES ?= "buildstats image-mklibs image-prelink" +:: + + USER_CLASSES ?= "buildstats image-mklibs image-prelink" .. _ref-classes-image-prelink: @@ -971,7 +1013,9 @@ time. By default, the class is enabled in the ``local.conf.template`` using the :term:`USER_CLASSES` variable as follows: -USER_CLASSES ?= "buildstats image-mklibs image-prelink" +:: + + USER_CLASSES ?= "buildstats image-mklibs image-prelink" .. _ref-classes-insane: @@ -1000,32 +1044,36 @@ should use :term:`INSANE_SKIP`. For example, to skip the check for symbolic link ``.so`` files in the main package of a recipe, add the following to the recipe. You need to realize that the package name override, in this example ``${PN}``, must be used: -INSANE_SKIP_${PN} += "dev-so" Please keep in mind that the QA checks +:: + + INSANE_SKIP_${PN} += "dev-so" + +Please keep in mind that the QA checks exist in order to detect real or potential problems in the packaged output. So exercise caution when disabling these checks. The following list shows the tests you can list with the ``WARN_QA`` and ``ERROR_QA`` variables: -- *``already-stripped:``* Checks that produced binaries have not +- ``already-stripped:`` Checks that produced binaries have not already been stripped prior to the build system extracting debug symbols. It is common for upstream software projects to default to stripping debug symbols for output binaries. In order for debugging to work on the target using ``-dbg`` packages, this stripping must be disabled. -- *``arch:``* Checks the Executable and Linkable Format (ELF) type, bit +- ``arch:`` Checks the Executable and Linkable Format (ELF) type, bit size, and endianness of any binaries to ensure they match the target architecture. This test fails if any binaries do not match the type since there would be an incompatibility. The test could indicate that the wrong compiler or compiler options have been used. Sometimes software, like bootloaders, might need to bypass this check. -- *``buildpaths:``* Checks for paths to locations on the build host +- ``buildpaths:`` Checks for paths to locations on the build host inside the output files. Currently, this test triggers too many false positives and thus is not normally enabled. -- *``build-deps:``* Determines if a build-time dependency that is +- ``build-deps:`` Determines if a build-time dependency that is specified through :term:`DEPENDS`, explicit :term:`RDEPENDS`, or task-level dependencies exists to match any runtime dependency. This determination is particularly @@ -1045,20 +1093,20 @@ The following list shows the tests you can list with the ``WARN_QA`` and ``initscripts`` recipe is actually built and thus the ``initscripts-functions`` package is made available. -- *``compile-host-path:``* Checks the +- ``compile-host-path:`` Checks the :ref:`ref-tasks-compile` log for indications that paths to locations on the build host were used. Using such paths might result in host contamination of the build output. -- *``debug-deps:``* Checks that all packages except ``-dbg`` packages +- ``debug-deps:`` Checks that all packages except ``-dbg`` packages do not depend on ``-dbg`` packages, which would cause a packaging bug. -- *``debug-files:``* Checks for ``.debug`` directories in anything but +- ``debug-files:`` Checks for ``.debug`` directories in anything but the ``-dbg`` package. The debug files should all be in the ``-dbg`` package. Thus, anything packaged elsewhere is incorrect packaging. -- *``dep-cmp:``* Checks for invalid version comparison statements in +- ``dep-cmp:`` Checks for invalid version comparison statements in runtime dependency relationships between packages (i.e. in :term:`RDEPENDS`, :term:`RRECOMMENDS`, @@ -1069,22 +1117,22 @@ The following list shows the tests you can list with the ``WARN_QA`` and comparisons might trigger failures or undesirable behavior when passed to the package manager. -- *``desktop:``* Runs the ``desktop-file-validate`` program against any +- ``desktop:`` Runs the ``desktop-file-validate`` program against any ``.desktop`` files to validate their contents against the specification for ``.desktop`` files. -- *``dev-deps:``* Checks that all packages except ``-dev`` or +- ``dev-deps:`` Checks that all packages except ``-dev`` or ``-staticdev`` packages do not depend on ``-dev`` packages, which would be a packaging bug. -- *``dev-so:``* Checks that the ``.so`` symbolic links are in the +- ``dev-so:`` Checks that the ``.so`` symbolic links are in the ``-dev`` package and not in any of the other packages. In general, these symlinks are only useful for development purposes. Thus, the ``-dev`` package is the correct location for them. Some very rare cases do exist for dynamically loaded modules where these symlinks are needed instead in the main package. -- *``file-rdeps:``* Checks that file-level dependencies identified by +- ``file-rdeps:`` Checks that file-level dependencies identified by the OpenEmbedded build system at packaging time are satisfied. For example, a shell script might start with the line ``#!/bin/bash``. This line would translate to a file dependency on ``/bin/bash``. Of @@ -1097,10 +1145,10 @@ The following list shows the tests you can list with the ``WARN_QA`` and :term:`RDEPENDS` exist to handle any file-level dependency detected in packaged files. -- *``files-invalid:``* Checks for :term:`FILES` variable +- ``files-invalid:`` Checks for :term:`FILES` variable values that contain "//", which is invalid. -- *``host-user-contaminated:``* Checks that no package produced by the +- ``host-user-contaminated:`` Checks that no package produced by the recipe contains any files outside of ``/home`` with a user or group ID that matches the user running BitBake. A match usually indicates that the files are being installed with an incorrect UID/GID, since @@ -1108,16 +1156,16 @@ The following list shows the tests you can list with the ``WARN_QA`` and see the section describing the :ref:`ref-tasks-install` task. -- *``incompatible-license:``* Report when packages are excluded from +- ``incompatible-license:`` Report when packages are excluded from being created due to being marked with a license that is in :term:`INCOMPATIBLE_LICENSE`. -- *``install-host-path:``* Checks the +- ``install-host-path:`` Checks the :ref:`ref-tasks-install` log for indications that paths to locations on the build host were used. Using such paths might result in host contamination of the build output. -- *``installed-vs-shipped:``* Reports when files have been installed +- ``installed-vs-shipped:`` Reports when files have been installed within ``do_install`` but have not been included in any package by way of the :term:`FILES` variable. Files that do not appear in any package cannot be present in an image later on in the @@ -1125,67 +1173,69 @@ The following list shows the tests you can list with the ``WARN_QA`` and installed at all. These files can be deleted at the end of ``do_install`` if the files are not needed in any package. -- *``invalid-chars:``* Checks that the recipe metadata variables +- ``invalid-chars:`` Checks that the recipe metadata variables :term:`DESCRIPTION`, :term:`SUMMARY`, :term:`LICENSE`, and :term:`SECTION` do not contain non-UTF-8 characters. Some package managers do not support such characters. -- *``invalid-packageconfig:``* Checks that no undefined features are +- ``invalid-packageconfig:`` Checks that no undefined features are being added to :term:`PACKAGECONFIG`. For example, any name "foo" for which the following form does not exist: - PACKAGECONFIG[foo] = "..." + :: -- *``la:``* Checks ``.la`` files for any ``TMPDIR`` paths. Any ``.la`` + PACKAGECONFIG[foo] = "..." + +- ``la:`` Checks ``.la`` files for any ``TMPDIR`` paths. Any ``.la`` file containing these paths is incorrect since ``libtool`` adds the correct sysroot prefix when using the files automatically itself. -- *``ldflags:``* Ensures that the binaries were linked with the +- ``ldflags:`` Ensures that the binaries were linked with the :term:`LDFLAGS` options provided by the build system. If this test fails, check that the ``LDFLAGS`` variable is being passed to the linker command. -- *``libdir:``* Checks for libraries being installed into incorrect +- ``libdir:`` Checks for libraries being installed into incorrect (possibly hardcoded) installation paths. For example, this test will catch recipes that install ``/lib/bar.so`` when ``${base_libdir}`` is "lib32". Another example is when recipes install ``/usr/lib64/foo.so`` when ``${libdir}`` is "/usr/lib". -- *``libexec:``* Checks if a package contains files in +- ``libexec:`` Checks if a package contains files in ``/usr/libexec``. This check is not performed if the ``libexecdir`` variable has been set explicitly to ``/usr/libexec``. -- *``packages-list:``* Checks for the same package being listed +- ``packages-list:`` Checks for the same package being listed multiple times through the :term:`PACKAGES` variable value. Installing the package in this manner can cause errors during packaging. -- *``perm-config:``* Reports lines in ``fs-perms.txt`` that have an +- ``perm-config:`` Reports lines in ``fs-perms.txt`` that have an invalid format. -- *``perm-line:``* Reports lines in ``fs-perms.txt`` that have an +- ``perm-line:`` Reports lines in ``fs-perms.txt`` that have an invalid format. -- *``perm-link:``* Reports lines in ``fs-perms.txt`` that specify +- ``perm-link:`` Reports lines in ``fs-perms.txt`` that specify 'link' where the specified target already exists. -- *``perms:``* Currently, this check is unused but reserved. +- ``perms:`` Currently, this check is unused but reserved. -- *``pkgconfig:``* Checks ``.pc`` files for any +- ``pkgconfig:`` Checks ``.pc`` files for any :term:`TMPDIR`/:term:`WORKDIR` paths. Any ``.pc`` file containing these paths is incorrect since ``pkg-config`` itself adds the correct sysroot prefix when the files are accessed. -- *``pkgname:``* Checks that all packages in +- ``pkgname:`` Checks that all packages in :term:`PACKAGES` have names that do not contain invalid characters (i.e. characters other than 0-9, a-z, ., +, and -). -- *``pkgv-undefined:``* Checks to see if the ``PKGV`` variable is +- ``pkgv-undefined:`` Checks to see if the ``PKGV`` variable is undefined during :ref:`ref-tasks-package`. -- *``pkgvarcheck:``* Checks through the variables +- ``pkgvarcheck:`` Checks through the variables :term:`RDEPENDS`, :term:`RRECOMMENDS`, :term:`RSUGGESTS`, @@ -1199,7 +1249,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and unnecessarily complicate dependencies of other packages within the same recipe or have other unintended consequences. -- *``pn-overrides:``* Checks that a recipe does not have a name +- ``pn-overrides:`` Checks that a recipe does not have a name (:term:`PN`) value that appears in :term:`OVERRIDES`. If a recipe is named such that its ``PN`` value matches something already in ``OVERRIDES`` (e.g. @@ -1208,43 +1258,43 @@ The following list shows the tests you can list with the ``WARN_QA`` and For example, assignments such as ``FILES_${PN} = "xyz"`` effectively turn into ``FILES = "xyz"``. -- *``rpaths:``* Checks for rpaths in the binaries that contain build +- ``rpaths:`` Checks for rpaths in the binaries that contain build system paths such as ``TMPDIR``. If this test fails, bad ``-rpath`` options are being passed to the linker commands and your binaries have potential security issues. -- *``split-strip:``* Reports that splitting or stripping debug symbols +- ``split-strip:`` Reports that splitting or stripping debug symbols from binaries has failed. -- *``staticdev:``* Checks for static library files (``*.a``) in +- ``staticdev:`` Checks for static library files (``*.a``) in non-``staticdev`` packages. -- *``symlink-to-sysroot:``* Checks for symlinks in packages that point +- ``symlink-to-sysroot:`` Checks for symlinks in packages that point into :term:`TMPDIR` on the host. Such symlinks will work on the host, but are clearly invalid when running on the target. -- *``textrel:``* Checks for ELF binaries that contain relocations in +- ``textrel:`` Checks for ELF binaries that contain relocations in their ``.text`` sections, which can result in a performance impact at runtime. See the explanation for the ```ELF binary`` <#qa-issue-textrel>`__ message for more information regarding runtime performance issues. -- *``unlisted-pkg-lics:``* Checks that all declared licenses applying +- ``unlisted-pkg-lics:`` Checks that all declared licenses applying for a package are also declared on the recipe level (i.e. any license in ``LICENSE_*`` should appear in :term:`LICENSE`). -- *``useless-rpaths:``* Checks for dynamic library load paths (rpaths) +- ``useless-rpaths:`` Checks for dynamic library load paths (rpaths) in the binaries that by default on a standard system are searched by the linker (e.g. ``/lib`` and ``/usr/lib``). While these paths will not cause any breakage, they do waste space and are unnecessary. -- *``var-undefined:``* Reports when variables fundamental to packaging +- ``var-undefined:`` Reports when variables fundamental to packaging (i.e. :term:`WORKDIR`, :term:`DEPLOY_DIR`, :term:`D`, :term:`PN`, and :term:`PKGD`) are undefined during :ref:`ref-tasks-package`. -- *``version-going-backwards:``* If Build History is enabled, reports +- ``version-going-backwards:`` If Build History is enabled, reports when a package being written out has a lower version than the previously written package under the same name. If you are placing output packages into a feed and upgrading packages on a target system @@ -1257,7 +1307,7 @@ The following list shows the tests you can list with the ``WARN_QA`` and If you are not using runtime package management on your target system, then you do not need to worry about this situation. -- *``xorg-driver-abi:``* Checks that all packages containing Xorg +- ``xorg-driver-abi:`` Checks that all packages containing Xorg drivers have ABI dependencies. The ``xserver-xorg`` recipe provides driver ABI names. All drivers should depend on the ABI versions that they have been built against. Driver recipes that include @@ -1293,9 +1343,8 @@ packages such as ``kernel-vmlinux``. The ``kernel`` class contains logic that allows you to embed an initial RAM filesystem (initramfs) image when you build the kernel image. For -information on how to build an initramfs, see the "`Building an Initial -RAM Filesystem (initramfs) -Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section in +information on how to build an initramfs, see the +":ref:`building-an-initramfs-image`" section in the Yocto Project Development Tasks Manual. Various other classes are used by the ``kernel`` and ``module`` classes @@ -1545,8 +1594,7 @@ and implements the :ref:`ref-tasks-compile` and everything needed to build and package a kernel module. For general information on out-of-tree Linux kernel modules, see the -"`Incorporating Out-of-Tree -Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__" +":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`" section in the Yocto Project Linux Kernel Development Manual. .. _ref-classes-module-base: @@ -1569,9 +1617,8 @@ The ``multilib*`` classes provide support for building libraries with different target optimizations or target architectures and installing them side-by-side in the same image. -For more information on using the Multilib feature, see the "`Combining -Multiple Versions of Library Files into One -Image <&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image>`__" +For more information on using the Multilib feature, see the +":ref:`combining-multiple-versions-library-files-into-one-image`" section in the Yocto Project Development Tasks Manual. .. _ref-classes-native: @@ -1597,14 +1644,18 @@ a couple different ways: naming convention: :: - myrecipe-native.bb - + myrecipe-native.bb + Not using this naming convention can lead to subtle problems caused by existing code that depends on that naming convention. - Create or modify a target recipe that contains the following: - :term:`BBCLASSEXTEND` = "native" Inside the + :: + + BBCLASSEXTEND = "native" + + Inside the recipe, use ``_class-native`` and ``_class-target`` overrides to specify any functionality specific to the respective native or target case. @@ -1632,7 +1683,11 @@ couple different ways: that the ``nativesdk`` class is inherited last. - Create a ``nativesdk`` variant of any recipe by adding the following: - :term:`BBCLASSEXTEND` = "nativesdk" Inside the + :: + + BBCLASSEXTEND = "nativesdk" + + Inside the recipe, use ``_class-nativesdk`` and ``_class-target`` overrides to specify any functionality specific to the respective SDK machine or target case. @@ -1643,7 +1698,7 @@ couple different ways: :: nativesdk-myrecipe.bb - + Not doing so can lead to subtle problems because code exists that depends on the naming convention. @@ -1675,9 +1730,8 @@ package manager (NPM) `__. npm:// fetcher to have dependencies fetched and packaged automatically. -For information on how to create NPM packages, see the "`Creating Node -Package Manager (NPM) -Packages <&YOCTO_DOCS_DEV_URL;#creating-node-package-manager-npm-packages>`__" +For information on how to create NPM packages, see the +":ref:`dev-manual/dev-manual-common-tasks:creating node package manager (npm) packages`" section in the Yocto Project Development Tasks Manual. .. _ref-classes-oelint: @@ -1706,8 +1760,12 @@ before attempting to fetch it from the upstream specified in To use this class, inherit it globally and specify :term:`SOURCE_MIRROR_URL`. Here is an example: -INHERIT += "own-mirrors" SOURCE_MIRROR_URL = -"http://example.com/my-source-mirror" You can specify only a single URL +:: + + INHERIT += "own-mirrors" + SOURCE_MIRROR_URL = "http://example.com/my-source-mirror" + +You can specify only a single URL in ``SOURCE_MIRROR_URL``. .. _ref-classes-package: @@ -1742,9 +1800,8 @@ first class listed in this variable is used for image generation. If you take the optional step to set up a repository (package feed) on the development host that can be used by DNF, you can install packages from the feed while you are running the image on the target (i.e. -runtime installation of packages). For more information, see the "`Using -Runtime Package -Management <&YOCTO_DOCS_DEV_URL;#using-runtime-package-management>`__" +runtime installation of packages). For more information, see the +":ref:`dev-manual/dev-manual-common-tasks:using runtime package management`" section in the Yocto Project Development Tasks Manual. The package-specific class you choose can affect build-time performance @@ -1774,9 +1831,9 @@ consider some further things about using RPM: You can find additional information on the effects of the package class at these two Yocto Project mailing list links: -- `https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html <&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006362.html>`__ +- https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html -- `https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html <&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006363.html>`__ +- https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html .. _ref-classes-package_deb: @@ -1870,9 +1927,8 @@ group recipes (e.g. ``PACKAGES``, ``PACKAGE_ARCH``, ``ALLOW_EMPTY``, and so forth). It is highly recommended that all package group recipes inherit this class. -For information on how to use this class, see the "`Customizing Images -Using Custom Package -Groups <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-customtasks>`__" +For information on how to use this class, see the +":ref:`usingpoky-extend-customimage-customtasks`" section in the Yocto Project Development Tasks Manual. Previously, this class was called the ``task`` class. @@ -1937,8 +1993,7 @@ files. The ``populate_sdk`` class provides support for SDK-only recipes. For information on advantages gained when building a cross-development toolchain using the :ref:`ref-tasks-populate_sdk` -task, see the "`Building an SDK -Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__" +task, see the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. @@ -1950,19 +2005,19 @@ Software Development Kit (eSDK) manual. The ``populate_sdk_*`` classes support SDK creation and consist of the following classes: -- *``populate_sdk_base``:* The base class supporting SDK creation under +- ``populate_sdk_base``: The base class supporting SDK creation under all package managers (i.e. DEB, RPM, and opkg). -- *``populate_sdk_deb``:* Supports creation of the SDK given the Debian +- ``populate_sdk_deb``: Supports creation of the SDK given the Debian package manager. -- *``populate_sdk_rpm``:* Supports creation of the SDK given the RPM +- ``populate_sdk_rpm``: Supports creation of the SDK given the RPM package manager. -- *``populate_sdk_ipk``:* Supports creation of the SDK given the opkg +- ``populate_sdk_ipk``: Supports creation of the SDK given the opkg (IPK format) package manager. -- *``populate_sdk_ext``:* Supports extensible SDK creation under all +- ``populate_sdk_ext``: Supports extensible SDK creation under all package managers. The ``populate_sdk_base`` class inherits the appropriate @@ -1977,8 +2032,10 @@ contains the cross-compiler and associated tooling, and the target, which contains a target root filesystem that is configured for the SDK usage. These two images reside in :term:`SDK_OUTPUT`, which consists of the following: -${SDK_OUTPUT}/${SDK_ARCH}-nativesdk-pkgs -${SDK_OUTPUT}/${SDKTARGETSYSROOT}/target-pkgs +:: + + ${SDK_OUTPUT}/${SDK_ARCH}-nativesdk-pkgs + ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/target-pkgs Finally, the base populate SDK class creates the toolchain environment setup script, the tarball of the SDK, and the installer. @@ -1989,13 +2046,12 @@ These classes are inherited by and used with the ``populate_sdk_base`` class. For more information on the cross-development toolchain generation, see -the "`Cross-Development Toolchain -Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__" +the ":ref:`overview-manual/overview-manual-concepts:cross-development toolchain generation`" section in the Yocto Project Overview and Concepts Manual. For information on advantages gained when building a cross-development toolchain using the :ref:`ref-tasks-populate_sdk` -task, see the "`Building an SDK -Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__" +task, see the +":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. @@ -2034,8 +2090,8 @@ The ``primport`` class provides functionality for importing ``prserv.bbclass`` ================== -The ``prserv`` class provides functionality for using a `PR -service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__ in order to +The ``prserv`` class provides functionality for using a :ref:`PR +service ` in order to automatically manage the incrementing of the :term:`PR` variable for each recipe. @@ -2054,11 +2110,10 @@ runtime tests for recipes that build software that provides these tests. This class is intended to be inherited by individual recipes. However, the class' functionality is largely disabled unless "ptest" appears in -:term:`DISTRO_FEATURES`. See the "`Testing -Packages With -ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in -the Yocto Project Development Tasks Manual for more information on -ptest. +:term:`DISTRO_FEATURES`. See the +":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`" +section in the Yocto Project Development Tasks Manual for more information +on ptest. .. _ref-classes-ptest-gnome: @@ -2068,10 +2123,9 @@ ptest. Enables package tests (ptests) specifically for GNOME packages, which have tests intended to be executed with ``gnome-desktop-testing``. -For information on setting up and running ptests, see the "`Testing -Packages With -ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section in -the Yocto Project Development Tasks Manual. +For information on setting up and running ptests, see the +":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`" +section in the Yocto Project Development Tasks Manual. .. _ref-classes-python-dir: @@ -2142,7 +2196,9 @@ absent from both the sysroot and target packages. If a recipe needs the ``.la`` files to be installed, then the recipe can override the removal by setting ``REMOVE_LIBTOOL_LA`` to "0" as follows: -REMOVE_LIBTOOL_LA = "0" +:: + + REMOVE_LIBTOOL_LA = "0" .. note:: @@ -2155,9 +2211,9 @@ REMOVE_LIBTOOL_LA = "0" ``report-error.bbclass`` ======================== -The ``report-error`` class supports enabling the `error reporting -tool <&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool>`__, which -allows you to submit build error information to a central database. +The ``report-error`` class supports enabling the :ref:`error reporting +tool `", +which allows you to submit build error information to a central database. The class collects debug information for recipe, recipe version, task, machine, distro, build system, target system, host distro, branch, @@ -2182,14 +2238,20 @@ preserves these files for inspection and possible debugging purposes. If you would rather have these files deleted to save disk space as the build progresses, you can enable ``rm_work`` by adding the following to your ``local.conf`` file, which is found in the :term:`Build Directory`. -INHERIT += "rm_work" If you are +:: + + INHERIT += "rm_work" + +If you are modifying and building source code out of the work directory for a recipe, enabling ``rm_work`` will potentially result in your changes to the source being lost. To exclude some recipes from having their work directories deleted by ``rm_work``, you can add the names of the recipe or recipes you are working on to the ``RM_WORK_EXCLUDE`` variable, which can also be set in your ``local.conf`` file. Here is an example: -RM_WORK_EXCLUDE += "busybox glibc" +:: + + RM_WORK_EXCLUDE += "busybox glibc" .. _ref-classes-rootfs*: @@ -2219,8 +2281,7 @@ The root filesystem is created from packages using one of the :term:`PACKAGE_CLASSES` variable. For information on how root filesystem images are created, see the -"`Image -Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__" +:ref:`image-generation-dev-environment`" section in the Yocto Project Overview and Concepts Manual. .. _ref-classes-sanity: @@ -2339,9 +2400,9 @@ The ``sstate`` class provides support for Shared State (sstate). By default, the class is enabled through the :term:`INHERIT_DISTRO` variable's default value. -For more information on sstate, see the "`Shared State -Cache <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__" section in the Yocto -Project Overview and Concepts Manual. +For more information on sstate, see the +":ref:`overview-manual/overview-manual-concepts:shared state cache`" +section in the Yocto Project Overview and Concepts Manual. .. _ref-classes-staging: @@ -2510,14 +2571,17 @@ You should set :term:`SYSTEMD_SERVICE` to the name of the service file. You should also use a package name override to indicate the package to which the value applies. If the value applies to the recipe's main package, use ``${``\ :term:`PN`\ ``}``. Here -is an example from the connman recipe: SYSTEMD_SERVICE_${PN} = -"connman.service" Services are set up to start on boot automatically +is an example from the connman recipe: +:: + + SYSTEMD_SERVICE_${PN} = "connman.service" + +Services are set up to start on boot automatically unless you have set :term:`SYSTEMD_AUTO_ENABLE` to "disable". -For more information on ``systemd``, see the "`Selecting an -Initialization -Manager <&YOCTO_DOCS_DEV_URL;#selecting-an-initialization-manager>`__" +For more information on ``systemd``, see the +":ref:`dev-manual/dev-manual-common-tasks:selecting an initialization manager`" section in the Yocto Project Development Tasks Manual. .. _ref-classes-systemd-boot: @@ -2593,13 +2657,17 @@ The tests are commands that run on the target system over ``ssh``. Each test is written in Python and makes use of the ``unittest`` module. The ``testimage.bbclass`` runs tests on an image when called using the -following: $ bitbake -c testimage image The ``testimage-auto`` class +following: +:: + + $ bitbake -c testimage image + +The ``testimage-auto`` class runs tests on an image after the image is constructed (i.e. :term:`TESTIMAGE_AUTO` must be set to "1"). For information on how to enable, run, and create new tests, see the -"`Performing Automated Runtime -Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" +":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" section in the Yocto Project Development Tasks Manual. .. _ref-classes-testsdk: @@ -2609,7 +2677,10 @@ section in the Yocto Project Development Tasks Manual. This class supports running automated tests against software development kits (SDKs). The ``testsdk`` class runs tests on an SDK when called -using the following: $ bitbake -c testsdk image +using the following: +:: + + $ bitbake -c testsdk image .. note:: @@ -2682,7 +2753,9 @@ The ``typecheck`` class provides support for validating the values of variables set at the configuration level against their defined types. The OpenEmbedded build system allows you to define the type of a variable using the "type" varflag. Here is an example: -IMAGE_FEATURES[type] = "list" +:: + + IMAGE_FEATURES[type] = "list" .. _ref-classes-uboot-config: @@ -2690,11 +2763,18 @@ IMAGE_FEATURES[type] = "list" ======================== The ``uboot-config`` class provides support for U-Boot configuration for -a machine. Specify the machine in your recipe as follows: UBOOT_CONFIG -??= UBOOT_CONFIG[foo] = "config,images" You can also specify -the machine using this method: UBOOT_MACHINE = "config" See the -:term:`UBOOT_CONFIG` and -:term:`UBOOT_MACHINE` variables for additional +a machine. Specify the machine in your recipe as follows: +:: + + UBOOT_CONFIG ??= + UBOOT_CONFIG[foo] = "config,images" + +You can also specify the machine using this method: +:: + + UBOOT_MACHINE = "config" + +See the :term:`UBOOT_CONFIG` and :term:`UBOOT_MACHINE` variables for additional information. .. _ref-classes-uninative: diff --git a/documentation/ref-manual/ref-devtool-reference.rst b/documentation/ref-manual/ref-devtool-reference.rst index ca1d7fd0cb..eaca45ae25 100644 --- a/documentation/ref-manual/ref-devtool-reference.rst +++ b/documentation/ref-manual/ref-devtool-reference.rst @@ -11,8 +11,7 @@ is a key part of the extensible SDK. This chapter provides a Quick Reference for the ``devtool`` command. For more information on how to apply the command when using the extensible -SDK, see the "`Using the Extensible -SDK <&YOCTO_DOCS_SDK_URL;#sdk-extensible>`__" chapter in the Yocto +SDK, see the ":doc:`../sdk-manual/sdk-extensible`" chapter in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. @@ -23,66 +22,99 @@ Getting Help The ``devtool`` command line is organized similarly to Git in that it has a number of sub-commands for each function. You can run -``devtool --help`` to see all the commands: $ devtool -h NOTE: Starting -bitbake server... usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] -[-d] [-q] [--color COLOR] [-h] ... OpenEmbedded development -tool options: --basepath BASEPATH Base directory of SDK / build -directory --bbpath BBPATH Explicitly specify the BBPATH, rather than -getting it from the metadata -d, --debug Enable debug output -q, --quiet -Print only errors --color COLOR Colorize output (where COLOR is auto, -always, never) -h, --help show this help message and exit subcommands: -Beginning work on a recipe: add Add a new recipe modify Modify the -source for an existing recipe upgrade Upgrade an existing recipe Getting -information: status Show workspace status search Search available -recipes latest-version Report the latest version of an existing recipe -check-upgrade-status Report upgradability for multiple (or all) recipes -Working on a recipe in the workspace: build Build a recipe rename Rename -a recipe file in the workspace edit-recipe Edit a recipe file -find-recipe Find a recipe file configure-help Get help on configure -script options update-recipe Apply changes from external source tree to -recipe reset Remove a recipe from your workspace finish Finish working -on a recipe in your workspace Testing changes on target: deploy-target -Deploy recipe output files to live target machine undeploy-target -Undeploy recipe output files in live target machine build-image Build -image including workspace recipe packages Advanced: create-workspace Set -up workspace in an alternative location export Export workspace into a -tar archive import Import exported tar archive into workspace extract -Extract the source for an existing recipe sync Synchronize the source -tree for an existing recipe Use devtool --help to get help -on a specific command As directed in the general help output, you can +``devtool --help`` to see all the commands: +:: + + $ devtool -h + NOTE: Starting bitbake server... + usage: devtool [--basepath BASEPATH] [--bbpath BBPATH] [-d] [-q] [--color COLOR] [-h] ... + + OpenEmbedded development tool + + options: + --basepath BASEPATH Base directory of SDK / build directory + --bbpath BBPATH Explicitly specify the BBPATH, rather than getting it from the metadata + -d, --debug Enable debug output + -q, --quiet Print only errors + --color COLOR Colorize output (where COLOR is auto, always, never) + -h, --help show this help message and exit + + subcommands: + Beginning work on a recipe: + add Add a new recipe + modify Modify the source for an existing recipe + upgrade Upgrade an existing recipe + Getting information: + status Show workspace status + latest-version Report the latest version of an existing recipe + check-upgrade-status Report upgradability for multiple (or all) recipes + search Search available recipes + Working on a recipe in the workspace: + build Build a recipe + rename Rename a recipe file in the workspace + edit-recipe Edit a recipe file + find-recipe Find a recipe file + configure-help Get help on configure script options + update-recipe Apply changes from external source tree to recipe + reset Remove a recipe from your workspace + finish Finish working on a recipe in your workspace + Testing changes on target: + deploy-target Deploy recipe output files to live target machine + undeploy-target Undeploy recipe output files in live target machine + build-image Build image including workspace recipe packages + Advanced: + create-workspace Set up workspace in an alternative location + extract Extract the source for an existing recipe + sync Synchronize the source tree for an existing recipe + menuconfig Alter build-time configuration for a recipe + import Import exported tar archive into workspace + export Export workspace into a tar archive + other: + selftest-reverse Reverse value (for selftest) + pluginfile Print the filename of this plugin + bbdir Print the BBPATH directory of this plugin + count How many times have this plugin been registered. + multiloaded How many times have this plugin been initialized + Use devtool --help to get help on a specific command + +As directed in the general help output, you can get more syntax on a specific command by providing the command name and -using "--help": $ devtool add --help NOTE: Starting bitbake server... -usage: devtool add [-h] [--same-dir \| --no-same-dir] [--fetch URI] -[--fetch-dev] [--version VERSION] [--no-git] [--srcrev SRCREV \| ---autorev] [--srcbranch SRCBRANCH] [--binary] [--also-native] -[--src-subdir SUBDIR] [--mirrors] [--provides PROVIDES] [recipename] -[srctree] [fetchuri] Adds a new recipe to the workspace to build a -specified source tree. Can optionally fetch a remote URI and unpack it -to create the source tree. arguments: recipename Name for new recipe to -add (just name - no version, path or extension). If not specified, will -attempt to auto-detect it. srctree Path to external source tree. If not -specified, a subdirectory of /home/scottrif/poky/build/workspace/sources -will be used. fetchuri Fetch the specified URI and extract it to create -the source tree options: -h, --help show this help message and exit ---same-dir, -s Build in same directory as source --no-same-dir Force -build in a separate build directory --fetch URI, -f URI Fetch the -specified URI and extract it to create the source tree (deprecated - -pass as positional argument instead) --fetch-dev For npm, also fetch -devDependencies --version VERSION, -V VERSION Version to use within -recipe (PV) --no-git, -g If fetching source, do not set up source tree -as a git repository --srcrev SRCREV, -S SRCREV Source revision to fetch -if fetching from an SCM such as git (default latest) --autorev, -a When -fetching from a git repository, set SRCREV in the recipe to a floating -revision instead of fixed --srcbranch SRCBRANCH, -B SRCBRANCH Branch in -source repository if fetching from an SCM such as git (default master) ---binary, -b Treat the source tree as something that should be installed -verbatim (no compilation, same directory structure). Useful with binary -packages e.g. RPMs. --also-native Also add native variant (i.e. support -building recipe for the build host as well as the target machine) ---src-subdir SUBDIR Specify subdirectory within source tree to use ---mirrors Enable PREMIRRORS and MIRRORS for source tree fetching -(disable by default). --provides PROVIDES, -p PROVIDES Specify an alias -for the item provided by the recipe. E.g. virtual/libgl +using "--help": +:: + + $ devtool add --help + NOTE: Starting bitbake server... + usage: devtool add [-h] [--same-dir | --no-same-dir] [--fetch URI] [--npm-dev] [--version VERSION] [--no-git] [--srcrev SRCREV | --autorev] [--srcbranch SRCBRANCH] [--binary] [--also-native] [--src-subdir SUBDIR] [--mirrors] + [--provides PROVIDES] + [recipename] [srctree] [fetchuri] + + Adds a new recipe to the workspace to build a specified source tree. Can optionally fetch a remote URI and unpack it to create the source tree. + + arguments: + recipename Name for new recipe to add (just name - no version, path or extension). If not specified, will attempt to auto-detect it. + srctree Path to external source tree. If not specified, a subdirectory of /media/build1/poky/build/workspace/sources will be used. + fetchuri Fetch the specified URI and extract it to create the source tree + + options: + -h, --help show this help message and exit + --same-dir, -s Build in same directory as source + --no-same-dir Force build in a separate build directory + --fetch URI, -f URI Fetch the specified URI and extract it to create the source tree (deprecated - pass as positional argument instead) + --npm-dev For npm, also fetch devDependencies + --version VERSION, -V VERSION + Version to use within recipe (PV) + --no-git, -g If fetching source, do not set up source tree as a git repository + --srcrev SRCREV, -S SRCREV + Source revision to fetch if fetching from an SCM such as git (default latest) + --autorev, -a When fetching from a git repository, set SRCREV in the recipe to a floating revision instead of fixed + --srcbranch SRCBRANCH, -B SRCBRANCH + Branch in source repository if fetching from an SCM such as git (default master) + --binary, -b Treat the source tree as something that should be installed verbatim (no compilation, same directory structure). Useful with binary packages e.g. RPMs. + --also-native Also add native variant (i.e. support building recipe for the build host as well as the target machine) + --src-subdir SUBDIR Specify subdirectory within source tree to use + --mirrors Enable PREMIRRORS and MIRRORS for source tree fetching (disable by default). + --provides PROVIDES, -p PROVIDES + Specify an alias for the item provided by the recipe. E.g. virtual/libgl .. _devtool-the-workspace-layer-structure: @@ -99,22 +131,35 @@ The following figure shows the workspace structure: :align: center :scale: 70% -attic - A directory created if devtool believes it must preserve -anything when you run "devtool reset". For example, if you run "devtool -add", make changes to the recipe, and then run "devtool reset", devtool -takes notice that the file has been changed and moves it into the attic -should you still want the recipe. README - Provides information on what -is in workspace layer and how to manage it. .devtool_md5 - A checksum -file used by devtool. appends - A directory that contains \*.bbappend -files, which point to external source. conf - A configuration directory -that contains the layer.conf file. recipes - A directory containing -recipes. This directory contains a folder for each directory added whose -name matches that of the added recipe. devtool places the recipe.bb file -within that sub-directory. sources - A directory containing a working -copy of the source files used when building the recipe. This is the -default directory used as the location of the source tree when you do -not provide a source tree path. This directory contains a folder for -each set of source files matched to a corresponding recipe. +:: + + attic - A directory created if devtool believes it must preserve + anything when you run "devtool reset". For example, if you + run "devtool add", make changes to the recipe, and then + run "devtool reset", devtool takes notice that the file has + been changed and moves it into the attic should you still + want the recipe. + + README - Provides information on what is in workspace layer and how to + manage it. + + .devtool_md5 - A checksum file used by devtool. + + appends - A directory that contains *.bbappend files, which point to + external source. + + conf - A configuration directory that contains the layer.conf file. + + recipes - A directory containing recipes. This directory contains a + folder for each directory added whose name matches that of the + added recipe. devtool places the recipe.bb file + within that sub-directory. + + sources - A directory containing a working copy of the source files used + when building the recipe. This is the default directory used + as the location of the source tree when you do not provide a + source tree path. This directory contains a folder for each + set of source files matched to a corresponding recipe. .. _devtool-adding-a-new-recipe-to-the-workspace: @@ -127,8 +172,10 @@ you. The source files the recipe uses should exist in an external area. The following example creates and adds a new recipe named ``jackson`` to a workspace layer the tool creates. The source code built by the recipes -resides in ``/home/user/sources/jackson``: $ devtool add jackson -/home/user/sources/jackson +resides in ``/home/user/sources/jackson``: +:: + + $ devtool add jackson /home/user/sources/jackson If you add a recipe and the workspace layer does not exist, the command creates the layer and populates it as described in "`The Workspace Layer @@ -145,35 +192,38 @@ external source tree. that these packages exist on the target hardware before attempting to run your application. If dependent packages (e.g. libraries) do not exist on the target, your application, when run, will fail to find - those functions. For more information, see the " - Deploying Your Software on the Target Machine - " section. + those functions. For more information, see the + ":ref:`ref-manual/ref-devtool-reference:deploying your software on the target machine`" + section. By default, ``devtool add`` uses the latest revision (i.e. master) when unpacking files from a remote URI. In some cases, you might want to specify a source revision by branch, tag, or commit hash. You can specify these options when using the ``devtool add`` command: -- To specify a source branch, use the ``--srcbranch`` option: $ devtool - add --srcbranch DISTRO_NAME_NO_CAP jackson /home/user/sources/jackson +- To specify a source branch, use the ``--srcbranch`` option: + :: + + $ devtool add --srcbranch DISTRO_NAME_NO_CAP jackson /home/user/sources/jackson + In the previous example, you are checking out the DISTRO_NAME_NO_CAP branch. - To specify a specific tag or commit hash, use the ``--srcrev`` - option: $ devtool add --srcrev DISTRO_REL_TAG jackson - /home/user/sources/jackson $ devtool add --srcrev some_commit_hash - /home/user/sources/jackson The previous examples check out the + option: + :: + + $ devtool add --srcrev DISTRO_REL_TAG jackson /home/user/sources/jackson + $ devtool add --srcrev some_commit_hash /home/user/sources/jackson + + The previous examples check out the DISTRO_REL_TAG tag and the commit associated with the some_commit_hash hash. .. note:: If you prefer to use the latest revision every time the recipe is - built, use the options - --autorev - or - -a - . + built, use the options --autorev or -a. .. _devtool-extracting-the-source-for-an-existing-recipe: @@ -219,8 +269,12 @@ The ``devtool modify`` command extracts the source for a recipe, sets it up as a Git repository if the source had not already been fetched from Git, checks out a branch for development, and applies any patches from the recipe as commits on top. You can use the following command to -checkout the source files: $ devtool modify recipe Using the above -command form, ``devtool`` uses the existing recipe's +checkout the source files: +:: + + $ devtool modify recipe + +Using the above command form, ``devtool`` uses the existing recipe's :term:`SRC_URI` statement to locate the upstream source, extracts the source into the default sources location in the workspace. The default development branch used is "devtool". @@ -255,16 +309,24 @@ compile, and test the code. When you are satisfied with the results and you have committed your changes to the Git repository, you can then run the -``devtool update-recipe`` to create the patches and update the recipe: $ -devtool update-recipe recipe If you run the ``devtool update-recipe`` +``devtool update-recipe`` to create the patches and update the recipe: +:: + + $ devtool update-recipe recipe + +If you run the ``devtool update-recipe`` without committing your changes, the command ignores the changes. Often, you might want to apply customizations made to your software in your own layer rather than apply them to the original recipe. If so, you can use the ``-a`` or ``--append`` option with the ``devtool update-recipe`` command. These options allow you to specify -the layer into which to write an append file: $ devtool update-recipe -recipe -a base-layer-directory The ``*.bbappend`` file is created at the +the layer into which to write an append file: +:: + + $ devtool update-recipe recipe -a base-layer-directory + +The ``*.bbappend`` file is created at the appropriate path within the specified layer directory, which may or may not be in your ``bblayers.conf`` file. If an append file already exists, the command updates it appropriately. @@ -287,7 +349,7 @@ particular recipe. .. note:: - For the ``oe-core`` layer, recipe maintainers come from the - ```maintainers.inc`http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/maintainers.inc + `maintainers.inc `_ file. - If the recipe is using the :ref:`bitbake:git-fetcher` @@ -296,14 +358,21 @@ particular recipe. recipe's latest version tag. As with all ``devtool`` commands, you can get help on the individual -command: $ devtool check-upgrade-status -h NOTE: Starting bitbake -server... usage: devtool check-upgrade-status [-h] [--all] [recipe -[recipe ...]] Prints a table of recipes together with versions currently -provided by recipes, and latest upstream versions, when there is a later -version available arguments: recipe Name of the recipe to report (omit -to report upgrade info for all recipes) options: -h, --help show this -help message and exit --all, -a Show all recipes, not just recipes -needing upgrade +command: +:: + + $ devtool check-upgrade-status -h + NOTE: Starting bitbake server... + usage: devtool check-upgrade-status [-h] [--all] [recipe [recipe ...]] + + Prints a table of recipes together with versions currently provided by recipes, and latest upstream versions, when there is a later version available + + arguments: + recipe Name of the recipe to report (omit to report upgrade info for all recipes) + + options: + -h, --help show this help message and exit + --all, -a Show all recipes, not just recipes needing upgrade Unless you provide a specific recipe name on the command line, the command checks all recipes in all configured layers. @@ -317,21 +386,18 @@ satisfied. .. note:: When a reason for not upgrading displays, the reason is usually - written into the recipe using the - RECIPE_NO_UPDATE_REASON - variable. See the - base-passwd.bb - recipe for an example. + written into the recipe using the RECIPE_NO_UPDATE_REASON + variable. See the base-passwd.bb recipe for an example. -$ devtool check-upgrade-status ... NOTE: acpid 2.0.30 2.0.31 Ross Burton - NOTE: u-boot-fw-utils 2018.11 2019.01 Marek -Vasut d3689267f92c5956e09cc7d1baa4700141662bff -NOTE: u-boot-tools 2018.11 2019.01 Marek Vasut -d3689267f92c5956e09cc7d1baa4700141662bff . . . NOTE: base-passwd 3.5.29 -3.5.45 Anuj Mittal cannot be updated due to: -Version 3.5.38 requires cdebconf for update-passwd utility NOTE: busybox -1.29.2 1.30.0 Andrej Valek NOTE: dbus-test -1.12.10 1.12.12 Chen Qi +:: + + $ devtool check-upgrade-status ... + NOTE: acpid 2.0.30 2.0.31 Ross Burton + NOTE: u-boot-fw-utils 2018.11 2019.01 Marek Vasut d3689267f92c5956e09cc7d1baa4700141662bff + NOTE: u-boot-tools 2018.11 2019.01 Marek Vasut d3689267f92c5956e09cc7d1baa4700141662bff . . . + NOTE: base-passwd 3.5.29 3.5.45 Anuj Mittal cannot be updated due to: Version 3.5.38 requires cdebconf for update-passwd utility + NOTE: busybox 1.29.2 1.30.0 Andrej Valek + NOTE: dbus-test 1.12.10 1.12.12 Chen Qi .. _devtool-upgrading-a-recipe: @@ -341,17 +407,13 @@ Upgrading a Recipe As software matures, upstream recipes are upgraded to newer versions. As a developer, you need to keep your local recipes up-to-date with the upstream version releases. Several methods exist by which you can -upgrade recipes. You can read about them in the "`Upgrading -Recipes <&YOCTO_DOCS_DEV_URL;#gs-upgrading-recipes>`__" section of the -Yocto Project Development Tasks Manual. This section overviews the -``devtool upgrade`` command. +upgrade recipes. You can read about them in the ":ref:`gs-upgrading-recipes`" +section of the Yocto Project Development Tasks Manual. This section +overviews the ``devtool upgrade`` command. -.. note:: - - Before you upgrade a recipe, you can check on its upgrade status. See - the " - Checking on the Upgrade Status of a Recipe - " for more information. +Before you upgrade a recipe, you can check on its upgrade status. See +the ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`" section +for more information. The ``devtool upgrade`` command upgrades an existing recipe to a more recent version of the recipe upstream. The command puts the upgraded @@ -369,14 +431,11 @@ revision to which you want to upgrade (i.e. the :term:`SRCREV`), whether or not to apply patches, and so forth. -You can read more on the ``devtool upgrade`` workflow in the "`Use -``devtool upgrade`` to Create a Version of the Recipe that Supports a -Newer Version of the -Software <&YOCTO_DOCS_SDK_URL;#sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software>`__" +You can read more on the ``devtool upgrade`` workflow in the +":ref:`sdk-devtool-use-devtool-upgrade-to-create-a-version-of-the-recipe-that-supports-a-newer-version-of-the-software`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. You can also see an example of -how to use ``devtool upgrade`` in the "`Using -``devtool upgrade`` <&YOCTO_DOCS_DEV_URL;#gs-using-devtool-upgrade>`__" +how to use ``devtool upgrade`` in the ":ref:`gs-using-devtool-upgrade`" section in the Yocto Project Development Tasks Manual. .. _devtool-resetting-a-recipe: @@ -397,10 +456,13 @@ files have been modified, the command preserves the modified files in a separate "attic" subdirectory under the workspace layer. Here is an example that resets the workspace directory that contains the -``mtr`` recipe: $ devtool reset mtr NOTE: Cleaning sysroot for recipe -mtr... NOTE: Leaving source tree -/home/scottrif/poky/build/workspace/sources/mtr as-is; if you no longer -need it then please delete it manually $ +``mtr`` recipe: +:: + + $ devtool reset mtr + NOTE: Cleaning sysroot for recipe mtr... + NOTE: Leaving source tree /home/scottrif/poky/build/workspace/sources/mtr as-is; if you no longer need it then please delete it manually + $ .. _devtool-building-your-recipe: @@ -414,8 +476,10 @@ Use the ``devtool build`` command to build your recipe. The When you use the ``devtool build`` command, you must supply the root name of the recipe (i.e. do not provide versions, paths, or extensions). You can use either the "-s" or the "--disable-parallel-make" options to -disable parallel makes during the build. Here is an example: $ devtool -build recipe +disable parallel makes during the build. Here is an example: +:: + + $ devtool build recipe .. _devtool-building-your-image: @@ -429,8 +493,10 @@ device for testing. For proper integration into a final image, you need to edit your custom image recipe appropriately. When you use the ``devtool build-image`` command, you must supply the -name of the image. This command has no command line options: $ devtool -build-image image +name of the image. This command has no command line options: +:: + + $ devtool build-image image .. _devtool-deploying-your-software-on-the-target-machine: @@ -438,7 +504,11 @@ Deploying Your Software on the Target Machine ============================================= Use the ``devtool deploy-target`` command to deploy the recipe's build -output to the live target machine: $ devtool deploy-target recipe target +output to the live target machine: +:: + + $ devtool deploy-target recipe target + The target is the address of the target machine, which must be running an SSH server (i.e. ``user@hostname[:destdir]``). @@ -485,8 +555,13 @@ Removing Your Software from the Target Machine Use the ``devtool undeploy-target`` command to remove deployed build output from the target machine. For the ``devtool undeploy-target`` command to work, you must have previously used the -```devtool deploy-target`` <#devtool-deploying-your-software-on-the-target-machine>`__ -command. $ devtool undeploy-target recipe target The target is the +":ref:`devtool deploy-target `" +command. +:: + + $ devtool undeploy-target recipe target + +The target is the address of the target machine, which must be running an SSH server (i.e. ``user@hostname``). @@ -501,12 +576,17 @@ new workspace layer, it is populated with the ``README`` file and the ``conf`` directory only. The following example creates a new workspace layer in your current -working and by default names the workspace layer "workspace": $ devtool -create-workspace +working and by default names the workspace layer "workspace": +:: + + $ devtool create-workspace You can create a workspace layer anywhere by supplying a pathname with the command. The following command creates a new workspace layer named -"new-workspace": $ devtool create-workspace /home/scottrif/new-workspace +"new-workspace": +:: + + $ devtool create-workspace /home/scottrif/new-workspace .. _devtool-get-the-status-of-the-recipes-in-your-workspace: @@ -517,13 +597,19 @@ Use the ``devtool status`` command to list the recipes currently in your workspace. Information includes the paths to their respective external source trees. -The ``devtool status`` command has no command-line options: $ devtool -status Following is sample output after using -```devtool add`` <#devtool-adding-a-new-recipe-to-the-workspace>`__ to -create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` -directory: $ devtool status mtr: -/home/scottrif/poky/build/workspace/sources/mtr -(/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb) $ +The ``devtool status`` command has no command-line options: +:: + + $ devtool status + +Following is sample output after using +:ref:`devtool add ` +to create and add the ``mtr_0.86.bb`` recipe to the ``workspace`` directory: +:: + + $ devtool status mtr + :/home/scottrif/poky/build/workspace/sources/mtr (/home/scottrif/poky/build/workspace/recipes/mtr/mtr_0.86.bb) + $ .. _devtool-search-for-available-target-recipes: diff --git a/documentation/ref-manual/ref-features.rst b/documentation/ref-manual/ref-features.rst index 0e901edaeb..ae5a0e3b24 100644 --- a/documentation/ref-manual/ref-features.rst +++ b/documentation/ref-manual/ref-features.rst @@ -26,8 +26,11 @@ One method you can use to determine which recipes are checking to see if a particular feature is contained or not is to ``grep`` through the :term:`Metadata` for the feature. Here is an example that discovers the recipes whose build is potentially changed based on a -given feature: $ cd poky $ git grep -'contains.*MACHINE_FEATURES.*feature' +given feature: +:: + + $ cd poky + $ git grep 'contains.*MACHINE_FEATURES.*feature' .. _ref-features-machine: @@ -115,8 +118,7 @@ metadata: - *api-documentation:* Enables generation of API documentation during recipe builds. The resulting documentation is added to SDK tarballs when the ``bitbake -c populate_sdk`` command is used. See the - "`Adding API Documentation to the Standard - SDK <&YOCTO_DOCS_SDK_URL;#adding-api-documentation-to-the-standard-sdk>`__" + ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding api documentation to the standard sdk`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. @@ -154,8 +156,7 @@ metadata: - *ptest:* Enables building the package tests where supported by individual recipes. For more information on package tests, see the - "`Testing Packages With - ptest <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__" section + ":ref:`dev-manual/dev-manual-common-tasks:testing packages with ptest`" section in the Yocto Project Development Tasks Manual. - *smbfs:* Include SMB networks client support (for mounting @@ -237,8 +238,8 @@ The following image features are available for all images: - *ptest-pkgs:* Installs ptest packages for all ptest-enabled recipes. - *read-only-rootfs:* Creates an image whose root filesystem is - read-only. See the "`Creating a Read-Only Root - Filesystem <&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem>`__" + read-only. See the + ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`" section in the Yocto Project Development Tasks Manual for more information. @@ -263,8 +264,7 @@ these valid features is as follows: - *perf:* Installs profiling tools such as ``perf``, ``systemtap``, and ``LTTng``. For general information on user-space tools, see the - `Yocto Project Application Development and the Extensible Software - Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual. + :doc:`../sdk-manual/sdk-manual` manual. - *ssh-server-dropbear:* Installs the Dropbear minimal SSH server. @@ -275,12 +275,10 @@ these valid features is as follows: will not be installed. - *tools-debug:* Installs debugging tools such as ``strace`` and - ``gdb``. For information on GDB, see the "`Debugging With the GNU - Project Debugger (GDB) - Remotely <&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug>`__" section + ``gdb``. For information on GDB, see the + ":ref:`platdev-gdb-remotedebug`" section in the Yocto Project Development Tasks Manual. For information on - tracing and profiling, see the `Yocto Project Profiling and Tracing - Manual <&YOCTO_DOCS_PROF_URL;>`__. + tracing and profiling, see the :doc:`../profile-manual/profile-manual`. - *tools-sdk:* Installs a full SDK that runs on the device. diff --git a/documentation/ref-manual/ref-images.rst b/documentation/ref-manual/ref-images.rst index 0e26e57155..47beda0c23 100644 --- a/documentation/ref-manual/ref-images.rst +++ b/documentation/ref-manual/ref-images.rst @@ -24,12 +24,13 @@ image you want. 1. Comment out the EXTRA_IMAGE_FEATURES line 2. Set INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0" - + From within the ``poky`` Git repository, you can use the following command to display the list of directories within the :term:`Source Directory` -that contain image recipe files: $ ls -meta*/recipes*/images/*.bb +that contain image recipe files: :: + + $ ls meta*/recipes*/images/*.bb Following is a list of supported recipes: @@ -121,9 +122,8 @@ Following is a list of supported recipes: automated runtime testing. Provides a "known good" image that is deployed to a separate partition so that you can boot into it and use it to deploy a second image to be tested. You can find more - information about runtime testing in the "`Performing Automated - Runtime - Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" + information about runtime testing in the + ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" section in the Yocto Project Development Tasks Manual. - ``core-image-testmaster-initramfs``: A RAM-based Initial Root @@ -132,8 +132,8 @@ Following is a list of supported recipes: - ``core-image-weston``: A very basic Wayland image with a terminal. This image provides the Wayland protocol libraries and the reference - Weston compositor. For more information, see the "`Using Wayland and - Weston <&YOCTO_DOCS_DEV_URL;#dev-using-wayland-and-weston>`__" + Weston compositor. For more information, see the + ":ref:`dev-manual/dev-manual-common-tasks:using wayland and weston`" section in the Yocto Project Development Tasks Manual. - ``core-image-x11``: A very basic X11 image with a terminal. diff --git a/documentation/ref-manual/ref-kickstart.rst b/documentation/ref-manual/ref-kickstart.rst index 271e6e8509..45222de05b 100644 --- a/documentation/ref-manual/ref-kickstart.rst +++ b/documentation/ref-manual/ref-kickstart.rst @@ -30,7 +30,13 @@ Command: part or partition ========================== Either of these commands creates a partition on the system and uses the -following syntax: part [mntpoint] partition [mntpoint] If you do not +following syntax: +:: + + part [mntpoint] + partition [mntpoint] + +If you do not provide mntpoint, Wic creates a partition but does not mount it. The ``mntpoint`` is where the partition is mounted and must be in one of @@ -62,20 +68,19 @@ Here is an example that uses "/" as the mountpoint. The command uses Here is a list that describes other supported options you can use with the ``part`` and ``partition`` commands: -- *``--size``:* The minimum partition size in MBytes. Specify an +- ``--size``: The minimum partition size in MBytes. Specify an integer value such as 500. Do not append the number with "MB". You do not need this option if you use ``--source``. -- *``--fixed-size``:* The exact partition size in MBytes. You cannot +- ``--fixed-size``: The exact partition size in MBytes. You cannot specify with ``--size``. An error occurs when assembling the disk image if the partition data is larger than ``--fixed-size``. -- *``--source``:* This option is a Wic-specific option that names the +- ``--source``: This option is a Wic-specific option that names the source of the data that populates the partition. The most common value for this option is "rootfs", but you can use any value that maps to a valid source plugin. For information on the source plugins, - see the "`Using the Wic Plugins - Interface <&YOCTO_DOCS_DEV_URL;#wic-using-the-wic-plugin-interface>`__" + see the ":ref:`dev-manual/dev-manual-common-tasks:using the wic plugin interface`" section in the Yocto Project Development Tasks Manual. If you use ``--source rootfs``, Wic creates a partition as large as @@ -98,10 +103,10 @@ the ``part`` and ``partition`` commands: creates an empty partition. Consequently, you must use the ``--size`` option to specify the size of the empty partition. -- *``--ondisk`` or ``--ondrive``:* Forces the partition to be created +- ``--ondisk`` or ``--ondrive``: Forces the partition to be created on a particular disk. -- *``--fstype``:* Sets the file system type for the partition. Valid +- ``--fstype``: Sets the file system type for the partition. Valid values are: - ``ext4`` @@ -116,66 +121,66 @@ the ``part`` and ``partition`` commands: - ``swap`` -- *``--fsoptions``:* Specifies a free-form string of options to be used +- ``--fsoptions``: Specifies a free-form string of options to be used when mounting the filesystem. This string is copied into the ``/etc/fstab`` file of the installed system and should be enclosed in quotes. If not specified, the default string is "defaults". -- *``--label label``:* Specifies the label to give to the filesystem to +- ``--label label``: Specifies the label to give to the filesystem to be made on the partition. If the given label is already in use by another filesystem, a new label is created for the partition. -- *``--active``:* Marks the partition as active. +- ``--active``: Marks the partition as active. -- *``--align (in KBytes)``:* This option is a Wic-specific option that +- ``--align (in KBytes)``: This option is a Wic-specific option that says to start partitions on boundaries given x KBytes. -- *``--no-table``:* This option is a Wic-specific option. Using the +- ``--no-table``: This option is a Wic-specific option. Using the option reserves space for the partition and causes it to become populated. However, the partition is not added to the partition table. -- *``--exclude-path``:* This option is a Wic-specific option that +- ``--exclude-path``: This option is a Wic-specific option that excludes the given relative path from the resulting image. This option is only effective with the rootfs source plugin. -- *``--extra-space``:* This option is a Wic-specific option that adds +- ``--extra-space``: This option is a Wic-specific option that adds extra space after the space filled by the content of the partition. The final size can exceed the size specified by the ``--size`` option. The default value is 10 Mbytes. -- *``--overhead-factor``:* This option is a Wic-specific option that +- ``--overhead-factor``: This option is a Wic-specific option that multiplies the size of the partition by the option's value. You must supply a value greater than or equal to "1". The default value is "1.3". -- *``--part-name``:* This option is a Wic-specific option that +- ``--part-name``: This option is a Wic-specific option that specifies a name for GPT partitions. -- *``--part-type``:* This option is a Wic-specific option that +- ``--part-type``: This option is a Wic-specific option that specifies the partition type globally unique identifier (GUID) for GPT partitions. You can find the list of partition type GUIDs at http://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs. -- *``--use-uuid``:* This option is a Wic-specific option that causes +- ``--use-uuid``: This option is a Wic-specific option that causes Wic to generate a random GUID for the partition. The generated identifier is used in the bootloader configuration to specify the root partition. -- *``--uuid``:* This option is a Wic-specific option that specifies the +- ``--uuid``: This option is a Wic-specific option that specifies the partition UUID. -- *``--fsuuid``:* This option is a Wic-specific option that specifies +- ``--fsuuid``: This option is a Wic-specific option that specifies the filesystem UUID. You can generate or modify :term:`WKS_FILE` with this option if a preconfigured filesystem UUID is added to the kernel command line in the bootloader configuration before you run Wic. -- *``--system-id``:* This option is a Wic-specific option that +- ``--system-id``: This option is a Wic-specific option that specifies the partition system ID, which is a one byte long, hexadecimal parameter with or without the 0x prefix. -- *``--mkfs-extraopts``:* This option specifies additional options to +- ``--mkfs-extraopts``: This option specifies additional options to pass to the ``mkfs`` utility. Some default options for certain filesystems do not take effect. See Wic's help on kickstart (i.e. ``wic help kickstart``). @@ -195,13 +200,13 @@ supports the following options: command essentially provides a means of modifying bootloader configuration. -- *``--timeout``:* Specifies the number of seconds before the +- ``--timeout``: Specifies the number of seconds before the bootloader times out and boots the default option. -- *``--append``:* Specifies kernel parameters. These parameters will be +- ``--append``: Specifies kernel parameters. These parameters will be added to the syslinux ``APPEND`` or ``grub`` kernel command line. -- *``--configfile``:* Specifies a user-defined configuration file for +- ``--configfile``: Specifies a user-defined configuration file for the bootloader. You can provide a full pathname for the file or a file that exists in the ``canned-wks`` folder. This option overrides all other bootloader options. diff --git a/documentation/ref-manual/ref-qa-checks.rst b/documentation/ref-manual/ref-qa-checks.rst index a56de690b1..3e76ac1509 100644 --- a/documentation/ref-manual/ref-qa-checks.rst +++ b/documentation/ref-manual/ref-qa-checks.rst @@ -209,7 +209,10 @@ Errors and Warnings Typically, the way to solve this performance issue is to add "-fPIC" or "-fpic" to the compiler command-line options. For example, given software that reads :term:`CFLAGS` when you build it, - you could add the following to your recipe: CFLAGS_append = " -fPIC " + you could add the following to your recipe: + :: + + CFLAGS_append = " -fPIC " For more information on text relocations at runtime, see http://www.akkadia.org/drepper/textrelocs.html. @@ -224,7 +227,10 @@ Errors and Warnings variable is being passed to the linker command. A common workaround for this situation is to pass in ``LDFLAGS`` using :term:`TARGET_CC_ARCH` within the recipe as - follows: TARGET_CC_ARCH += "${LDFLAGS}" + follows: + :: + + TARGET_CC_ARCH += "${LDFLAGS}"   @@ -244,10 +250,11 @@ Errors and Warnings The ``/usr/share/info/dir`` should not be packaged. Add the following line to your :ref:`ref-tasks-install` task or to your - ``do_install_append`` within the recipe as follows: rm - ${D}${infodir}/dir + ``do_install_append`` within the recipe as follows: + :: -   + rm ${D}${infodir}/dir +   - ``Symlink in points to TMPDIR [symlink-to-sysroot]`` diff --git a/documentation/ref-manual/ref-release-process.rst b/documentation/ref-manual/ref-release-process.rst index 7b33c0ae6b..be041e7254 100644 --- a/documentation/ref-manual/ref-release-process.rst +++ b/documentation/ref-manual/ref-release-process.rst @@ -17,8 +17,13 @@ month cadence roughly timed each April and October of the year. Following are examples of some major YP releases with their codenames also shown. See the "`Major Release Codenames <#major-release-codenames>`__" section for information on -codenames used with major releases. 2.2 (Morty) 2.1 (Krogoth) 2.0 -(Jethro) While the cadence is never perfect, this timescale facilitates +codenames used with major releases. + + - 2.2 (Morty) + - 2.1 (Krogoth) + - 2.0 (Jethro) + +While the cadence is never perfect, this timescale facilitates regular releases that have strong QA cycles while not overwhelming users with too many new releases. The cadence is predictable and avoids many major holidays in various geographies. @@ -26,7 +31,13 @@ major holidays in various geographies. The Yocto project delivers minor (point) releases on an unscheduled basis and are usually driven by the accumulation of enough significant fixes or enhancements to the associated major release. Following are -some example past point releases: 2.1.1 2.1.2 2.2.1 The point release +some example past point releases: + + - 2.1.1 + - 2.1.2 + - 2.2.1 + +The point release indicates a point in the major release branch where a full QA cycle and release process validates the content of the new branch. @@ -39,9 +50,8 @@ Major Release Codenames ======================= Each major release receives a codename that identifies the release in -the `Yocto Project Source -Repositories <&YOCTO_DOCS_OM_URL;#yocto-project-repositories>`__. The -concept is that branches of :term:`Metadata` with the same +the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`. +The concept is that branches of :term:`Metadata` with the same codename are likely to be compatible and thus work together. .. note:: @@ -95,9 +105,8 @@ provide the Yocto Project team a way to ensure a release is validated. Additionally, because the test strategies are visible to you as a developer, you can validate your projects. This section overviews the available test infrastructure used in the Yocto Project. For information -on how to run available tests on your projects, see the "`Performing -Automated Runtime -Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" +on how to run available tests on your projects, see the +":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" section in the Yocto Project Development Tasks Manual. The QA/testing infrastructure is woven into the project to the point @@ -119,12 +128,12 @@ consists of the following pieces: - :ref:`testimage.bbclass `: This class performs runtime testing of images after they are built. The tests - are usually used with `QEMU <&YOCTO_DOCS_DEV_URL;#dev-manual-qemu>`__ + are usually used with :doc:`QEMU <../dev-manual/dev-manual-qemu>` to boot the images and check the combined runtime result boot operation and functions. However, the test can also use the IP address of a machine to test. -- ```ptest`` <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__: +- :ref:`ptest `: Runs tests against packages produced during the build for a given piece of software. The test allows the packages to be be run within a target image. @@ -147,7 +156,7 @@ effort has been made to automate the tests so that more people can use them and the Yocto Project development team can run them faster and more efficiently. -The Yocto Project's main Autobuilder (``autobuilder.yoctoproject.org``) +The Yocto Project's main Autobuilder (https://autobuilder.yoctoproject.org/) publicly tests each Yocto Project release's code in the :term:`OpenEmbedded-Core (OE-Core)`, Poky, and BitBake repositories. The testing occurs for both the current state of the "master" branch and also for diff --git a/documentation/ref-manual/ref-structure.rst b/documentation/ref-manual/ref-structure.rst index 1efb81414f..48a443331b 100644 --- a/documentation/ref-manual/ref-structure.rst +++ b/documentation/ref-manual/ref-structure.rst @@ -11,8 +11,8 @@ describes the Source Directory and gives information about those files and directories. For information on how to establish a local Source Directory on your -development system, see the "`Locating Yocto Project Source -Files <&YOCTO_DOCS_DEV_URL;#locating-yocto-project-source-files>`__" +development system, see the +":ref:`dev-manual/dev-manual-start:locating yocto project source files`" section in the Yocto Project Development Tasks Manual. .. note:: @@ -42,7 +42,7 @@ itself; consequently, most users do not need to worry about BitBake. When you run the ``bitbake`` command, the main BitBake executable (which resides in the ``bitbake/bin/`` directory) starts. Sourcing the -environment setup script (i.e. ````` <#structure-core-script>`__) places +environment setup script (i.e. :ref:`structure-core-script`) places the ``scripts/`` and ``bitbake/bin/`` directories (in that order) into the shell's ``PATH`` environment variable. @@ -59,14 +59,14 @@ generated by the OpenEmbedded build system in its standard configuration where the source tree is combined with the output. The :term:`Build Directory` is created initially when you ``source`` the OpenEmbedded build environment setup script (i.e. -````` <#structure-core-script>`__). +:ref:`structure-core-script`). It is also possible to place output and configuration files in a directory separate from the :term:`Source Directory` by providing a directory name when you ``source`` the setup script. For information on separating output from your local Source Directory files (commonly described as an "out of tree" build), see the -"````` <#structure-core-script>`__" section. +":ref:`structure-core-script`" section. .. _handbook: @@ -103,9 +103,8 @@ metadata to define the Poky reference distribution. ------------------- This directory contains the Yocto Project reference hardware Board -Support Packages (BSPs). For more information on BSPs, see the `Yocto -Project Board Support Package (BSP) Developer's -Guide <&YOCTO_DOCS_BSP_URL;>`__. +Support Packages (BSPs). For more information on BSPs, see the +:doc:`../bsp-guide/bsp-guide`. .. _structure-meta-selftest: @@ -131,7 +130,7 @@ This directory contains template recipes for BSP and kernel development. This directory contains various integration scripts that implement extra functionality in the Yocto Project environment (e.g. QEMU scripts). The -````` <#structure-core-script>`__ script prepends this directory to the +:ref:`structure-core-script` script prepends this directory to the shell's ``PATH`` environment variable. The ``scripts`` directory has useful scripts that assist in contributing @@ -154,18 +153,30 @@ When you run this script, your Yocto Project environment is set up, a :term:`Build Directory` is created, your working directory becomes the Build Directory, and you are presented with some simple suggestions as to what to do next, including a list of some -possible targets to build. Here is an example: $ source -oe-init-build-env ### Shell environment set up for builds. ### You can -now run 'bitbake ' Common targets are: core-image-minimal -core-image-sato meta-toolchain meta-ide-support You can also run -generated qemu images with a command like 'runqemu qemux86-64' The -default output of the ``oe-init-build-env`` script is from the +possible targets to build. Here is an example: +:: + + $ source oe-init-build-env + + ### Shell environment set up for builds. ### + + You can now run 'bitbake ' + + Common targets are: + core-image-minimal + core-image-sato + meta-toolchain + meta-ide-support + + You can also run generated qemu images with a command like 'runqemu qemux86-64' + +The default output of the ``oe-init-build-env`` script is from the ``conf-notes.txt`` file, which is found in the ``meta-poky`` directory within the :term:`Source Directory`. If you design a custom distribution, you can include your own version of this configuration file to mention the targets defined by your distribution. -See the "`Creating a Custom Template Configuration -Directory <&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory>`__" +See the +":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`" section in the Yocto Project Development Tasks Manual for more information. @@ -175,11 +186,14 @@ you provide a Build Directory argument when you ``source`` the script, you direct the OpenEmbedded build system to create a Build Directory of your choice. For example, the following command creates a Build Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`: -$ source OE_INIT_FILE ~/mybuilds The -OpenEmbedded build system uses the template configuration files, which +:: + + $ source OE_INIT_FILE ~/mybuilds + +The OpenEmbedded build system uses the template configuration files, which are found by default in the ``meta-poky/conf/`` directory in the Source -Directory. See the "`Creating a Custom Template Configuration -Directory <&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory>`__" +Directory. See the +":ref:`dev-manual/dev-manual-common-tasks:creating a custom template configuration directory`" section in the Yocto Project Development Tasks Manual for more information. @@ -207,7 +221,7 @@ The Build Directory - ``build/`` The OpenEmbedded build system creates the :term:`Build Directory` when you run the build environment setup -script ````` <#structure-core-script>`__. If you do not give the Build +script :ref:`structure-core-script`. If you do not give the Build Directory a specific name when you run the setup script, the name defaults to ``build/``. @@ -223,8 +237,7 @@ The OpenEmbedded build system creates this directory when you enable build history via the ``buildhistory`` class file. The directory organizes build information into image, packages, and SDK subdirectories. For information on the build history feature, see the -"`Maintaining Build Output -Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__" +":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`" section in the Yocto Project Development Tasks Manual. .. _structure-build-conf-local.conf: @@ -248,7 +261,7 @@ which you want to access downloaded files (``DL_DIR``). If ``local.conf`` is not present when you start the build, the OpenEmbedded build system creates it from ``local.conf.sample`` when you ``source`` the top-level build environment setup script -````` <#structure-core-script>`__. +:ref:`structure-core-script`. The source ``local.conf.sample`` file used depends on the ``$TEMPLATECONF`` script variable, which defaults to ``meta-poky/conf/`` @@ -258,7 +271,11 @@ environment. Because the script variable points to the source of the ``local.conf.sample`` file, this implies that you can configure your build environment from any layer by setting the variable in the top-level build environment setup script as follows: -TEMPLATECONF=your_layer/conf Once the build process gets the sample +:: + + TEMPLATECONF=your_layer/conf + +Once the build process gets the sample file, it uses ``sed`` to substitute final ``${``\ :term:`OEROOT`\ ``}`` values for all ``##OEROOT##`` values. @@ -283,7 +300,7 @@ file, it uses ``sed`` to substitute final ---------------------------- This configuration file defines -`layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__, +:ref:`layers `, which are directory trees, traversed (or walked) by BitBake. The ``bblayers.conf`` file uses the :term:`BBLAYERS` variable to list the layers BitBake tries to find. @@ -291,7 +308,7 @@ variable to list the layers BitBake tries to find. If ``bblayers.conf`` is not present when you start the build, the OpenEmbedded build system creates it from ``bblayers.conf.sample`` when you ``source`` the top-level build environment setup script (i.e. -````` <#structure-core-script>`__). +:ref:`structure-core-script`). As with the ``local.conf`` file, the source ``bblayers.conf.sample`` file used depends on the ``$TEMPLATECONF`` script variable, which @@ -301,10 +318,12 @@ building from the OpenEmbedded-Core environment. Because the script variable points to the source of the ``bblayers.conf.sample`` file, this implies that you can base your build from any layer by setting the variable in the top-level build environment setup script as follows: -TEMPLATECONF=your_layer/conf Once the build process gets the sample -file, it uses ``sed`` to substitute final -``${``\ :term:`OEROOT`\ ``}`` values for all -``##OEROOT##`` values. +:: + + TEMPLATECONF=your_layer/conf + +Once the build process gets the sample file, it uses ``sed`` to substitute final +``${``\ :term:`OEROOT`\ ``}`` values for all ``##OEROOT##`` values. .. note:: @@ -395,9 +414,8 @@ This directory contains any "end result" output from the OpenEmbedded build process. The :term:`DEPLOY_DIR` variable points to this directory. For more detail on the contents of the ``deploy`` directory, see the -"`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" and -"`Application Development -SDK <&YOCTO_DOCS_OM_URL;#sdk-dev-environment>`__" sections in the Yocto +":ref:`images-dev-environment`" and +":ref:`sdk-dev-environment`" sections in the Yocto Project Overview and Concepts Manual. .. _structure-build-tmp-deploy-deb: @@ -434,9 +452,8 @@ This directory receives package licensing information. For example, the directory contains sub-directories for ``bash``, ``busybox``, and ``glibc`` (among others) that in turn contain appropriate ``COPYING`` license files with other licensing information. For information on -licensing, see the "`Maintaining Open Source License Compliance During -Your Product's -Lifecycle <&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle>`__" +licensing, see the +":ref:`dev-manual/dev-manual-common-tasks:maintaining open source license compliance during your product's lifecycle`" section in the Yocto Project Development Tasks Manual. .. _structure-build-tmp-deploy-images: @@ -461,8 +478,11 @@ image again. If you do accidentally delete files here, you will need to force them to be re-created. In order to do that, you will need to know the target that produced them. For example, these commands rebuild and re-create -the kernel files: $ bitbake -c clean virtual/kernel $ bitbake -virtual/kernel +the kernel files: +:: + + $ bitbake -c clean virtual/kernel + $ bitbake virtual/kernel .. _structure-build-tmp-deploy-sdk: @@ -472,8 +492,7 @@ virtual/kernel The OpenEmbedded build system creates this directory to hold toolchain installer scripts which, when executed, install the sysroot that matches your target hardware. You can find out more about these installers in -the "`Building an SDK -Installer <&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer>`__" +the ":ref:`sdk-manual/sdk-appendix-obtain:building an sdk installer`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. @@ -540,8 +559,8 @@ the files in the directory are empty of data, BitBake uses the filenames and timestamps for tracking purposes. For information on how BitBake uses stamp files to determine if a task -should be rerun, see the "`Stamp Files and the Rerunning of -Tasks <&YOCTO_DOCS_OM_URL;#stamp-files-and-the-rerunning-of-tasks>`__" +should be rerun, see the +":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`" section in the Yocto Project Overview and Concepts Manual. .. _structure-build-tmp-log: @@ -573,8 +592,7 @@ built within the Yocto Project. For this package, a work directory of ``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred to as the ``WORKDIR``, is created. Within this directory, the source is unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt. -(See the "`Using Quilt in Your -Workflow <&YOCTO_DOCS_DEV_URL;#using-a-quilt-workflow>`__" section in +(See the ":ref:`using-a-quilt-workflow`" section in the Yocto Project Development Tasks Manual for more information.) Within the ``linux-qemux86-standard-build`` directory, standard Quilt directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and diff --git a/documentation/ref-manual/ref-system-requirements.rst b/documentation/ref-manual/ref-system-requirements.rst index b82bed8a76..56218e4ebb 100644 --- a/documentation/ref-manual/ref-system-requirements.rst +++ b/documentation/ref-manual/ref-system-requirements.rst @@ -14,18 +14,15 @@ descriptions, and so forth as needed during the course of using the Yocto Project. For introductory information on the Yocto Project, see the -:yocto_home:`Yocto Project Website <>` and the "`Yocto Project -Development -Environment <&YOCTO_DOCS_OM_URL;#overview-development-environment>`__" +:yocto_home:`Yocto Project Website <>` and the +":ref:`overview-manual/overview-manual-development-environment:the yocto project development environment`" chapter in the Yocto Project Overview and Concepts Manual. If you want to use the Yocto Project to quickly build an image without -having to understand concepts, work through the `Yocto Project Quick -Build <&YOCTO_DOCS_BRIEF_URL;>`__ document. You can find "how-to" -information in the `Yocto Project Development Tasks -Manual <&YOCTO_DOCS_DEV_URL;>`__. You can find Yocto Project overview -and conceptual information in the `Yocto Project Overview and Concepts -Manual <&YOCTO_DOCS_OM_URL;>`__. +having to understand concepts, work through the +:doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` document. You can find "how-to" +information in the :doc:`../dev-manual/dev-manual`. You can find Yocto Project overview +and conceptual information in the :doc:`../overview-manual/overview-manual`. .. note:: @@ -95,12 +92,11 @@ distributions: WSLv2, if you still decide to use WSL please upgrade to WSLv2. - If you encounter problems, please go to `Yocto Project - Bugzilla <&YOCTO_BUGZILLA_URL;>`__ and submit a bug. We are + Bugzilla `__ and submit a bug. We are interested in hearing about your experience. For information on how to submit a bug, see the Yocto Project :yocto_wiki:`Bugzilla wiki page ` - and the "`Submitting a Defect Against the Yocto - Project <&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project>`__" + and the ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`" section in the Yocto Project Development Tasks Manual. @@ -126,19 +122,28 @@ supported Ubuntu or Debian Linux distribution: might experience QEMU build failures due to the package installing its own custom ``/usr/include/linux/soundcard.h`` on the Debian system. If you run into this situation, either of the following - solutions exist: $ sudo apt-get build-dep qemu $ sudo apt-get - remove oss4-dev + solutions exist: + :: + + $ sudo apt-get build-dep qemu + $ sudo apt-get remove oss4-dev - For Debian-8, ``python3-git`` and ``pylint3`` are no longer - available via ``apt-get``. $ sudo pip3 install GitPython - pylint==1.9.5 + available via ``apt-get``. + :: + + $ sudo pip3 install GitPython pylint==1.9.5 - *Essentials:* Packages needed to build an image on a headless system: - $ sudo apt-get install UBUNTU_HOST_PACKAGES_ESSENTIAL + :: + + $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; - *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals: $ sudo apt-get install make - xsltproc docbook-utils fop dblatex xmlto + Yocto Project documentation manuals: + :: + + $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto Fedora Packages --------------- @@ -147,12 +152,17 @@ The following list shows the required packages by function given a supported Fedora Linux distribution: - *Essentials:* Packages needed to build an image for a headless - system: $ sudo dnf install FEDORA_HOST_PACKAGES_ESSENTIAL + system: + :: + + $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL; - *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals: $ sudo dnf install - docbook-style-dsssl docbook-style-xsl \\ docbook-dtds docbook-utils - fop libxslt dblatex xmlto + Yocto Project documentation manuals: + :: + + $ sudo dnf install docbook-style-dsssl docbook-style-xsl \ + docbook-dtds docbook-utils fop libxslt dblatex xmlto openSUSE Packages ----------------- @@ -161,7 +171,10 @@ The following list shows the required packages by function given a supported openSUSE Linux distribution: - *Essentials:* Packages needed to build an image for a headless - system: $ sudo zypper install OPENSUSE_HOST_PACKAGES_ESSENTIAL + system: + :: + + $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; - *Documentation:* Packages needed if you are going to build out the Yocto Project documentation manuals: $ sudo zypper install dblatex @@ -174,7 +187,10 @@ The following list shows the required packages by function given a supported CentOS-7 Linux distribution: - *Essentials:* Packages needed to build an image for a headless - system: $ sudo yum install CENTOS7_HOST_PACKAGES_ESSENTIAL + system: + :: + + $ sudo yum install &CENTOS7_HOST_PACKAGES_ESSENTIAL; .. note:: @@ -187,9 +203,11 @@ supported CentOS-7 Linux distribution: ``epel-release``. - *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals: $ sudo yum install - docbook-style-dsssl docbook-style-xsl \\ docbook-dtds docbook-utils - fop libxslt dblatex xmlto + Yocto Project documentation manuals: + :: + + $ sudo yum install docbook-style-dsssl docbook-style-xsl \ + docbook-dtds docbook-utils fop libxslt dblatex xmlto CentOS-8 Packages ----------------- @@ -198,7 +216,10 @@ The following list shows the required packages by function given a supported CentOS-8 Linux distribution: - *Essentials:* Packages needed to build an image for a headless - system: $ sudo dnf install CENTOS8_HOST_PACKAGES_ESSENTIAL + system: + :: + + $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL; .. note:: @@ -214,9 +235,11 @@ supported CentOS-8 Linux distribution: ``epel-release``. - *Documentation:* Packages needed if you are going to build out the - Yocto Project documentation manuals: $ sudo dnf install - docbook-style-dsssl docbook-style-xsl \\ docbook-dtds docbook-utils - fop libxslt dblatex xmlto + Yocto Project documentation manuals: + :: + + $ sudo dnf install docbook-style-dsssl docbook-style-xsl \\ + docbook-dtds docbook-utils fop libxslt dblatex xmlto Required Git, tar, Python and gcc Versions ========================================== @@ -251,10 +274,14 @@ The ``install-buildtools`` script is the easiest of the three methods by which you can get these tools. It downloads a pre-built buildtools installer and automatically installs the tools for you: -1. Execute the ``install-buildtools`` script. Here is an example: $ cd - poky $ scripts/install-buildtools --without-extended-buildtools \\ - --base-url https://downloads.yoctoproject.org/releases/yocto \\ --release yocto-DISTRO \\ - --installer-version DISTRO +1. Execute the ``install-buildtools`` script. Here is an example: + :: + + $ cd poky + $ scripts/install-buildtools --without-extended-buildtools \ + --base-url https://downloads.yoctoproject.org/releases/yocto \ + --release yocto-&DISTRO; \ + --installer-version &DISTRO; During execution, the buildtools tarball will be downloaded, the checksum of the download will be verified, the installer will be run @@ -263,17 +290,25 @@ installer and automatically installs the tools for you: To avoid the need of ``sudo`` privileges, the ``install-buildtools`` script will by default tell the installer to install in: - /path/to/poky/buildtools + :: + + /path/to/poky/buildtools If your host development system needs the additional tools provided in the ``buildtools-extended`` tarball, you can instead execute the - ``install-buildtools`` script with the default parameters: $ cd poky - $ scripts/install-buildtools + ``install-buildtools`` script with the default parameters: + :: + + $ cd poky + $ scripts/install-buildtools 2. Source the tools environment setup script by using a command like the - following: $ source - /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux Of - course, you need to supply your installation directory and be sure to + following: + :: + + $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux + + Of course, you need to supply your installation directory and be sure to use the right file (i.e. i586 or x86_64). After you have sourced the setup script, the tools are added to @@ -290,21 +325,30 @@ Downloading a Pre-Built ``buildtools`` Tarball Downloading and running a pre-built buildtools installer is the easiest of the two methods by which you can get these tools: -1. Locate and download the ``*.sh`` at - ` <&YOCTO_RELEASE_DL_URL;/buildtools/>`__. +1. Locate and download the ``*.sh`` at &YOCTO_RELEASE_DL_URL;/buildtools/ 2. Execute the installation script. Here is an example for the - traditional installer: $ sh - ~/Downloads/x86_64-buildtools-nativesdk-standalone-DISTRO.sh Here is - an example for the extended installer: $ sh - ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-DISTRO.sh + traditional installer: + :: + + $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-DISTRO.sh + + Here is an example for the extended installer: + :: + + $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-DISTRO.sh + During execution, a prompt appears that allows you to choose the installation directory. For example, you could choose the following: /home/your-username/buildtools 3. Source the tools environment setup script by using a command like the - following: $ source - /home/your_username/buildtools/environment-setup-i586-poky-linux Of + following: + :: + + $ source /home/your_username/buildtools/environment-setup-i586-poky-linux + + Of course, you need to supply your installation directory and be sure to use the right file (i.e. i585 or x86-64). @@ -330,11 +374,17 @@ installer: 1. On the machine that is able to run BitBake, be sure you have set up your build environment with the setup script - (````` <#structure-core-script>`__). + (:ref:`structure-core-script`). -2. Run the BitBake command to build the tarball: $ bitbake - buildtools-tarball or run the BitBake command to build the extended - tarball: $ bitbake buildtools-extended-tarball +2. Run the BitBake command to build the tarball: + :: + + $ bitbake buildtools-tarball + + or run the BitBake command to build the extended tarball: + :: + + $ bitbake buildtools-extended-tarball .. note:: @@ -355,18 +405,27 @@ installer: 4. On the machine that does not meet the requirements, run the ``.sh`` file to install the tools. Here is an example for the traditional - installer: $ sh - ~/Downloads/x86_64-buildtools-nativesdk-standalone-DISTRO.sh Here is - an example for the extended installer: $ sh - ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-DISTRO.sh + installer: + :: + + $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh + + Here is an example for the extended installer: + :: + + $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh + During execution, a prompt appears that allows you to choose the installation directory. For example, you could choose the following: /home/your_username/buildtools 5. Source the tools environment setup script by using a command like the - following: $ source - /home/your_username/buildtools/environment-setup-x86_64-poky-linux Of - course, you need to supply your installation directory and be sure to + following: + :: + + $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux + + Of course, you need to supply your installation directory and be sure to use the right file (i.e. i586 or x86_64). After you have sourced the setup script, the tools are added to diff --git a/documentation/ref-manual/ref-tasks.rst b/documentation/ref-manual/ref-tasks.rst index 5b0711586f..44463f2236 100644 --- a/documentation/ref-manual/ref-tasks.rst +++ b/documentation/ref-manual/ref-tasks.rst @@ -109,7 +109,7 @@ after other tasks works the same way. :: do_build[recrdeptask] += "do_deploy" - + See the " Dependencies @@ -143,8 +143,7 @@ The ``do_image`` task performs pre-processing on the image through the :term:`IMAGE_PREPROCESS_COMMAND` and dynamically generates supporting ``do_image_*`` tasks as needed. -For more information on image creation, see the "`Image -Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__" +For more information on image creation, see the ":ref:`image-generation-dev-environment`" section in the Yocto Project Overview and Concepts Manual. .. _ref-tasks-image-complete: @@ -162,8 +161,8 @@ The ``do_image_complete`` task performs post-processing on the image through the :term:`IMAGE_POSTPROCESS_COMMAND`. -For more information on image creation, see the "`Image -Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__" +For more information on image creation, see the +":ref:`image-generation-dev-environment`" section in the Yocto Project Overview and Concepts Manual. .. _ref-tasks-install: @@ -176,10 +175,9 @@ Copies files that are to be packaged into the holding area working directory set to ``${``\ :term:`B`\ ``}``, which is the compilation directory. The ``do_install`` task, as well as other tasks that either directly or indirectly depend on the installed files (e.g. -:ref:`ref-tasks-package`, -```do_package_write_*`` <#ref-tasks-package_write_deb>`__, and +:ref:`ref-tasks-package`, ``do_package_write_*``, and :ref:`ref-tasks-rootfs`), run under -`fakeroot <&YOCTO_DOCS_OM_URL;#fakeroot-and-pseudo>`__. +:ref:`fakeroot `. .. note:: @@ -187,9 +185,8 @@ that either directly or indirectly depend on the installed files (e.g. of the installed files to unintended values. Some methods of copying files, notably when using the recursive ``cp`` command, can preserve the UID and/or GID of the original file, which is usually not what - you want. The - ```host-user-contaminated`` <#insane-host-user-contaminated>`__ QA - check checks for files that probably have the wrong ownership. + you want. The ``host-user-contaminated`` QA check checks for files + that probably have the wrong ownership. Safe methods for installing files include the following: @@ -223,9 +220,8 @@ variables. The ``do_package`` task, in conjunction with the :ref:`ref-tasks-packagedata` task, also saves some important package metadata. For additional information, see the -:term:`PKGDESTWORK` variable and the "`Automatically -Added Runtime -Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__" +:term:`PKGDESTWORK` variable and the +":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`" section in the Yocto Project Overview and Concepts Manual. .. _ref-tasks-package_qa: @@ -243,8 +239,8 @@ see the :ref:`insane ` class. Creates Debian packages (i.e. ``*.deb`` files) and places them in the ``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory in -the package feeds area. For more information, see the "`Package -Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in +the package feeds area. For more information, see the +":ref:`package-feeds-dev-environment`" section in the Yocto Project Overview and Concepts Manual. .. _ref-tasks-package_write_ipk: @@ -254,8 +250,8 @@ the Yocto Project Overview and Concepts Manual. Creates IPK packages (i.e. ``*.ipk`` files) and places them in the ``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory in -the package feeds area. For more information, see the "`Package -Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in +the package feeds area. For more information, see the +":ref:`package-feeds-dev-environment`" section in the Yocto Project Overview and Concepts Manual. .. _ref-tasks-package_write_rpm: @@ -265,8 +261,8 @@ the Yocto Project Overview and Concepts Manual. Creates RPM packages (i.e. ``*.rpm`` files) and places them in the ``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory in -the package feeds area. For more information, see the "`Package -Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in +the package feeds area. For more information, see the +":ref:`package-feeds-dev-environment`" section in the Yocto Project Overview and Concepts Manual. .. _ref-tasks-package_write_tar: @@ -276,8 +272,8 @@ the Yocto Project Overview and Concepts Manual. Creates tarballs and places them in the ``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory in -the package feeds area. For more information, see the "`Package -Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section in +the package feeds area. For more information, see the +":ref:`package-feeds-dev-environment`" section in the Yocto Project Overview and Concepts Manual. .. _ref-tasks-packagedata: @@ -312,8 +308,14 @@ and kept in a subdirectory of the directory holding the recipe file. For example, consider the :yocto_git:`bluez5 ` recipe from the OE-Core layer (i.e. ``poky/meta``): -poky/meta/recipes-connectivity/bluez5 This recipe has two patch files -located here: poky/meta/recipes-connectivity/bluez5/bluez5 +:: + + poky/meta/recipes-connectivity/bluez5 + +This recipe has two patch files located here: +:: + + poky/meta/recipes-connectivity/bluez5/bluez5 In the ``bluez5`` recipe, the ``SRC_URI`` statements point to the source and patch files needed to build the package. @@ -331,23 +333,35 @@ and patch files needed to build the package. As mentioned earlier, the build system treats files whose file types are ``.patch`` and ``.diff`` as patch files. However, you can use the "apply=yes" parameter with the ``SRC_URI`` statement to indicate any -file as a patch file: SRC_URI = " \\ git://path_to_repo/some_package \\ -file://file;apply=yes \\ " +file as a patch file: +:: + + SRC_URI = " \\ + git://path_to_repo/some_package \\ + file://file;apply=yes \\ + " Conversely, if you have a directory full of patch files and you want to exclude some so that the ``do_patch`` task does not apply them during the patch phase, you can use the "apply=no" parameter with the -``SRC_URI`` statement: SRC_URI = " \\ git://path_to_repo/some_package \\ -file://path_to_lots_of_patch_files \\ -file://path_to_lots_of_patch_files/patch_file5;apply=no \\ " In the +``SRC_URI`` statement: +:: + + SRC_URI = " \ + git://path_to_repo/some_package \ + file://path_to_lots_of_patch_files \ + file://path_to_lots_of_patch_files/patch_file5;apply=no \ + " + +In the previous example, assuming all the files in the directory holding the patch files end with either ``.patch`` or ``.diff``, every file would be applied as a patch by default except for the patch_file5 patch. You can find out more about the patching process in the -"`Patching <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__" section in -the Yocto Project Overview and Concepts Manual and the "`Patching -Code <&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code>`__" section in the +":ref:`patching-dev-environment`" section in +the Yocto Project Overview and Concepts Manual and the +":ref:`new-recipe-patching-code`" section in the Yocto Project Development Tasks Manual. .. _ref-tasks-populate_lic: @@ -364,8 +378,7 @@ the image is constructed. ------------------- Creates the file and directory structure for an installable SDK. See the -"`SDK -Generation <&YOCTO_DOCS_OM_URL;#sdk-generation-dev-environment>`__" +":ref:`sdk-generation-dev-environment`" section in the Yocto Project Overview and Concepts Manual for more information. @@ -420,8 +433,7 @@ Unpacks the source code into a working directory pointed to by ``${``\ :term:`WORKDIR`\ ``}``. The :term:`S` variable also plays a role in where unpacked source files ultimately reside. For more information on how source files are unpacked, see the -"`Source -Fetching <&YOCTO_DOCS_OM_URL;#source-fetching-dev-environment>`__" +":ref:`source-fetching-dev-environment`" section in the Yocto Project Overview and Concepts Manual and also see the ``WORKDIR`` and ``S`` variable descriptions. @@ -442,16 +454,24 @@ of the recipe exists upstream and a status of not updated, updated, or unknown. To check the upstream version and status of a recipe, use the following -devtool commands: $ devtool latest-version $ devtool -check-upgrade-status See the "```devtool`` Quick -Reference <#ref-devtool-reference>`__" chapter for more information on -``devtool``. See the "`Checking on the Upgrade Status of a -Recipe <&YOCTO_DOCS_REF_URL;#devtool-checking-on-the-upgrade-status-of-a-recipe>`__" +devtool commands: +:: + + $ devtool latest-version + $ devtool check-upgrade-status + +See the ":ref:`ref-manual/ref-devtool-reference:\`\`devtool\`\` quick reference`" +chapter for more information on +``devtool``. See the ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`" section for information on checking the upgrade status of a recipe. To build the ``checkpkg`` task, use the ``bitbake`` command with the -"-c" option and task name: $ bitbake core-image-minimal -c checkpkg By -default, the results are stored in :term:`$LOG_DIR ` (e.g. +"-c" option and task name: +:: + + $ bitbake core-image-minimal -c checkpkg + +By default, the results are stored in :term:`$LOG_DIR ` (e.g. ``$BUILD_DIR/tmp/log``). .. _ref-tasks-checkuri: @@ -473,11 +493,13 @@ Removes all output files for a target from the :ref:`ref-tasks-install`, and :ref:`ref-tasks-package`). -You can run this task using BitBake as follows: $ bitbake -c clean -recipe +You can run this task using BitBake as follows: +:: + + $ bitbake -c clean recipe Running this task does not remove the -`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__ cache files. +:ref:`sstate ` cache files. Consequently, if no changes have been made and the recipe is rebuilt after cleaning, output files are simply restored from the sstate cache. If you want to remove the sstate cache files for the recipe, you need to @@ -490,14 +512,16 @@ use the :ref:`ref-tasks-cleansstate` task instead --------------- Removes all output files, shared state -(`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache, and +(:ref:`sstate `) cache, and downloaded source files for a target (i.e. the contents of :term:`DL_DIR`). Essentially, the ``do_cleanall`` task is identical to the :ref:`ref-tasks-cleansstate` task with the added removal of downloaded source files. -You can run this task using BitBake as follows: $ bitbake -c cleanall -recipe +You can run this task using BitBake as follows: +:: + + $ bitbake -c cleanall recipe Typically, you would not normally use the ``cleanall`` task. Do so only if you want to start fresh with the :ref:`ref-tasks-fetch` @@ -509,14 +533,16 @@ task. ------------------ Removes all output files and shared state -(`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) cache for a +(:ref:`sstate `) cache for a target. Essentially, the ``do_cleansstate`` task is identical to the :ref:`ref-tasks-clean` task with the added removal of -shared state (`sstate <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__) +shared state (`:ref:`sstate `) cache. -You can run this task using BitBake as follows: $ bitbake -c cleansstate -recipe +You can run this task using BitBake as follows: +:: + + $ bitbake -c cleansstate recipe When you run the ``do_cleansstate`` task, the OpenEmbedded build system no longer uses any sstate. Consequently, building the recipe from @@ -531,8 +557,8 @@ scratch is guaranteed. as follows: :: - $ bitbake -f -c do_cleansstate target - + $ bitbake -f -c do_cleansstate target + .. _ref-tasks-devpyshell: @@ -542,9 +568,7 @@ scratch is guaranteed. Starts a shell in which an interactive Python interpreter allows you to interact with the BitBake build environment. From within this shell, you can directly examine and set bits from the data store and execute -functions as if within the BitBake environment. See the "`Using a -Development Python -Shell <&YOCTO_DOCS_DEV_URL;#platdev-appdev-devpyshell>`__" section in +functions as if within the BitBake environment. See the ":ref:`platdev-appdev-devpyshell`" section in the Yocto Project Development Tasks Manual for more information about using ``devpyshell``. @@ -554,8 +578,7 @@ using ``devpyshell``. --------------- Starts a shell whose environment is set up for development, debugging, -or both. See the "`Using a Development -Shell <&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell>`__" section in the +or both. See the ":ref:`platdev-appdev-devshell`" section in the Yocto Project Development Tasks Manual for more information about using ``devshell``. @@ -571,8 +594,7 @@ Lists all defined tasks for a target. ``do_package_index`` -------------------- -Creates or updates the index in the `Package -Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__ area. +Creates or updates the index in the `:ref:`package-feeds-dev-environment` area. .. note:: @@ -615,8 +637,7 @@ has some more information about these types of images. ------------- Creates the root filesystem (file and directory structure) for an image. -See the "`Image -Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__" +See the ":ref:`image-generation-dev-environment`" section in the Yocto Project Overview and Concepts Manual for more information on how the root filesystem is created. @@ -626,9 +647,8 @@ information on how the root filesystem is created. ---------------- Boots an image and performs runtime tests within the image. For -information on automatically testing images, see the "`Performing -Automated Runtime -Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" +information on automatically testing images, see the +":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" section in the Yocto Project Development Tasks Manual. .. _ref-tasks-testimage_auto: @@ -640,9 +660,8 @@ Boots an image and performs runtime tests within the image immediately after it has been built. This task is enabled when you set :term:`TESTIMAGE_AUTO` equal to "1". -For information on automatically testing images, see the "`Performing -Automated Runtime -Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" +For information on automatically testing images, see the +":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" section in the Yocto Project Development Tasks Manual. Kernel-Related Tasks @@ -674,9 +693,13 @@ changes made by the user with other methods (i.e. using (:ref:`ref-tasks-kernel_menuconfig`). Once the file of differences is created, it can be used to create a config fragment that only contains the differences. You can invoke this task -from the command line as follows: $ bitbake linux-yocto -c diffconfig -For more information, see the "`Creating Configuration -Fragments <&YOCTO_DOCS_KERNEL_DEV_URL;#creating-config-fragments>`__" +from the command line as follows: +:: + + $ bitbake linux-yocto -c diffconfig + +For more information, see the +":ref:`kernel-dev/kernel-dev-common:creating configuration fragments`" section in the Yocto Project Linux Kernel Development Manual. .. _ref-tasks-kernel_checkout: @@ -701,9 +724,13 @@ Validates the configuration produced by the configuration does not appear in the final ``.config`` file or when you override a policy configuration in a hardware configuration fragment. You can run this task explicitly and view the output by using the -following command: $ bitbake linux-yocto -c kernel_configcheck -f For -more information, see the "`Validating -Configuration <&YOCTO_DOCS_KERNEL_DEV_URL;#validating-configuration>`__" +following command: +:: + + $ bitbake linux-yocto -c kernel_configcheck -f + +For more information, see the +":ref:`kernel-dev/kernel-dev-common:validating configuration`" section in the Yocto Project Linux Kernel Development Manual. .. _ref-tasks-kernel_configme: @@ -733,10 +760,9 @@ tool, which you then use to modify the kernel configuration. :: $ bitbake linux-yocto -c menuconfig - -See the "`Using -``menuconfig`` <&YOCTO_DOCS_KERNEL_DEV_URL;#using-menuconfig>`__" + +See the ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``" section in the Yocto Project Linux Kernel Development Manual for more information on this configuration tool. @@ -760,7 +786,7 @@ which can then be applied by subsequent tasks such as Runs ``make menuconfig`` for the kernel. For information on ``menuconfig``, see the -"`Using  ``menuconfig`` <&YOCTO_DOCS_KERNEL_DEV_URL;#using-menuconfig>`__" +":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``" section in the Yocto Project Linux Kernel Development Manual. .. _ref-tasks-savedefconfig: @@ -773,8 +799,10 @@ instead of the default defconfig. The saved defconfig contains the differences between the default defconfig and the changes made by the user using other methods (i.e. the :ref:`ref-tasks-kernel_menuconfig` task. You -can invoke the task using the following command: $ bitbake linux-yocto --c savedefconfig +can invoke the task using the following command: +:: + + $ bitbake linux-yocto -c savedefconfig .. _ref-tasks-shared_workdir: diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst index 24eff62bcd..312fc12ef0 100644 --- a/documentation/ref-manual/ref-terms.rst +++ b/documentation/ref-manual/ref-terms.rst @@ -26,7 +26,12 @@ universal, the list includes them just in case: 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 + 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 any of the following recipe names: @@ -68,11 +73,11 @@ universal, the list includes them just in case: examples assume your :term:`Source Directory` is named ``poky``: - Create the Build Directory inside your Source Directory and let - the name of the Build Directory default to ``build``: + the name of the Build Directory default to ``build``: .. code-block:: shell - $ cd $HOME/poky + $ cd $HOME/poky $ source oe-init-build-env - Create the Build Directory inside your home directory and @@ -80,18 +85,18 @@ universal, the list includes them just in case: .. code-block:: shell - $ cd $HOME + $ cd $HOME $ source poky/oe-init-build-env test-builds - Provide a directory path and specifically name the Build Directory. Any intermediate folders in the pathname must exist. This next example creates a Build Directory named ``YP-POKYVERSION`` in your home directory within the existing - directory ``mybuilds``: + directory ``mybuilds``: .. code-block:: shell - $ cd $HOME + $ cd $HOME $ source $HOME/poky/oe-init-build-env $HOME/mybuilds/YP-POKYVERSION .. note:: @@ -349,8 +354,9 @@ universal, the list includes them just in case: While it is not recommended that you use tarball expansion to set up the Source Directory, if you do, the top-level directory name of the Source Directory is derived from the Yocto Project release tarball. - For example, downloading and unpacking ```` results in a Source - Directory whose root folder is named ````. + For example, downloading and unpacking + :yocto_dl:`releases/yocto/&DISTRO_REL_TAG;/&YOCTO_POKY;.tar.bz2` + results in a Source Directory whose root folder is named ``poky``. It is important to understand the differences between the Source Directory created by unpacking a released tarball as compared to @@ -366,8 +372,8 @@ universal, the list includes them just in case: repository. For more information on concepts related to Git repositories, - branches, and tags, see the "`Repositories, Tags, and - Branches <&YOCTO_DOCS_OM_URL;#repositories-tags-and-branches>`__" + branches, and tags, see the + ":ref:`overview-manual/overview-manual-development-environment:repositories, tags, and branches`" section in the Yocto Project Overview and Concepts Manual. Task @@ -381,7 +387,7 @@ universal, the list includes them just in case: The interface enables you to configure and run your builds. Information about builds is collected and stored in a database. For information on Toaster, see the - `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__. + :doc:`../toaster-manual/toaster-manual`. Upstream A reference to source code or repositories that are not diff --git a/documentation/ref-manual/ref-variables.rst b/documentation/ref-manual/ref-variables.rst index 54a892576b..625a37c158 100644 --- a/documentation/ref-manual/ref-variables.rst +++ b/documentation/ref-manual/ref-variables.rst @@ -21,74 +21,86 @@ system and gives an overview of their function and contents. ABIEXTENSION Extension to the Application Binary Interface (ABI) field of the GNU canonical architecture name (e.g. "eabi"). - + ABI extensions are set in the machine include files. For example, the ``meta/conf/machine/include/arm/arch-arm.inc`` file sets the - following extension: ABIEXTENSION = "eabi" - + following extension: + :: + + ABIEXTENSION = "eabi" + ALLOW_EMPTY Specifies whether to produce an output package even if it is empty. By default, BitBake does not produce empty packages. This default behavior can cause issues when there is an :term:`RDEPENDS` or some other hard runtime requirement on the existence of the package. - + Like all package-controlling variables, you must always use them in - conjunction with a package name override, as in: ALLOW_EMPTY_${PN} = - "1" ALLOW_EMPTY_${PN}-dev = "1" ALLOW_EMPTY_${PN}-staticdev = "1" - + conjunction with a package name override, as in: + :: + + ALLOW_EMPTY_${PN} = "1" + ALLOW_EMPTY_${PN}-dev = "1" + ALLOW_EMPTY_${PN}-staticdev = "1" + ALTERNATIVE Lists commands in a package that need an alternative binary naming scheme. Sometimes the same command is provided in multiple packages. When this occurs, the OpenEmbedded build system needs to use the alternatives system to create a different binary naming scheme so the commands can co-exist. - + To use the variable, list out the package's commands that also exist as part of another package. For example, if the ``busybox`` package has four commands that also exist as part of another package, you - identify them as follows: ALTERNATIVE_busybox = "sh sed test bracket" + identify them as follows: + :: + + ALTERNATIVE_busybox = "sh sed test bracket" + For more information on the alternatives system, see the ":ref:`update-alternatives.bbclass `" section. - + ALTERNATIVE_LINK_NAME Used by the alternatives system to map duplicated commands to actual locations. For example, if the ``bracket`` command provided by the ``busybox`` package is duplicated through another package, you must use the ``ALTERNATIVE_LINK_NAME`` variable to specify the actual - location: ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/[" - + location: + :: + + ALTERNATIVE_LINK_NAME[bracket] = "/usr/bin/[" + In this example, the binary for the ``bracket`` command (i.e. ``[``) from the ``busybox`` package resides in ``/usr/bin/``. - + .. note:: - - If - ALTERNATIVE_LINK_NAME - is not defined, it defaults to - ${bindir}/ - name - . - + + If ALTERNATIVE_LINK_NAME is not defined, it defaults to ${bindir}/ name. + For more information on the alternatives system, see the ":ref:`update-alternatives.bbclass `" section. - + ALTERNATIVE_PRIORITY Used by the alternatives system to create default priorities for duplicated commands. You can use the variable to create a single default regardless of the command name or package, a default for specific duplicated commands regardless of the package, or a default for specific commands tied to particular packages. Here are the - available syntax forms: ALTERNATIVE_PRIORITY = "priority" - ALTERNATIVE_PRIORITY[name] = "priority" - ALTERNATIVE_PRIORITY_pkg[name] = "priority" - + available syntax forms: + :: + + ALTERNATIVE_PRIORITY = "priority" + ALTERNATIVE_PRIORITY[name] = "priority" + ALTERNATIVE_PRIORITY_pkg[name] = "priority" + For more information on the alternatives system, see the ":ref:`update-alternatives.bbclass `" section. - + ALTERNATIVE_TARGET Used by the alternatives system to create default link locations for duplicated commands. You can use the variable to create a single @@ -96,105 +108,115 @@ system and gives an overview of their function and contents. command name or package, a default for specific duplicated commands regardless of the package, or a default for specific commands tied to particular packages. Here are the available syntax forms: - ALTERNATIVE_TARGET = "target" ALTERNATIVE_TARGET[name] = "target" - ALTERNATIVE_TARGET_pkg[name] = "target" - + :: + + ALTERNATIVE_TARGET = "target" + ALTERNATIVE_TARGET[name] = "target" + ALTERNATIVE_TARGET_pkg[name] = "target" + .. note:: - + If ``ALTERNATIVE_TARGET`` is not defined, it inherits the value - from the - :term:`ALTERNATIVE_LINK_NAME` - variable. - + from the :term:`ALTERNATIVE_LINK_NAME` variable. + If ``ALTERNATIVE_LINK_NAME`` and ``ALTERNATIVE_TARGET`` are the same, the target for ``ALTERNATIVE_TARGET`` has "``.{BPN}``" appended to it. - + Finally, if the file referenced has not been renamed, the alternatives system will rename it to avoid the need to rename alternative files in the :ref:`ref-tasks-install` task while retaining support for the command if necessary. - + For more information on the alternatives system, see the ":ref:`update-alternatives.bbclass `" section. - + APPEND An override list of append strings for each target specified with :term:`LABELS`. - + See the :ref:`grub-efi ` class for more information on how this variable is used. - + AR The minimal command and arguments used to run ``ar``. - + ARCHIVER_MODE When used with the :ref:`archiver ` class, determines the type of information used to create a released archive. You can use this variable to create archives of patched source, original source, configured source, and so forth by employing the - following variable flags (varflags): ARCHIVER_MODE[src] = "original" - # Uses original (unpacked) source # files. ARCHIVER_MODE[src] = - "patched" # Uses patched source files. This is # the default. - ARCHIVER_MODE[src] = "configured" # Uses configured source files. - ARCHIVER_MODE[diff] = "1" # Uses patches between do_unpack and # - do_patch. ARCHIVER_MODE[diff-exclude] ?= "file file ..." # Lists - files and directories to # exclude from diff. ARCHIVER_MODE[dumpdata] - = "1" # Uses environment data. ARCHIVER_MODE[recipe] = "1" # Uses - recipe and include files. ARCHIVER_MODE[srpm] = "1" # Uses RPM - package files. For information on how the variable works, see the + following variable flags (varflags): + :: + + ARCHIVER_MODE[src] = "original" # Uses original (unpacked) source files. + ARCHIVER_MODE[src] = "patched" # Uses patched source files. This is the default. + ARCHIVER_MODE[src] = "configured" # Uses configured source files. + ARCHIVER_MODE[diff] = "1" # Uses patches between do_unpack and do_patch. + ARCHIVER_MODE[diff-exclude] ?= "file file ..." # Lists files and directories to exclude from diff. + ARCHIVER_MODE[dumpdata] = "1" # Uses environment data. + ARCHIVER_MODE[recipe] = "1" # Uses recipe and include files. + ARCHIVER_MODE[srpm] = "1" # Uses RPM package files. + + For information on how the variable works, see the ``meta/classes/archiver.bbclass`` file in the :term:`Source Directory`. - + AS Minimal command and arguments needed to run the assembler. - + 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, ``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``. - + ASSUME_SHLIBS Provides additional ``shlibs`` provider mapping information, which adds to or overwrites the information provided automatically by the system. Separate multiple entries using spaces. - + As an example, use the following form to add an ``shlib`` provider of shlibname in packagename with the optional version: - shlibname:packagename[_version] - + :: + + shlibname:packagename[_version] + Here is an example that adds a shared library named ``libEGL.so.1`` as being provided by the ``libegl-implementation`` package: - ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation" - + :: + + ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation" + AUTHOR The email address used to contact the original author or authors in order to send patches and forward bugs. - + AUTO_LIBNAME_PKGS When the :ref:`debian ` class is inherited, which is the default behavior, ``AUTO_LIBNAME_PKGS`` specifies which packages should be checked for libraries and renamed according to Debian library package naming. - + The default value is "${PACKAGES}", which causes the debian class to act on all packages that are explicitly generated by the recipe. - + AUTO_SYSLINUXMENU Enables creating an automatic menu for the syslinux bootloader. You must set this variable in your recipe. The :ref:`syslinux ` class checks this variable. - + AUTOREV When ``SRCREV`` is set to the value of this variable, it specifies to use the latest source revision in the repository. Here is an example: - SRCREV = "${AUTOREV}" - + :: + + SRCREV = "${AUTOREV}" + If you use the previous statement to retrieve the latest version of software, you need to be sure :term:`PV` contains ``${``\ :term:`SRCPV`\ ``}``. For example, suppose you @@ -203,19 +225,18 @@ system and gives an overview of their function and contents. statement. In this example, ``${SRCPV}`` does not automatically get into ``PV``. Consequently, you need to change ``PV`` in your recipe so that it does contain ``${SRCPV}``. - - For more information see the "`Automatically Incrementing a Binary - Package Revision - Number <&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number>`__" + + For more information see the + ":ref:`dev-manual/dev-manual-common-tasks:automatically incrementing a package version number`" section in the Yocto Project Development Tasks Manual. - + AVAILABLE_LICENSES List of licenses found in the directories specified by :term:`COMMON_LICENSE_DIR` and :term:`LICENSE_PATH`. - + .. note:: - + It is assumed that all changes to COMMON_LICENSE_DIR and @@ -225,106 +246,113 @@ system and gives an overview of their function and contents. is defined (in license.bbclass ). - + AVAILTUNES The list of defined CPU and Application Binary Interface (ABI) tunings (i.e. "tunes") available for use by the OpenEmbedded build system. - + The list simply presents the tunes that are available. Not all tunes may be compatible with a particular machine configuration, or with each other in a - `Multilib <&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image>`__ + :ref:`Multilib ` configuration. - + To add a tune to the list, be sure to append it with spaces using the "+=" BitBake operator. Do not simply replace the list by using the "=" operator. See the ":ref:`Basic Syntax `" section in the BitBake User Manual for more information. - + B The directory within the :term:`Build Directory` in which the OpenEmbedded build system places generated objects during a recipe's build process. By default, this directory is the same as the - :term:`S` directory, which is defined as: S = - "${WORKDIR}/${BP}" - + :term:`S` directory, which is defined as: + :: + + S = "${WORKDIR}/${BP}" + You can separate the (``S``) directory and the directory pointed to by the ``B`` variable. Most Autotools-based recipes support separating these directories. The build system defaults to using separate directories for ``gcc`` and some kernel recipes. - + BAD_RECOMMENDATIONS Lists "recommended-only" packages to not install. Recommended-only packages are packages installed only through the :term:`RRECOMMENDS` variable. You can prevent any of these "recommended" packages from being installed by listing them - with the ``BAD_RECOMMENDATIONS`` variable: BAD_RECOMMENDATIONS = - "package_name package_name package_name ..." - + with the ``BAD_RECOMMENDATIONS`` variable: + :: + + BAD_RECOMMENDATIONS = "package_name package_name package_name ..." + You can set this variable globally in your ``local.conf`` file or you can attach it to a specific image recipe by using the recipe name - override: BAD_RECOMMENDATIONS_pn-target_image = "package_name" - + override: + :: + + BAD_RECOMMENDATIONS_pn-target_image = "package_name" + It is important to realize that if you choose to not install packages using this variable and some other packages are dependent on them (i.e. listed in a recipe's :term:`RDEPENDS` variable), the OpenEmbedded build system ignores your request and will install the packages to avoid dependency errors. - + Support for this variable exists only when using the IPK and RPM packaging backend. Support does not exist for DEB. - + See the :term:`NO_RECOMMENDATIONS` and the :term:`PACKAGE_EXCLUDE` variables for related information. - + BASE_LIB The library directory name for the CPU or Application Binary Interface (ABI) tune. The ``BASE_LIB`` applies only in the Multilib - context. See the "`Combining Multiple Versions of Library Files into - One - Image <&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image>`__" + context. See the ":ref:`dev-manual/dev-manual-common-tasks:combining multiple versions of library files into one image`" section in the Yocto Project Development Tasks Manual for information on Multilib. - + The ``BASE_LIB`` variable is defined in the machine include files in the :term:`Source Directory`. If Multilib is not being used, the value defaults to "lib". - + BASE_WORKDIR Points to the base of the work directory for all recipes. The default value is "${TMPDIR}/work". - + 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 ``BB_NO_NETWORK`` is either not set or set to "0". - + - Limited support for wildcard matching against the beginning of host names exists. For example, the following setting matches ``git.gnu.org``, ``ftp.gnu.org``, and ``foo.git.gnu.org``. - BB_ALLOWED_NETWORKS = "*.gnu.org" - + :: + + BB_ALLOWED_NETWORKS = "*.gnu.org" + .. note:: - + 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 ``BB_ALLOWED_NETWORKS`` in conjunction with :term:`PREMIRRORS` is very useful. Adding the host you want to use to ``PREMIRRORS`` results in the source code being @@ -333,7 +361,7 @@ system and gives an overview of their function and contents. statement. This is because the fetcher does not attempt to use the host listed in ``SRC_URI`` after a successful fetch from the ``PREMIRRORS`` occurs. - + BB_DANGLINGAPPENDS_WARNONLY Defines how BitBake handles situations where an append file (``.bbappend``) has no corresponding recipe file (``.bb``). This @@ -341,42 +369,69 @@ system and gives an overview of their function and contents. bumps a recipe version and the old recipe no longer exists and the other layer has not been updated to the new version of the recipe yet). - + The default fatal behavior is safest because it is the sane reaction given something is out of sync. It is important to realize when your changes are no longer being applied. - + You can change the default behavior by setting this variable to "1", "yes", or "true" in your ``local.conf`` file, which is located in the :term:`Build Directory`: Here is an example: - BB_DANGLINGAPPENDS_WARNONLY = "1" - + :: + + BB_DANGLINGAPPENDS_WARNONLY = "1" + 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. To enable monitoring, add the ``BB_DISKMON_DIRS`` variable to your ``conf/local.conf`` file found in the :term:`Build Directory`. Use the - following form: BB_DISKMON_DIRS = "action,dir,threshold [...]" where: - action is: ABORT: Immediately abort 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 in the conf/local.conf file. 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 = "ABORT,${TMPDIR},1G,100K - WARN,${SSTATE_DIR},1G,100K" BB_DISKMON_DIRS = - "STOPTASKS,${TMPDIR},1G" BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K" + following form: + :: + + BB_DISKMON_DIRS = "action,dir,threshold [...]" + + where: + + action is: + ABORT: Immediately abort 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 in + the conf/local.conf file. + + 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 = "ABORT,${TMPDIR},1G,100K WARN,${SSTATE_DIR},1G,100K" + BB_DISKMON_DIRS = "STOPTASKS,${TMPDIR},1G" + BB_DISKMON_DIRS = "ABORT,${TMPDIR},,100K" + The first example works only if you also provide the :term:`BB_DISKMON_WARNINTERVAL` variable in the ``conf/local.conf``. This example causes the build @@ -388,64 +443,85 @@ system and gives an overview of their function and contents. of free inodes drops below 100 Kbytes. Subsequent warnings are issued during intervals as defined by the ``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 aborts 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. - + BB_DISKMON_WARNINTERVAL Defines the disk space and free inode warning intervals. To set these intervals, define the variable in your ``conf/local.conf`` file in the :term:`Build Directory`. - + If you are going to use the ``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 ``BB_DISKMON_WARNINTERVAL`` variable and you do use ``BB_DISKMON_DIRS`` with the "WARN" action, the disk monitoring interval defaults to the following: - BB_DISKMON_WARNINTERVAL = "50M,5K" - + :: + + 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 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 the OpenEmbedded build system 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). - + BB_GENERATE_MIRROR_TARBALLS Causes tarballs of the source control repositories (e.g. Git repositories), including metadata, to be placed in the :term:`DL_DIR` directory. - + For performance reasons, creating and placing tarballs of these repositories is not the default action by the OpenEmbedded build - system. BB_GENERATE_MIRROR_TARBALLS = "1" Set this variable in your + system. + :: + + BB_GENERATE_MIRROR_TARBALLS = "1" + + Set this variable in your ``local.conf`` file in the :term:`Build Directory`. - + Once you have the tarballs containing your source files, you can clean up your ``DL_DIR`` directory by deleting any Git or other source control work directories. - + BB_NUMBER_THREADS The maximum number of tasks BitBake should run in parallel at any one time. The OpenEmbedded build system automatically configures this @@ -453,27 +529,31 @@ system and gives an overview of their function and contents. example, a system with a dual core processor that also uses hyper-threading causes the ``BB_NUMBER_THREADS`` variable to default to "4". - + For single socket systems (i.e. one CPU), you should not have to override this variable to gain optimal parallelism during builds. However, if you have very large systems that employ multiple physical CPUs, you might want to make sure the ``BB_NUMBER_THREADS`` variable is not set higher than "20". - - For more information on speeding up builds, see the "`Speeding Up a - Build <&YOCTO_DOCS_DEV_URL;#speeding-up-a-build>`__" section in the - Yocto Project Development Tasks Manual. - + + For more information on speeding up builds, see the + ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`" + section in the Yocto Project Development Tasks Manual. + BB_SERVER_TIMEOUT Specifies the time (in seconds) after which to unload the BitBake server due to inactivity. Set ``BB_SERVER_TIMEOUT`` to determine how long the BitBake server stays resident between invocations. - + For example, the following statement in your ``local.conf`` file instructs the server to be unloaded after 20 seconds of inactivity: - BB_SERVER_TIMEOUT = "20" If you want the server to never be unloaded, + :: + + BB_SERVER_TIMEOUT = "20" + + If you want the server to never be unloaded, set ``BB_SERVER_TIMEOUT`` to "-1". - + BBCLASSEXTEND Allows you to extend a recipe so that it builds variants of the software. Common variants for recipes exist such as "natives" like @@ -483,40 +563,42 @@ system and gives an overview of their function and contents. :term:`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 following to your recipe: - BBCLASSEXTEND =+ "native nativesdk" BBCLASSEXTEND =+ - "multilib:multilib_name" - + :: + + BBCLASSEXTEND =+ "native nativesdk" + BBCLASSEXTEND =+ "multilib:multilib_name" + .. note:: - + Internally, the ``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 ``DEPENDS`` on "foo-native". - + Even when using ``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. - + BBFILE_COLLECTIONS Lists the names of configured layers. These names are used to find the other ``BBFILE_*`` variables. Typically, each layer will append its name to this variable in its ``conf/layer.conf`` file. - + 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``). - + BBFILE_PRIORITY Assigns the priority for recipe files in each layer. - + 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 @@ -526,7 +608,7 @@ system and gives an overview of their function and contents. example, a layer that has a recipe with a higher ``PV`` value but for which the ``BBFILE_PRIORITY`` is set to have a lower precedence still has a lower precedence. - + A larger value for the ``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 ``BBFILE_PRIORITY`` variable @@ -534,116 +616,136 @@ system and gives an overview of their function and contents. 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. - + 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. + `glob `_ syntax. For details on the syntax, see the documentation by following the previous link. - + BBFILES_DYNAMIC Activates content when identified layers are present. You identify the layers by the collections that the layers define. - + Use the ``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. - + Use the following form for ``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 \\ " + collection names and two filename patterns: + :: + + BBFILES_DYNAMIC += " \ + clang-layer:${LAYERDIR}/bbappends/meta-clang/*/*/*.bbappend \ + core:${LAYERDIR}/bbappends/openembedded-core/meta/*/*/*.bbappend \ + " + This next example shows an error message that occurs because invalid - entries are found, which cause parsing to abort: ERROR: - BBFILES_DYNAMIC entries must be of the form :, not: - /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend - /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend - + entries are found, which cause parsing to abort: + :: + + ERROR: BBFILES_DYNAMIC entries must be of the form :, not: + /work/my-layer/bbappends/meta-security-isafw/*/*/*.bbappend + /work/my-layer/bbappends/openembedded-core/meta/*/*/*.bbappend + BBINCLUDELOGS Variable that controls how BitBake displays logs on build failure. - + 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 ``BBINCLUDELOGS_LINES``, the entire log is printed. - + BBLAYERS Lists the layers to enable during the build. This variable is defined in the ``bblayers.conf`` configuration file in the :term:`Build Directory`. - Here is an example: BBLAYERS = " \\ - /home/scottrif/poky/meta \\ /home/scottrif/poky/meta-poky \\ - /home/scottrif/poky/meta-yocto-bsp \\ - /home/scottrif/poky/meta-mykernel \\ " - + Here is an example: + :: + + BBLAYERS = " \ + /home/scottrif/poky/meta \ /home/scottrif/poky/meta-poky \ + /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``. - + BBMASK Prevents BitBake from processing recipes and recipe append files. - + You can use the ``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#re. - + 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/" + ``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" - + 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. - + BBMULTICONFIG Specifies each additional separate configuration when you are building targets with multiple configurations. Use this variable in your ``conf/local.conf`` configuration file. Specify a multiconfigname for each configuration file you are using. For example, the following line specifies three configuration files: - BBMULTICONFIG = "configA configB configC" Each configuration file you + :: + + BBMULTICONFIG = "configA configB configC" + + Each configuration file you use must reside in the :term:`Build Directory` ``conf/multiconfig`` directory (e.g. build_directory\ ``/conf/multiconfig/configA.conf``). - + For information on how to use ``BBMULTICONFIG`` in an environment that supports building targets with multiple configurations, see the - "`Building Images for Multiple Targets Using Multiple - Configurations <&YOCTO_DOCS_DEV_URL;#dev-building-images-for-multiple-targets-using-multiple-configurations>`__" + ":ref:`dev-building-images-for-multiple-targets-using-multiple-configurations`" section in the Yocto Project Development Tasks Manual. - + BBPATH Used by BitBake to locate ``.bbclass`` and configuration files. This variable is analogous to the ``PATH`` variable. - + .. note:: - + If you run BitBake from a directory outside of the Build Directory , you must be sure to set @@ -651,24 +753,27 @@ system and gives an overview of their function and contents. 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 - - + + BBSERVER If defined in the BitBake environment, ``BBSERVER`` points to the BitBake remote server. - + Use the following format to export the variable to the BitBake - environment: export BBSERVER=localhost:$port - + environment: + :: + + export BBSERVER=localhost:$port + By default, ``BBSERVER`` also appears in :term:`bitbake:BB_HASHBASE_WHITELIST`. Consequently, ``BBSERVER`` is excluded from checksum and dependency data. - + BINCONFIG When inheriting the :ref:`binconfig-disabled ` class, @@ -677,11 +782,13 @@ system and gives an overview of their function and contents. ``binconfig-disabled`` class will modify the specified scripts to return an error so that calls to them can be easily found and replaced. - + To add multiple scripts, separate them by spaces. Here is an example - from the ``libpng`` recipe: BINCONFIG = "${bindir}/libpng-config - ${bindir}/libpng16-config" - + from the ``libpng`` recipe: + :: + + BINCONFIG = "${bindir}/libpng-config ${bindir}/libpng16-config" + BINCONFIG_GLOB When inheriting the :ref:`binconfig ` class, this variable specifies a wildcard for configuration scripts that @@ -689,9 +796,9 @@ system and gives an overview of their function and contents. been set up during compilation so that they are correct for use when installed into the sysroot and called by the build processes of other recipes. - + .. note:: - + The BINCONFIG_GLOB variable uses @@ -702,18 +809,21 @@ system and gives an overview of their function and contents. and glob . - + For more information on how this variable works, see ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`. You can also find general information on the class in the ":ref:`binconfig.bbclass `" section. - + BP The base recipe name and version but without any special recipe name suffix (i.e. ``-native``, ``lib64-``, and so forth). ``BP`` is - comprised of the following: ${BPN}-${PV} - + comprised of the following: + :: + + ${BPN}-${PV} + BPN This variable is a version of the :term:`PN` variable with common prefixes and suffixes removed, such as ``nativesdk-``, @@ -722,115 +832,115 @@ system and gives an overview of their function and contents. :term:`MLPREFIX` and :term:`SPECIAL_PKGSUFFIX` variables, respectively. - + BUGTRACKER Specifies a URL for an upstream bug tracking website for a recipe. The OpenEmbedded build system does not use this variable. Rather, the variable is a useful pointer in case a bug in the software being built needs to be manually reported. - + BUILD_ARCH Specifies the architecture of the build host (e.g. ``i686``). The OpenEmbedded build system sets the value of ``BUILD_ARCH`` from the machine name reported by the ``uname`` command. - + BUILD_AS_ARCH Specifies the architecture-specific assembler flags for the build host. By default, the value of ``BUILD_AS_ARCH`` is empty. - + BUILD_CC_ARCH Specifies the architecture-specific C compiler flags for the build host. By default, the value of ``BUILD_CC_ARCH`` is empty. - + BUILD_CCLD Specifies the linker command to be used for the build host when the C compiler is being used as the linker. By default, ``BUILD_CCLD`` points to GCC and passes as arguments the value of :term:`BUILD_CC_ARCH`, assuming ``BUILD_CC_ARCH`` is set. - + BUILD_CFLAGS Specifies the flags to pass to the C compiler when building for the build host. When building in the ``-native`` context, :term:`CFLAGS` is set to the value of this variable by default. - + BUILD_CPPFLAGS Specifies the flags to pass to the C preprocessor (i.e. to both the C and the C++ compilers) when building for the build host. When building in the ``-native`` context, :term:`CPPFLAGS` is set to the value of this variable by default. - + BUILD_CXXFLAGS Specifies the flags to pass to the C++ compiler when building for the build host. When building in the ``-native`` context, :term:`CXXFLAGS` is set to the value of this variable by default. - + BUILD_FC Specifies the Fortran compiler command for the build host. By default, ``BUILD_FC`` points to Gfortran and passes as arguments the value of :term:`BUILD_CC_ARCH`, assuming ``BUILD_CC_ARCH`` is set. - + BUILD_LD Specifies the linker command for the build host. By default, ``BUILD_LD`` points to the GNU linker (ld) and passes as arguments the value of :term:`BUILD_LD_ARCH`, assuming ``BUILD_LD_ARCH`` is set. - + BUILD_LD_ARCH Specifies architecture-specific linker flags for the build host. By default, the value of ``BUILD_LD_ARCH`` is empty. - + BUILD_LDFLAGS Specifies the flags to pass to the linker when building for the build host. When building in the ``-native`` context, :term:`LDFLAGS` is set to the value of this variable by default. - + BUILD_OPTIMIZATION Specifies the optimization flags passed to the C compiler when building for the build host or the SDK. The flags are passed through the :term:`BUILD_CFLAGS` and :term:`BUILDSDK_CFLAGS` default values. - + The default value of the ``BUILD_OPTIMIZATION`` variable is "-O2 -pipe". - + BUILD_OS Specifies the operating system in use on the build host (e.g. "linux"). The OpenEmbedded build system sets the value of ``BUILD_OS`` from the OS reported by the ``uname`` command - the first word, converted to lower-case characters. - + BUILD_PREFIX The toolchain binary prefix used for native recipes. The OpenEmbedded build system uses the ``BUILD_PREFIX`` value to set the :term:`TARGET_PREFIX` when building for ``native`` recipes. - + BUILD_STRIP Specifies the command to be used to strip debugging symbols from binaries produced for the build host. By default, ``BUILD_STRIP`` points to ``${``\ :term:`BUILD_PREFIX`\ ``}strip``. - + BUILD_SYS Specifies the system, including the architecture and the operating system, to use when building for the build host (i.e. when building ``native`` recipes). - + The OpenEmbedded build system automatically sets this variable based on :term:`BUILD_ARCH`, :term:`BUILD_VENDOR`, and :term:`BUILD_OS`. You do not need to set the ``BUILD_SYS`` variable yourself. - + BUILD_VENDOR Specifies the vendor name to use when building for the build host. The default value is an empty string (""). - + BUILDDIR Points to the location of the :term:`Build Directory`. You can define this directory indirectly through the @@ -838,7 +948,7 @@ system and gives an overview of their function and contents. Directory path when you run the script. If you run the script and do not provide a Build Directory path, the ``BUILDDIR`` defaults to ``build`` in the current directory. - + BUILDHISTORY_COMMIT When inheriting the :ref:`buildhistory ` class, this variable specifies whether or not to commit the build @@ -848,60 +958,70 @@ system and gives an overview of their function and contents. top-level subdirectory of the build history output (images, packages, and sdk). If you want to track changes to build history over time, you should set this value to "1". - + By default, the ``buildhistory`` class does not commit the build - history output in a local Git repository: BUILDHISTORY_COMMIT ?= "0" - + history output in a local Git repository: + :: + + BUILDHISTORY_COMMIT ?= "0" + BUILDHISTORY_COMMIT_AUTHOR When inheriting the :ref:`buildhistory ` class, this variable specifies the author to use for each Git commit. In order for the ``BUILDHISTORY_COMMIT_AUTHOR`` variable to work, the :term:`BUILDHISTORY_COMMIT` variable must be set to "1". - + Git requires that the value you provide for the ``BUILDHISTORY_COMMIT_AUTHOR`` variable takes the form of "name email@host". Providing an email address or host that is not valid does not produce an error. - + By default, the ``buildhistory`` class sets the variable as follows: - BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory " - + :: + + BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory " + BUILDHISTORY_DIR When inheriting the :ref:`buildhistory ` class, this variable specifies the directory in which build history information is kept. For more information on how the variable works, see the ``buildhistory.class``. - + By default, the ``buildhistory`` class sets the directory as follows: - BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory" - + :: + + BUILDHISTORY_DIR ?= "${TOPDIR}/buildhistory" + BUILDHISTORY_FEATURES When inheriting the :ref:`buildhistory ` class, this variable specifies the build history features to be enabled. For more information on how build history works, see the - "`Maintaining Build Output - Quality <&YOCTO_DOCS_DEV_URL;#maintaining-build-output-quality>`__" + ":ref:`dev-manual/dev-manual-common-tasks:maintaining build output quality`" section in the Yocto Project Development Tasks Manual. - + You can specify these features in the form of a space-separated list: - + - *image:* Analysis of the contents of images, which includes the list of installed packages among other things. - + - *package:* Analysis of the contents of individual packages. - + - *sdk:* Analysis of the contents of the software development kit (SDK). - - - *task:* Save output file signatures for `shared - state <&YOCTO_DOCS_OM_URL;#shared-state-cache>`__ (sstate) tasks. + + - *task:* Save output file signatures for + :ref:`shared state ` + (sstate) tasks. This saves one file per task and lists the SHA-256 checksums for each file staged (i.e. the output of the task). - + By default, the ``buildhistory`` class enables the following - features: BUILDHISTORY_FEATURES ?= "image package sdk" - + features: + :: + + BUILDHISTORY_FEATURES ?= "image package sdk" + BUILDHISTORY_IMAGE_FILES When inheriting the :ref:`buildhistory ` class, this variable specifies a list of paths to files copied from @@ -912,10 +1032,13 @@ system and gives an overview of their function and contents. changes in user and group entries. You can modify the list to include any file. Specifying an invalid path does not produce an error. Consequently, you can include files that might not always be present. - + By default, the ``buildhistory`` class provides paths to the - following files: BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group" - + following files: + :: + + BUILDHISTORY_IMAGE_FILES ?= "/etc/passwd /etc/group" + BUILDHISTORY_PUSH_REPO When inheriting the :ref:`buildhistory ` class, this variable optionally specifies a remote repository to @@ -923,81 +1046,83 @@ system and gives an overview of their function and contents. ``BUILDHISTORY_PUSH_REPO`` to work, :term:`BUILDHISTORY_COMMIT` must be set to "1". - + The repository should correspond to a remote address that specifies a repository as understood by Git, or alternatively to a remote name that you have set up manually using ``git remote`` within the local repository. - + By default, the ``buildhistory`` class sets the variable as follows: - BUILDHISTORY_PUSH_REPO ?= "" - + :: + + BUILDHISTORY_PUSH_REPO ?= "" + BUILDSDK_CFLAGS Specifies the flags to pass to the C compiler when building for the SDK. When building in the ``nativesdk-`` context, :term:`CFLAGS` is set to the value of this variable by default. - + BUILDSDK_CPPFLAGS Specifies the flags to pass to the C pre-processor (i.e. to both the C and the C++ compilers) when building for the SDK. When building in the ``nativesdk-`` context, :term:`CPPFLAGS` is set to the value of this variable by default. - + BUILDSDK_CXXFLAGS Specifies the flags to pass to the C++ compiler when building for the SDK. When building in the ``nativesdk-`` context, :term:`CXXFLAGS` is set to the value of this variable by default. - + BUILDSDK_LDFLAGS Specifies the flags to pass to the linker when building for the SDK. When building in the ``nativesdk-`` context, :term:`LDFLAGS` is set to the value of this variable by default. - + BUILDSTATS_BASE Points to the location of the directory that holds build statistics when you use and enable the :ref:`buildstats ` class. The ``BUILDSTATS_BASE`` directory defaults to ``${``\ :term:`TMPDIR`\ ``}/buildstats/``. - + BUSYBOX_SPLIT_SUID For the BusyBox recipe, specifies whether to split the output executable file into two parts: one for features that require ``setuid root``, and one for the remaining features (i.e. those that do not require ``setuid root``). - + The ``BUSYBOX_SPLIT_SUID`` variable defaults to "1", which results in splitting the output executable file. Set the variable to "0" to get a single output executable file. - + CACHE Specifies the directory BitBake uses to store a cache of the :term:`Metadata` so it does not need to be parsed every time BitBake is started. - + CC The minimal command and arguments used to run the C compiler. - + CFLAGS Specifies the flags to pass to the C compiler. This variable is exported to an environment variable and thus made visible to the software being built during the compilation step. - + Default initialization for ``CFLAGS`` varies depending on what is being built: - + - :term:`TARGET_CFLAGS` when building for the target - + - :term:`BUILD_CFLAGS` when building for the build host (i.e. ``-native``) - + - :term:`BUILDSDK_CFLAGS` when building for an SDK (i.e. ``nativesdk-``) - + CLASSOVERRIDE An internal variable specifying the special class override that should currently apply (e.g. "class-target", "class-native", and so @@ -1005,31 +1130,41 @@ system and gives an overview of their function and contents. :ref:`native `, :ref:`nativesdk `, and so forth) set the variable to appropriate values. - + .. note:: - + CLASSOVERRIDE gets its default "class-target" value from the bitbake.conf file. - + As an example, the following override allows you to install extra files, but only when building for the target: - do_install_append_class-target() { install my-extra-file - ${D}${sysconfdir} } Here is an example where ``FOO`` is set to + :: + + do_install_append_class-target() { + install my-extra-file ${D}${sysconfdir} + } + + Here is an example where ``FOO`` is set to "native" when building for the build host, and to "other" when not - building for the build host: FOO_class-native = "native" FOO = - "other" The underlying mechanism behind ``CLASSOVERRIDE`` is simply + building for the build host: + :: + + FOO_class-native = "native" + FOO = "other" + + The underlying mechanism behind ``CLASSOVERRIDE`` is simply that it is included in the default value of :term:`OVERRIDES`. - + CLEANBROKEN If set to "1" within a recipe, ``CLEANBROKEN`` specifies that the ``make clean`` command does not work for the software being built. Consequently, the OpenEmbedded build system will not try to run ``make clean`` during the :ref:`ref-tasks-configure` task, which is the default behavior. - + COMBINED_FEATURES Provides a list of hardware features that are enabled in both :term:`MACHINE_FEATURES` and @@ -1039,12 +1174,12 @@ system and gives an overview of their function and contents. "bluetooth" feature requires hardware support but should also be optional at the distribution level, in case the hardware supports Bluetooth but you do not ever intend to use it. - + COMMON_LICENSE_DIR Points to ``meta/files/common-licenses`` in the :term:`Source Directory`, which is where generic license files reside. - + COMPATIBLE_HOST A regular expression that resolves to one or more hosts (when the recipe is native) or one or more targets (when the recipe is @@ -1055,7 +1190,7 @@ system and gives an overview of their function and contents. particularly useful with kernels. The variable also helps to increase parsing speed since the build system skips parsing recipes not compatible with the current system. - + COMPATIBLE_MACHINE A regular expression that resolves to one or more target machines with which a recipe is compatible. The regular expression is matched @@ -1065,14 +1200,14 @@ system and gives an overview of their function and contents. useful with kernels. The variable also helps to increase parsing speed since the build system skips parsing recipes not compatible with the current machine. - + COMPLEMENTARY_GLOB Defines wildcards to match when installing a list of complementary packages for all the packages explicitly (or implicitly) installed in an image. - + .. note:: - + The COMPLEMENTARY_GLOB variable uses Unix filename pattern matching ( @@ -1080,33 +1215,36 @@ system and gives an overview of their function and contents. ), which is similar to the Unix style pathname pattern expansion ( glob ). - + The resulting list of complementary packages is associated with an item that can be added to :term:`IMAGE_FEATURES`. An example usage of this is the "dev-pkgs" item that when added to ``IMAGE_FEATURES`` will install -dev packages (containing headers and other development files) for every package in the image. - + To add a new feature item pointing to a wildcard, use a variable flag to specify the feature item name and use the value to specify the - wildcard. Here is an example: COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev' - + wildcard. Here is an example: + :: + + COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev' + COMPONENTS_DIR Stores sysroot components for each recipe. The OpenEmbedded build system uses ``COMPONENTS_DIR`` when constructing recipe-specific sysroots for other recipes. - + The default is "``${``\ :term:`STAGING_DIR`\ ``}-components``." (i.e. "``${``\ :term:`TMPDIR`\ ``}/sysroots-components``"). - + CONF_VERSION Tracks the version of the local configuration file (i.e. ``local.conf``). The value for ``CONF_VERSION`` increments each time ``build/conf/`` compatibility changes. - + CONFFILES Identifies editable or configurable files that are part of a package. If the Package Management System (PMS) is being used to update @@ -1117,12 +1255,15 @@ system and gives an overview of their function and contents. as part of the package update process. You can use the ``CONFFILES`` variable to list the files in the package that you wish to prevent the PMS from overwriting during this update process. - + To use the ``CONFFILES`` variable, provide a package name override that identifies the resulting package. Then, provide a - space-separated list of files. Here is an example: CONFFILES_${PN} += - "${sysconfdir}/file1 \\ ${sysconfdir}/file2 ${sysconfdir}/file3" - + space-separated list of files. Here is an example: + :: + + CONFFILES_${PN} += "${sysconfdir}/file1 \ + ${sysconfdir}/file2 ${sysconfdir}/file3" + A relationship exists between the ``CONFFILES`` and ``FILES`` variables. The files listed within ``CONFFILES`` must be a subset of the files listed within ``FILES``. Because the configuration files @@ -1130,9 +1271,9 @@ system and gives an overview of their function and contents. the PMS will not overwrite them, it makes sense that the files must already be included as part of the package through the ``FILES`` variable. - + .. note:: - + When specifying paths as part of the CONFFILES variable, it is good practice to use appropriate path variables. @@ -1149,13 +1290,13 @@ system and gives an overview of their function and contents. file in the Source Directory . - + CONFIG_INITRAMFS_SOURCE Identifies the initial RAM filesystem (initramfs) source files. The OpenEmbedded build system receives and uses this kernel Kconfig variable as an environment variable. By default, the variable is set to null (""). - + The ``CONFIG_INITRAMFS_SOURCE`` can be either a single cpio archive with a ``.cpio`` suffix or a space-separated list of directories and files for building the initramfs image. A cpio archive should contain @@ -1163,23 +1304,22 @@ system and gives an overview of their function and contents. should contain a filesystem layout to be included in the initramfs image. Files should contain entries according to the format described by the ``usr/gen_init_cpio`` program in the kernel tree. - + If you specify multiple directories and files, the initramfs image will be the aggregate of all of them. - - For information on creating an initramfs, see the "`Building an - Initial RAM Filesystem (initramfs) - Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section + + For information on creating an initramfs, see the + ":ref:`building-an-initramfs-image`" section in the Yocto Project Development Tasks Manual. - + CONFIG_SITE A list of files that contains ``autoconf`` test results relevant to the current build. This variable is used by the Autotools utilities when running ``configure``. - + CONFIGURE_FLAGS The minimal arguments for GNU configure. - + CONFLICT_DISTRO_FEATURES When inheriting the :ref:`distro_features_check ` @@ -1188,7 +1328,7 @@ system and gives an overview of their function and contents. ``CONFLICT_DISTRO_FEATURES`` variable lists a feature that also appears in ``DISTRO_FEATURES`` within the current configuration, an error occurs and the build stops. - + COPYLEFT_LICENSE_EXCLUDE A space-separated list of licenses to exclude from the source archived by the :ref:`archiver ` class. In @@ -1196,32 +1336,32 @@ system and gives an overview of their function and contents. :term:`LICENSE` value is in the value of ``COPYLEFT_LICENSE_EXCLUDE``, then its source is not archived by the class. - + .. note:: - + The COPYLEFT_LICENSE_EXCLUDE variable takes precedence over the COPYLEFT_LICENSE_INCLUDE variable. - + The default value, which is "CLOSED Proprietary", for ``COPYLEFT_LICENSE_EXCLUDE`` is set by the :ref:`copyleft_filter ` class, which is inherited by the ``archiver`` class. - + COPYLEFT_LICENSE_INCLUDE A space-separated list of licenses to include in the source archived by the :ref:`archiver ` class. In other words, if a license in a recipe's :term:`LICENSE` value is in the value of ``COPYLEFT_LICENSE_INCLUDE``, then its source is archived by the class. - + The default value is set by the :ref:`copyleft_filter ` class, which is inherited by the ``archiver`` class. The default value includes "GPL*", "LGPL*", and "AGPL*". - + COPYLEFT_PN_EXCLUDE A list of recipes to exclude in the source archived by the :ref:`archiver ` class. The @@ -1230,12 +1370,12 @@ system and gives an overview of their function and contents. :term:`COPYLEFT_LICENSE_INCLUDE` and :term:`COPYLEFT_LICENSE_EXCLUDE` variables, respectively. - + The default value, which is "" indicating to not explicitly exclude any recipes by name, for ``COPYLEFT_PN_EXCLUDE`` is set by the :ref:`copyleft_filter ` class, which is inherited by the ``archiver`` class. - + COPYLEFT_PN_INCLUDE A list of recipes to include in the source archived by the :ref:`archiver ` class. The @@ -1244,22 +1384,22 @@ system and gives an overview of their function and contents. :term:`COPYLEFT_LICENSE_INCLUDE` and :term:`COPYLEFT_LICENSE_EXCLUDE` variables, respectively. - + The default value, which is "" indicating to not explicitly include any recipes by name, for ``COPYLEFT_PN_INCLUDE`` is set by the :ref:`copyleft_filter ` class, which is inherited by the ``archiver`` class. - + COPYLEFT_RECIPE_TYPES A space-separated list of recipe types to include in the source archived by the :ref:`archiver ` class. Recipe types are ``target``, ``native``, ``nativesdk``, ``cross``, ``crosssdk``, and ``cross-canadian``. - + The default value, which is "target*", for ``COPYLEFT_RECIPE_TYPES`` is set by the :ref:`copyleft_filter ` class, which is inherited by the ``archiver`` class. - + COPY_LIC_DIRS If set to "1" along with the :term:`COPY_LIC_MANIFEST` variable, the @@ -1267,9 +1407,9 @@ system and gives an overview of their function and contents. which are located in ``/usr/share/common-licenses``, for each package. The license files are placed in directories within the image itself during build time. - + .. note:: - + The COPY_LIC_DIRS does not offer a path for adding licenses for newly installed @@ -1280,15 +1420,15 @@ system and gives an overview of their function and contents. Providing License Text " section in the Yocto Project Development Tasks Manual for information on providing license text. - + COPY_LIC_MANIFEST If set to "1", the OpenEmbedded build system copies the license manifest for the image to ``/usr/share/common-licenses/license.manifest`` within the image itself during build time. - + .. note:: - + The COPY_LIC_MANIFEST does not offer a path for adding licenses for newly installed @@ -1299,177 +1439,190 @@ system and gives an overview of their function and contents. Providing License Text " section in the Yocto Project Development Tasks Manual for information on providing license text. - + CORE_IMAGE_EXTRA_INSTALL Specifies the list of packages to be added to the image. You should only set this variable in the ``local.conf`` configuration file found in the :term:`Build Directory`. - + This variable replaces ``POKY_EXTRA_INSTALL``, which is no longer supported. - + COREBASE Specifies the parent directory of the OpenEmbedded-Core Metadata layer (i.e. ``meta``). - + It is an important distinction that ``COREBASE`` points to the parent of this layer and not the layer itself. Consider an example where you have cloned the Poky Git repository and retained the ``poky`` name for your local copy of the repository. In this case, ``COREBASE`` points to the ``poky`` folder because it is the parent directory of the ``poky/meta`` layer. - + COREBASE_FILES Lists files from the :term:`COREBASE` directory that should be copied other than the layers listed in the ``bblayers.conf`` file. The ``COREBASE_FILES`` variable exists for the purpose of copying metadata from the OpenEmbedded build system into the extensible SDK. - + Explicitly listing files in ``COREBASE`` is needed because it typically contains build directories and other files that should not normally be copied into the extensible SDK. Consequently, the value of ``COREBASE_FILES`` is used in order to only copy the files that are actually needed. - + CPP The minimal command and arguments used to run the C preprocessor. - + CPPFLAGS Specifies the flags to pass to the C pre-processor (i.e. to both the C and the C++ compilers). This variable is exported to an environment variable and thus made visible to the software being built during the compilation step. - + Default initialization for ``CPPFLAGS`` varies depending on what is being built: - + - :term:`TARGET_CPPFLAGS` when building for the target - + - :term:`BUILD_CPPFLAGS` when building for the build host (i.e. ``-native``) - + - :term:`BUILDSDK_CPPFLAGS` when building for an SDK (i.e. ``nativesdk-``) - + CROSS_COMPILE The toolchain binary prefix for the target tools. The ``CROSS_COMPILE`` variable is the same as the :term:`TARGET_PREFIX` variable. - + .. note:: - + The OpenEmbedded build system sets the CROSS_COMPILE variable only in certain contexts (e.g. when building for kernel and kernel module recipes). - + CVSDIR The directory in which files checked out under the CVS system are stored. - + CXX The minimal command and arguments used to run the C++ compiler. - + CXXFLAGS Specifies the flags to pass to the C++ compiler. This variable is exported to an environment variable and thus made visible to the software being built during the compilation step. - + Default initialization for ``CXXFLAGS`` varies depending on what is being built: - + - :term:`TARGET_CXXFLAGS` when building for the target - + - :term:`BUILD_CXXFLAGS` when building for the build host (i.e. ``-native``) - + - :term:`BUILDSDK_CXXFLAGS` when building for an SDK (i.e. ``nativesdk-``) - + D The destination directory. The location in the :term:`Build Directory` where components are installed by the :ref:`ref-tasks-install` task. This location defaults - to: ${WORKDIR}/image - + to: + :: + + ${WORKDIR}/image + .. note:: - + Tasks that read from or write to this directory should run under fakeroot . - + DATE The date the build was started. Dates appear using the year, month, and day (YMD) format (e.g. "20150209" for February 9th, 2015). - + DATETIME The date and time on which the current build started. The format is suitable for timestamps. - + DEBIAN_NOAUTONAME When the :ref:`debian ` class is inherited, which is the default behavior, ``DEBIAN_NOAUTONAME`` specifies a particular package should not be renamed according to Debian library package naming. You must use the package name as an override when you set this variable. Here is an example from the ``fontconfig`` recipe: - DEBIAN_NOAUTONAME_fontconfig-utils = "1" - + :: + + DEBIAN_NOAUTONAME_fontconfig-utils = "1" + DEBIANNAME When the :ref:`debian ` class is inherited, which is the default behavior, ``DEBIANNAME`` allows you to override the library name for an individual package. Overriding the library name in these cases is rare. You must use the package name as an override when you set this variable. Here is an example from the - ``dbus`` recipe: DEBIANNAME_${PN} = "dbus-1" - + ``dbus`` recipe: + :: + + DEBIANNAME_${PN} = "dbus-1" + DEBUG_BUILD Specifies to build packages with debugging information. This influences the value of the ``SELECTED_OPTIMIZATION`` variable. - + DEBUG_OPTIMIZATION The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when compiling a system for debugging. This variable defaults to "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe". - + 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 ``PREFERRED_VERSION`` being used to build the development version. - + .. note:: - + The bias provided by DEFAULT_PREFERENCE is weak and is overridden by BBFILE_PRIORITY if that variable is different between two layers that contain different versions of the same recipe. - + DEFAULTTUNE The default CPU and Application Binary Interface (ABI) tunings (i.e. the "tune") used by the OpenEmbedded build system. The ``DEFAULTTUNE`` helps define :term:`TUNE_FEATURES`. - + The default tune is either implicitly or explicitly set by the machine (:term:`MACHINE`). However, you can override the setting using available tunes as defined with :term:`AVAILTUNES`. - + DEPENDS Lists a recipe's build-time dependencies. These are dependencies on other recipes whose contents (e.g. headers and shared libraries) are needed by the recipe at build time. - + As an example, consider a recipe ``foo`` that contains the following - assignment: DEPENDS = "bar" The practical effect of the previous + assignment: + :: + + DEPENDS = "bar" + + The practical effect of the previous assignment is that all files installed by bar will be available in the appropriate staging sysroot, given by the :term:`STAGING_DIR* ` variables, by the time the @@ -1479,23 +1632,28 @@ system and gives an overview of their function and contents. each recipe listed in ``DEPENDS``, through a ``[``\ :ref:`deptask `\ ``]`` declaration in the :ref:`base ` class. - + .. note:: - + It seldom is necessary to reference, for example, STAGING_DIR_HOST explicitly. The standard classes and build-related variables are configured to automatically use the appropriate staging sysroots. - + As another example, ``DEPENDS`` can also be used to add utilities that run on the build machine during the build. For example, a recipe that makes use of a code generator built by the recipe ``codegen`` - might have the following: DEPENDS = "codegen-native" For more + might have the following: + :: + + DEPENDS = "codegen-native" + + For more information, see the :ref:`native ` class and the :term:`EXTRANATIVEPATH` variable. - + .. note:: - + - ``DEPENDS`` is a list of recipe names. Or, to be more precise, it is a list of :term:`PROVIDES` names, which usually match recipe names. Putting a package name such as @@ -1503,16 +1661,15 @@ system and gives an overview of their function and contents. instead, as this will put files from all the packages that make up ``foo``, which includes those from ``foo-dev``, into the sysroot. - + - One recipe having another recipe in ``DEPENDS`` does not by itself add any runtime dependencies between the packages produced by the two recipes. However, as explained in the - "`Automatically Added Runtime - Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__" + ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`" section in the Yocto Project Overview and Concepts Manual, runtime dependencies will often be added automatically, meaning ``DEPENDS`` alone is sufficient for most recipes. - + - Counterintuitively, ``DEPENDS`` is often necessary even for recipes that install precompiled components. For example, if ``libfoo`` is a precompiled library that links against @@ -1521,50 +1678,51 @@ system and gives an overview of their function and contents. Without a ``DEPENDS`` from the recipe that installs ``libfoo`` to the recipe that installs ``libbar``, other recipes might fail to link against ``libfoo``. - + For information on runtime dependencies, see the :term:`RDEPENDS` variable. You can also see the ":ref:`Tasks `" and ":ref:`Dependencies `" sections in the BitBake User Manual for additional information on tasks and dependencies. - + DEPLOY_DIR Points to the general area that the OpenEmbedded build system uses to place images, packages, SDKs, and other output files that are ready to be used outside of the build system. By default, this directory resides within the :term:`Build Directory` as ``${TMPDIR}/deploy``. - + For more information on the structure of the Build Directory, see - "`The Build Directory - ``build/`` <#structure-build>`__" section. + ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section. For more detail on the contents of the ``deploy`` directory, see the - "`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__", "`Package - Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__", and - "`Application Development - SDK <&YOCTO_DOCS_OM_URL;#sdk-dev-environment>`__" sections all in the + ":ref:`Images `", ":ref:`Package + Feeds `", and + ":ref:`sdk-dev-environment`" sections all in the Yocto Project Overview and Concepts Manual. - + DEPLOY_DIR_DEB Points to the area that the OpenEmbedded build system uses to place Debian packages that are ready to be used outside of the build system. This variable applies only when :term:`PACKAGE_CLASSES` contains "package_deb". - + The BitBake configuration file initially defines the ``DEPLOY_DIR_DEB`` variable as a sub-folder of - :term:`DEPLOY_DIR`: DEPLOY_DIR_DEB = - "${DEPLOY_DIR}/deb" - + :term:`DEPLOY_DIR`: + :: + + DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb" + The :ref:`package_deb ` class uses the ``DEPLOY_DIR_DEB`` variable to make sure the :ref:`ref-tasks-package_write_deb` task writes Debian packages into the appropriate folder. For more - information on how packaging works, see the "`Package - Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section + information on how packaging works, see the ":ref:`Package + Feeds `" section in the Yocto Project Overview and Concepts Manual. - + DEPLOY_DIR_IMAGE Points to the area that the OpenEmbedded build system uses to place images and other associated output files that are ready to be @@ -1572,120 +1730,130 @@ system and gives an overview of their function and contents. as it contains the ``${MACHINE}`` name. By default, this directory resides within the :term:`Build Directory` as ``${DEPLOY_DIR}/images/${MACHINE}/``. - + For more information on the structure of the Build Directory, see - "`The Build Directory - ``build/`` <#structure-build>`__" section. + ":ref:`ref-manual/ref-structure:the build directory - \`\`build/\`\``" section. For more detail on the contents of the ``deploy`` directory, see the - "`Images <&YOCTO_DOCS_OM_URL;#images-dev-environment>`__" and - "`Application Development - SDK <&YOCTO_DOCS_OM_URL;#sdk-dev-environment>`__" sections both in + ":ref:`Images `" and + ":ref:`sdk-dev-environment`" sections both in the Yocto Project Overview and Concepts Manual. - + DEPLOY_DIR_IPK Points to the area that the OpenEmbedded build system uses to place IPK packages that are ready to be used outside of the build system. This variable applies only when :term:`PACKAGE_CLASSES` contains "package_ipk". - + The BitBake configuration file initially defines this variable as a - sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_IPK = - "${DEPLOY_DIR}/ipk" - + sub-folder of :term:`DEPLOY_DIR`: + :: + + DEPLOY_DIR_IPK = "${DEPLOY_DIR}/ipk" + The :ref:`package_ipk ` class uses the ``DEPLOY_DIR_IPK`` variable to make sure the :ref:`ref-tasks-package_write_ipk` task writes IPK packages into the appropriate folder. For more information - on how packaging works, see the "`Package - Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section + on how packaging works, see the ":ref:`Package + Feeds `" section in the Yocto Project Overview and Concepts Manual. - + DEPLOY_DIR_RPM Points to the area that the OpenEmbedded build system uses to place RPM packages that are ready to be used outside of the build system. This variable applies only when :term:`PACKAGE_CLASSES` contains "package_rpm". - + The BitBake configuration file initially defines this variable as a - sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_RPM = - "${DEPLOY_DIR}/rpm" - + sub-folder of :term:`DEPLOY_DIR`: + :: + + DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm" + The :ref:`package_rpm ` class uses the ``DEPLOY_DIR_RPM`` variable to make sure the :ref:`ref-tasks-package_write_rpm` task writes RPM packages into the appropriate folder. For more information - on how packaging works, see the "`Package - Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section + on how packaging works, see the ":ref:`Package + Feeds `" section in the Yocto Project Overview and Concepts Manual. - + DEPLOY_DIR_TAR Points to the area that the OpenEmbedded build system uses to place tarballs that are ready to be used outside of the build system. This variable applies only when :term:`PACKAGE_CLASSES` contains "package_tar". - + The BitBake configuration file initially defines this variable as a - sub-folder of :term:`DEPLOY_DIR`: DEPLOY_DIR_TAR = - "${DEPLOY_DIR}/tar" - + sub-folder of :term:`DEPLOY_DIR`: + :: + + DEPLOY_DIR_TAR = "${DEPLOY_DIR}/tar" + The :ref:`package_tar ` class uses the ``DEPLOY_DIR_TAR`` variable to make sure the :ref:`ref-tasks-package_write_tar` task writes TAR packages into the appropriate folder. For more information - on how packaging works, see the "`Package - Feeds <&YOCTO_DOCS_OM_URL;#package-feeds-dev-environment>`__" section + on how packaging works, see the ":ref:`Package + Feeds `" section in the Yocto Project Overview and Concepts Manual. - + DEPLOYDIR When inheriting the :ref:`deploy ` class, the ``DEPLOYDIR`` points to a temporary work area for deployed files that - is set in the ``deploy`` class as follows: DEPLOYDIR = - "${WORKDIR}/deploy-${:term:`PN`}" - + is set in the ``deploy`` class as follows: + :: + + DEPLOYDIR = "${WORKDIR}/deploy-${:term:`PN`}" + Recipes inheriting the ``deploy`` class should copy files to be deployed into ``DEPLOYDIR``, and the class will take care of copying them into :term:`DEPLOY_DIR_IMAGE` afterwards. - + DESCRIPTION The package description used by package managers. If not set, ``DESCRIPTION`` takes the value of the :term:`SUMMARY` variable. - + DISTRO The short name of the distribution. For information on the long name of the distribution, see the :term:`DISTRO_NAME` variable. - + The ``DISTRO`` variable corresponds to a distribution configuration file whose root name is the same as the variable's argument and whose filename extension is ``.conf``. For example, the distribution configuration file for the Poky distribution is named ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory of the :term:`Source Directory`. - + Within that ``poky.conf`` file, the ``DISTRO`` variable is set as - follows: DISTRO = "poky" - + follows: + :: + + DISTRO = "poky" + Distribution configuration files are located in a ``conf/distro`` directory within the :term:`Metadata` that contains the distribution configuration. The value for ``DISTRO`` must not contain spaces, and is typically all lower-case. - + .. note:: - + If the DISTRO variable is blank, a set of default configurations are used, which are specified within meta/conf/distro/defaultsetup.conf also in the Source Directory. - + DISTRO_CODENAME Specifies a codename for the distribution being built. - + DISTRO_EXTRA_RDEPENDS Specifies a list of distro-specific packages to add to all images. This variable takes affect through ``packagegroup-base`` so the @@ -1693,18 +1861,18 @@ system and gives an overview of their function and contents. include ``packagegroup-base``. You can use this variable to keep distro policy out of generic images. As with all other distro variables, you set this variable in the distro ``.conf`` file. - + DISTRO_EXTRA_RRECOMMENDS Specifies a list of distro-specific packages to add to all images if the packages exist. The packages might not exist or be empty (e.g. kernel modules). The list of packages are automatically installed but you can remove them. - + DISTRO_FEATURES The software support you want in your distribution for various features. You define your distribution features in the distribution configuration file. - + In most cases, the presence or absence of a feature in ``DISTRO_FEATURES`` is translated to the appropriate option supplied to the configure script during the @@ -1713,41 +1881,43 @@ system and gives an overview of their function and contents. ``DISTRO_FEATURES``, causes every piece of software built for the target that can optionally support X11 to have its X11 support enabled. - + Two more examples are Bluetooth and NFS support. For a more complete list of features that ships with the Yocto Project and that you can provide with this variable, see the "`Distro Features <#ref-features-distro>`__" section. - + DISTRO_FEATURES_BACKFILL Features to be added to ``DISTRO_FEATURES`` if not also present in ``DISTRO_FEATURES_BACKFILL_CONSIDERED``. - + This variable is set in the ``meta/conf/bitbake.conf`` file. It is not intended to be user-configurable. It is best to just reference the variable to see which distro features are being backfilled for all distro configurations. See the "`Feature Backfilling <#ref-features-backfill>`__" section for more information. - + DISTRO_FEATURES_BACKFILL_CONSIDERED Features from ``DISTRO_FEATURES_BACKFILL`` that should not be backfilled (i.e. added to ``DISTRO_FEATURES``) during the build. See the "`Feature Backfilling <#ref-features-backfill>`__" section for more information. - + DISTRO_FEATURES_DEFAULT A convenience variable that gives you the default list of distro features with the exception of any features specific to the C library (``libc``). - + When creating a custom distribution, you might find it useful to be able to reuse the default :term:`DISTRO_FEATURES` options without the need to write out the full set. Here is an example that uses ``DISTRO_FEATURES_DEFAULT`` from a custom distro configuration file: - DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature" - + :: + + DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} myfeature" + DISTRO_FEATURES_FILTER_NATIVE Specifies a list of features that if present in the target :term:`DISTRO_FEATURES` value should be @@ -1755,7 +1925,7 @@ system and gives an overview of their function and contents. variable is used in addition to the features filtered using the :term:`DISTRO_FEATURES_NATIVE` variable. - + DISTRO_FEATURES_FILTER_NATIVESDK Specifies a list of features that if present in the target :term:`DISTRO_FEATURES` value should be @@ -1763,7 +1933,7 @@ system and gives an overview of their function and contents. variable is used in addition to the features filtered using the :term:`DISTRO_FEATURES_NATIVESDK` variable. - + DISTRO_FEATURES_NATIVE Specifies a list of features that should be included in :term:`DISTRO_FEATURES` when building native @@ -1771,7 +1941,7 @@ system and gives an overview of their function and contents. using the :term:`DISTRO_FEATURES_FILTER_NATIVE` variable. - + DISTRO_FEATURES_NATIVESDK Specifies a list of features that should be included in :term:`DISTRO_FEATURES` when building @@ -1779,49 +1949,52 @@ system and gives an overview of their function and contents. filtered using the :term:`DISTRO_FEATURES_FILTER_NATIVESDK` variable. - + DISTRO_NAME The long name of the distribution. For information on the short name of the distribution, see the :term:`DISTRO` variable. - + The ``DISTRO_NAME`` variable corresponds to a distribution configuration file whose root name is the same as the variable's argument and whose filename extension is ``.conf``. For example, the distribution configuration file for the Poky distribution is named ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory of the :term:`Source Directory`. - + Within that ``poky.conf`` file, the ``DISTRO_NAME`` variable is set - as follows: DISTRO_NAME = "Poky (Yocto Project Reference Distro)" - + as follows: + :: + + DISTRO_NAME = "Poky (Yocto Project Reference Distro)" + Distribution configuration files are located in a ``conf/distro`` directory within the :term:`Metadata` that contains the distribution configuration. - + .. note:: - + If the DISTRO_NAME variable is blank, a set of default configurations are used, which are specified within meta/conf/distro/defaultsetup.conf also in the Source Directory. - + DISTRO_VERSION The version of the distribution. - + DISTROOVERRIDES A colon-separated list of overrides specific to the current distribution. By default, this list includes the value of :term:`DISTRO`. - + You can extend ``DISTROOVERRIDES`` to add extra overrides that should apply to the distribution. - + The underlying mechanism behind ``DISTROOVERRIDES`` is simply that it is included in the default value of :term:`OVERRIDES`. - + DL_DIR The central download directory used by the build process to store downloads. By default, ``DL_DIR`` gets files suitable for mirroring @@ -1829,25 +2002,29 @@ system and gives an overview of their function and contents. repositories, use the :term:`BB_GENERATE_MIRROR_TARBALLS` variable. - + You can set this directory by defining the ``DL_DIR`` variable in the ``conf/local.conf`` file. This directory is self-maintaining and you should not have to touch it. By default, the directory is - ``downloads`` in the :term:`Build Directory`. #DL_DIR - ?= "${TOPDIR}/downloads" To specify a different download directory, + ``downloads`` in the :term:`Build Directory`. + :: + + #DL_DIR ?= "${TOPDIR}/downloads" + + To specify a different download directory, simply remove the comment from the line and provide your directory. - + During a first build, the system downloads many different source code tarballs from various upstream projects. Downloading can take a while, particularly if your network connection is slow. Tarballs are all stored in the directory defined by ``DL_DIR`` and the build system looks there first to find source tarballs. - + .. note:: - + When wiping and rebuilding, you can preserve this directory to speed up this part of subsequent builds. - + You can safely share this directory between multiple builds on the same development machine. For additional information on how the build process gets source files when working behind a firewall or proxy @@ -1856,58 +2033,61 @@ system and gives an overview of their function and contents. chapter. You can also refer to the ":yocto_wiki:`Working Behind a Network Proxy `" Wiki page. - + DOC_COMPRESS When inheriting the :ref:`compress_doc ` class, this variable sets the compression policy used when the OpenEmbedded build system compresses man pages and info pages. By default, the compression method used is gz (gzip). Other policies available are xz and bz2. - + For information on policies and on how to use this variable, see the comments in the ``meta/classes/compress_doc.bbclass`` file. - + EFI_PROVIDER When building bootable images (i.e. where ``hddimg``, ``iso``, or ``wic.vmdk`` is in :term:`IMAGE_FSTYPES`), the ``EFI_PROVIDER`` variable specifies the EFI bootloader to use. The default is "grub-efi", but "systemd-boot" can be used instead. - + See the :ref:`systemd-boot ` and :ref:`image-live ` classes for more information. - + ENABLE_BINARY_LOCALE_GENERATION Variable that controls which locales for ``glibc`` are generated during the build (useful if the target device has 64Mbytes of RAM or less). - + ERR_REPORT_DIR When used with the :ref:`report-error ` class, specifies the path used for storing the debug files created by - the `error reporting - tool <&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool>`__, which + the :ref:`error reporting + tool `, which allows you to submit build errors you encounter to a central database. By default, the value of this variable is ``${``\ :term:`LOG_DIR`\ ``}/error-report``. - + You can set ``ERR_REPORT_DIR`` to the path you want the error reporting tool to store the debug files as follows in your - ``local.conf`` file: ERR_REPORT_DIR = "path" - + ``local.conf`` file: + :: + + ERR_REPORT_DIR = "path" + ERROR_QA Specifies the quality assurance checks whose failures are reported as errors by the OpenEmbedded build system. You set this variable in your distribution configuration file. For a list of the checks you can control with this variable, see the ":ref:`insane.bbclass `" section. - + EXCLUDE_FROM_SHLIBS Triggers the OpenEmbedded build system's shared libraries resolver to exclude an entire package when scanning for shared libraries. - + .. note:: - + The shared libraries resolver's functionality results in part from the internal function package_do_shlibs @@ -1915,25 +2095,28 @@ system and gives an overview of their function and contents. do_package task. You should be aware that the shared libraries resolver might implicitly define some dependencies between packages. - + The ``EXCLUDE_FROM_SHLIBS`` variable is similar to the :term:`PRIVATE_LIBS` variable, which excludes a package's particular libraries only and not the whole package. - + Use the ``EXCLUDE_FROM_SHLIBS`` variable by setting it to "1" for a - particular package: EXCLUDE_FROM_SHLIBS = "1" - + particular package: + :: + + EXCLUDE_FROM_SHLIBS = "1" + 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. - + .. note:: - + Recipes added to EXCLUDE_FROM_WORLD may still be built during a world build in order to satisfy @@ -1941,52 +2124,53 @@ system and gives an overview of their function and contents. EXCLUDE_FROM_WORLD only ensures that the recipe is not explicitly added to the list of build targets in a world build. - + EXTENDPE Used with file and pathnames to create a prefix for a recipe's version based on the recipe's :term:`PE` value. If ``PE`` is set and greater than zero for a recipe, ``EXTENDPE`` becomes that - value (e.g if ``PE`` is equal to "1" then ``EXTENDPE`` becomes "1_"). + value (e.g if ``PE`` is equal to "1" then ``EXTENDPE`` becomes "1"). If a recipe's ``PE`` is not set (the default) or is equal to zero, ``EXTENDPE`` becomes "". - + See the :term:`STAMP` variable for an example. - + EXTENDPKGV The full package version specification as it appears on the final packages produced by a recipe. The variable's value is normally used to fix a runtime dependency to the exact same version of another - package in the same recipe: RDEPENDS_${PN}-additional-module = "${PN} - (= ${EXTENDPKGV})" - + package in the same recipe: + :: + + RDEPENDS_${PN}-additional-module = "${PN} (= ${EXTENDPKGV})" + The dependency relationships are intended to force the package manager to upgrade these types of packages in lock-step. - + EXTERNAL_KERNEL_TOOLS When set, the ``EXTERNAL_KERNEL_TOOLS`` variable indicates that these tools are not in the source tree. - + When kernel tools are available in the tree, they are preferred over any externally installed tools. Setting the ``EXTERNAL_KERNEL_TOOLS`` variable tells the OpenEmbedded build system to prefer the installed external tools. See the :ref:`kernel-yocto ` class in ``meta/classes`` to see how the variable is used. - + EXTERNALSRC When inheriting the :ref:`externalsrc ` class, this variable points to the source tree, which is outside of the OpenEmbedded build system. When set, this variable sets the :term:`S` variable, which is what the OpenEmbedded build system uses to locate unpacked recipe source code. - + For more information on ``externalsrc.bbclass``, see the ":ref:`externalsrc.bbclass `" section. You can also find information on how to use this variable in the - "`Building Software from an External - Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__" + ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`" section in the Yocto Project Development Tasks Manual. - + EXTERNALSRC_BUILD When inheriting the :ref:`externalsrc ` class, this variable points to the directory in which the recipe's @@ -1994,121 +2178,124 @@ system and gives an overview of their function and contents. system. When set, this variable sets the :term:`B` variable, which is what the OpenEmbedded build system uses to locate the Build Directory. - + For more information on ``externalsrc.bbclass``, see the ":ref:`externalsrc.bbclass `" section. You can also find information on how to use this variable in the - "`Building Software from an External - Source <&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source>`__" + ":ref:`dev-manual/dev-manual-common-tasks:building software from an external source`" section in the Yocto Project Development Tasks Manual. - + EXTRA_AUTORECONF For recipes inheriting the :ref:`autotools ` class, you can use ``EXTRA_AUTORECONF`` to specify extra options to pass to the ``autoreconf`` command that is executed during the :ref:`ref-tasks-configure` task. - + The default value is "--exclude=autopoint". - + EXTRA_IMAGE_FEATURES A list of additional features to include in an image. When listing more than one feature, separate them with a space. - + Typically, you configure this variable in your ``local.conf`` file, which is found in the :term:`Build Directory`. Although you can use this variable from within a recipe, best practices dictate that you do not. - + .. note:: - + To enable primary features from within the image recipe, use the IMAGE_FEATURES variable. - - Here are some examples of features you can add: "dbg-pkgs" - Adds - -dbg packages for all installed packages including symbol information - for debugging and profiling. "debug-tweaks" - Makes an image suitable - for debugging. For example, allows root logins without passwords and - enables post-installation logging. See the 'allow-empty-password' and - 'post-install-logging' features in the "`Image - Features <#ref-features-image>`__" section for more information. - "dev-pkgs" - Adds -dev packages for all installed packages. This is - useful if you want to develop against the libraries in the image. - "read-only-rootfs" - Creates an image whose root filesystem is - read-only. See the "`Creating a Read-Only Root - Filesystem <&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem>`__" - section in the Yocto Project Development Tasks Manual for more - information "tools-debug" - Adds debugging tools such as gdb and - strace. "tools-sdk" - Adds development tools such as gcc, make, - pkgconfig and so forth. "tools-testapps" - Adds useful testing tools - such as ts_print, aplay, arecord and so forth. - + + Here are some examples of features you can add: + + - "dbg-pkgs" - Adds -dbg packages for all installed packages including + symbol information for debugging and profiling. + + - "debug-tweaks" - Makes an image suitable for debugging. For example, allows root logins without passwords and + enables post-installation logging. See the 'allow-empty-password' and + 'post-install-logging' features in the "`Image + Features <#ref-features-image>`__" section for more information. + - "dev-pkgs" - Adds -dev packages for all installed packages. This is + useful if you want to develop against the libraries in the image. + - "read-only-rootfs" - Creates an image whose root filesystem is + read-only. See the + ":ref:`dev-manual/dev-manual-common-tasks:creating a read-only root filesystem`" + section in the Yocto Project Development Tasks Manual for more + information + - "tools-debug" - Adds debugging tools such as gdb and strace. + - "tools-sdk" - Adds development tools such as gcc, make, + pkgconfig and so forth. + - "tools-testapps" - Adds useful testing tools + such as ts_print, aplay, arecord and so forth. + For a complete list of image features that ships with the Yocto Project, see the "`Image Features <#ref-features-image>`__" section. - + For an example that shows how to customize your image by using this - variable, see the "`Customizing Images Using Custom - ``IMAGE_FEATURES`` and - ``EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures>`__" + variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`" section in the Yocto Project Development Tasks Manual. - + EXTRA_IMAGECMD Specifies additional options for the image creation command that has been specified in :term:`IMAGE_CMD`. When setting this variable, use an override for the associated image type. Here is - an example: EXTRA_IMAGECMD_ext3 ?= "-i 4096" - + an example: + :: + + EXTRA_IMAGECMD_ext3 ?= "-i 4096" + EXTRA_IMAGEDEPENDS A list of recipes to build that do not provide packages for installing into the root filesystem. - + Sometimes a recipe is required to build the final image but is not needed in the root filesystem. You can use the ``EXTRA_IMAGEDEPENDS`` variable to list these recipes and thus specify the dependencies. A typical example is a required bootloader in a machine configuration. - + .. note:: - + To add packages to the root filesystem, see the various - \* - RDEPENDS - and - \* - RRECOMMENDS + \*RDEPENDS and \*RRECOMMENDS variables. - + EXTRANATIVEPATH A list of subdirectories of ``${``\ :term:`STAGING_BINDIR_NATIVE`\ ``}`` added to the beginning of the environment variable ``PATH``. As an example, the following prepends "${STAGING_BINDIR_NATIVE}/foo:${STAGING_BINDIR_NATIVE}/bar:" to - ``PATH``: EXTRANATIVEPATH = "foo bar" - + ``PATH``: + :: + + EXTRANATIVEPATH = "foo bar" + EXTRA_OECMAKE Additional `CMake `__ options. See the :ref:`cmake ` class for additional information. - + EXTRA_OECONF Additional ``configure`` script options. See :term:`PACKAGECONFIG_CONFARGS` for additional information on passing configure script options. - + EXTRA_OEMAKE Additional GNU ``make`` options. - + Because the ``EXTRA_OEMAKE`` defaults to "", you need to set the variable to specify any required GNU options. - + :term:`PARALLEL_MAKE` and :term:`PARALLEL_MAKEINST` also make use of ``EXTRA_OEMAKE`` to pass the required flags. - + EXTRA_OESCONS When inheriting the :ref:`scons ` class, this variable specifies additional configuration options you want to pass to the ``scons`` command line. - + EXTRA_USERS_PARAMS When inheriting the :ref:`extrausers ` class, this variable provides image level user and group operations. @@ -2116,26 +2303,35 @@ system and gives an overview of their function and contents. configuration as compared to using the :ref:`useradd ` class, which ties user and group configurations to a specific recipe. - + The set list of commands you can configure using the ``EXTRA_USERS_PARAMS`` is shown in the ``extrausers`` class. These - commands map to the normal Unix commands of the same names: # - EXTRA_USERS_PARAMS = "\\ # useradd -p '' tester; \\ # groupadd - developers; \\ # userdel nobody; \\ # groupdel -g video; \\ # - groupmod -g 1020 developers; \\ # usermod -s /bin/sh tester; \\ # " - + commands map to the normal Unix commands of the same names: + :: + + # EXTRA_USERS_PARAMS = "\ + # useradd -p '' tester; \ + # groupadd developers; \ + # userdel nobody; \ + # groupdel -g video; \ + # groupmod -g 1020 developers; \ + # usermod -s /bin/sh tester; \ + # " + FEATURE_PACKAGES Defines one or more packages to include in an image when a specific item is included in :term:`IMAGE_FEATURES`. When setting the value, ``FEATURE_PACKAGES`` should have the name of the feature item as an override. Here is an example: - FEATURE_PACKAGES_widget = "package1 package2" - + :: + + FEATURE_PACKAGES_widget = "package1 package2" + In this example, if "widget" were added to ``IMAGE_FEATURES``, package1 and package2 would be included in the image. - + .. note:: - + Packages installed by features defined through FEATURE_PACKAGES are often package groups. While similarly named, you should not @@ -2143,40 +2339,46 @@ system and gives an overview of their function and contents. FEATURE_PACKAGES variable with package groups, which are discussed elsewhere in the documentation. - + FEED_DEPLOYDIR_BASE_URI Points to the base URL of the server and location within the document-root that provides the metadata and packages required by OPKG to support runtime package management of IPK packages. You set this variable in your ``local.conf`` file. - - Consider the following example: FEED_DEPLOYDIR_BASE_URI = - "http://192.168.7.1/BOARD-dir" This example assumes you are serving + + Consider the following example: + :: + + FEED_DEPLOYDIR_BASE_URI = "http://192.168.7.1/BOARD-dir" + + This example assumes you are serving your packages over HTTP and your databases are located in a directory named ``BOARD-dir``, which is underneath your HTTP server's document-root. In this case, the OpenEmbedded build system generates a set of configuration files for you in your target that work with the feed. - + FILES The list of files and directories that are placed in a package. The :term:`PACKAGES` variable lists the packages generated by a recipe. - + To use the ``FILES`` variable, provide a package name override that identifies the resulting package. Then, provide a space-separated list of files or paths that identify the files you want included as - part of the resulting package. Here is an example: FILES_${PN} += - "${bindir}/mydir1 ${bindir}/mydir2/myfile" - + part of the resulting package. Here is an example: + :: + + FILES_${PN} += "${bindir}/mydir1 ${bindir}/mydir2/myfile" + .. note:: - + - When specifying files or paths, you can pattern match using Python's - ```glob`https://docs.python.org/2/library/glob.html + `glob `_ syntax. For details on the syntax, see the documentation by following the previous link. - + - When specifying paths as part of the ``FILES`` variable, it is good practice to use appropriate path variables. For example, use ``${sysconfdir}`` rather than ``/etc``, or ``${bindir}`` @@ -2185,24 +2387,26 @@ system and gives an overview of their function and contents. the :term:`Source Directory`. You will also find the default values of the various ``FILES_*`` variables in this file. - + If some of the files you provide with the ``FILES`` variable are editable and you know they should not be overwritten during the package update process by the Package Management System (PMS), you can identify these files so that the PMS will not overwrite them. See the :term:`CONFFILES` variable for information on how to identify these files to the PMS. - + FILES_SOLIBSDEV Defines the file specification to match :term:`SOLIBSDEV`. In other words, ``FILES_SOLIBSDEV`` defines the full path name of the development symbolic link (symlink) for shared libraries on the target platform. - + The following statement from the ``bitbake.conf`` shows how it is - set: FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} - ${libdir}/lib*${SOLIBSDEV}" - + set: + :: + + FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}" + FILESEXTRAPATHS Extends the search path the OpenEmbedded build system uses when looking for files and patches as it processes recipes and append @@ -2210,58 +2414,71 @@ system and gives an overview of their function and contents. are initially defined by the :term:`FILESPATH` variable. You can extend ``FILESPATH`` variable by using ``FILESEXTRAPATHS``. - + Best practices dictate that you accomplish this by using ``FILESEXTRAPATHS`` from within a ``.bbappend`` file and that you - prepend paths as follows: FILESEXTRAPATHS_prepend := - "${THISDIR}/${PN}:" In the above example, the build system first + prepend paths as follows: + :: + + FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" + + In the above example, the build system first looks for files in a directory that has the same name as the corresponding append file. - + .. note:: - + When extending ``FILESEXTRAPATHS``, be sure to use the immediate expansion (``:=``) operator. Immediate expansion makes sure that BitBake evaluates :term:`THISDIR` at the time the directive is encountered rather than at some later time when expansion might result in a directory that does not contain the files you need. - + Also, include the trailing separating colon character if you are prepending. The trailing colon character is necessary because you are directing BitBake to extend the path by prepending directories to the search path. - - Here is another common use: FILESEXTRAPATHS_prepend := - "${THISDIR}/files:" In this example, the build system extends the + + Here is another common use: + :: + + FILESEXTRAPATHS_prepend := "${THISDIR}/files:" + + In this example, the build system extends the ``FILESPATH`` variable to include a directory named ``files`` that is in the same directory as the corresponding append file. - + This next example specifically adds three paths: - FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:" - + :: + + FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:" + A final example shows how you can extend the search path and include a :term:`MACHINE`-specific override, which is useful - in a BSP layer: FILESEXTRAPATHS_prepend_intel-x86-common := - "${THISDIR}/${PN}:" The previous statement appears in the - ``linux-yocto-dev.bbappend`` file, which is found in the Yocto - Project `Source - Repositories <&YOCTO_DOCS_OM_URL;#source-repositories>`__ in + in a BSP layer: + :: + + FILESEXTRAPATHS_prepend_intel-x86-common := "${THISDIR}/${PN}:" + + The previous statement appears in the + ``linux-yocto-dev.bbappend`` file, which is found in the + :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories` in ``meta-intel/common/recipes-kernel/linux``. Here, the machine override is a special :term:`PACKAGE_ARCH` definition for multiple ``meta-intel`` machines. - + .. note:: - + For a layer that supports a single BSP, the override could just be the value of MACHINE . - + By prepending paths in ``.bbappend`` files, you allow multiple append files that reside in different layers but are used for the same recipe to correctly extend the path. - + FILESOVERRIDES A subset of :term:`OVERRIDES` used by the OpenEmbedded build system for creating @@ -2273,53 +2490,63 @@ system and gives an overview of their function and contents. are handled in the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`" section of the BitBake User Manual. - + By default, the ``FILESOVERRIDES`` variable is defined as: - FILESOVERRIDES = - "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}" - + :: + + FILESOVERRIDES = "${TRANSLATED_TARGET_ARCH}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}" + .. note:: - + Do not hand-edit the FILESOVERRIDES variable. The values match up with expected overrides and are used in an expected manner by the build system. - + FILESPATH The default set of directories the OpenEmbedded build system uses when searching for patches and files. - + During the build process, BitBake searches each directory in ``FILESPATH`` in the specified order when looking for files and patches specified by each ``file://`` URI in a recipe's :term:`SRC_URI` statements. - + The default value for the ``FILESPATH`` variable is defined in the ``base.bbclass`` class found in ``meta/classes`` in the - :term:`Source Directory`: FILESPATH = - "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \\ - "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" The + :term:`Source Directory`: + :: + + FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \ + "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}" + + The ``FILESPATH`` variable is automatically extended using the overrides from the :term:`FILESOVERRIDES` variable. - + .. note:: - + - Do not hand-edit the ``FILESPATH`` variable. If you want the build system to look in directories other than the defaults, extend the ``FILESPATH`` variable by using the :term:`FILESEXTRAPATHS` variable. - + - Be aware that the default ``FILESPATH`` directories do not map to directories in custom layers where append files (``.bbappend``) are used. If you want the build system to find patches or files that reside with your append files, you need to extend the ``FILESPATH`` variable by using the ``FILESEXTRAPATHS`` variable. - + You can take advantage of this searching behavior in useful ways. For example, consider a case where the following directory structure exists for general and machine-specific configurations: - files/defconfig files/MACHINEA/defconfig files/MACHINEB/defconfig + :: + + files/defconfig + files/MACHINEA/defconfig + files/MACHINEB/defconfig + Also in the example, the ``SRC_URI`` statement contains "file://defconfig". Given this scenario, you can set :term:`MACHINE` to "MACHINEA" and cause the build @@ -2327,37 +2554,37 @@ system and gives an overview of their function and contents. "MACHINEB" and the build system uses files from ``files/MACHINEB``. Finally, for any machine other than "MACHINEA" and "MACHINEB", the build system uses files from ``files/defconfig``. - + You can find out more about the patching process in the - "`Patching <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__" section - in the Yocto Project Overview and Concepts Manual and the "`Patching - Code <&YOCTO_DOCS_DEV_URL;#new-recipe-patching-code>`__" section in + ":ref:`patching-dev-environment`" section + in the Yocto Project Overview and Concepts Manual and the + ":ref:`new-recipe-patching-code`" section in the Yocto Project Development Tasks Manual. See the :ref:`ref-tasks-patch` task as well. - + FILESYSTEM_PERMS_TABLES Allows you to define your own file permissions settings table as part of your configuration for the packaging process. For example, suppose you need a consistent set of custom permissions for a set of groups and users across an entire work project. It is best to do this in the packages themselves but this is not always possible. - + By default, the OpenEmbedded build system uses the ``fs-perms.txt``, which is located in the ``meta/files`` folder in the :term:`Source Directory`. If you create your own file permissions setting table, you should place it in your layer or the distro's layer. - + You define the ``FILESYSTEM_PERMS_TABLES`` variable in the ``conf/local.conf`` file, which is found in the :term:`Build Directory`, to point to your custom ``fs-perms.txt``. You can specify more than a single file permissions setting table. The paths you specify to these files must be defined within the :term:`BBPATH` variable. - + For guidance on how to create your own file permissions settings table file, examine the existing ``fs-perms.txt``. - + FIT_HASH_ALG Specifies the hash algorithm used in creating the FIT Image. For e.g. sha256. @@ -2369,7 +2596,7 @@ system and gives an overview of their function and contents. When inheriting the :ref:`fontcache ` class, this variable specifies the runtime dependencies for font packages. By default, the ``FONT_EXTRA_RDEPENDS`` is set to "fontconfig-utils". - + FONT_PACKAGES When inheriting the :ref:`fontcache ` class, this variable identifies packages containing font files that need to @@ -2377,168 +2604,189 @@ system and gives an overview of their function and contents. that fonts are in the recipe's main package (i.e. ``${``\ :term:`PN`\ ``}``). Use this variable if fonts you need are in a package other than that main package. - + FORCE_RO_REMOVE Forces the removal of the packages listed in ``ROOTFS_RO_UNNEEDED`` during the generation of the root filesystem. - + Set the variable to "1" to force the removal of these packages. - + FULL_OPTIMIZATION The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when compiling an optimized system. This variable defaults to "-O2 -pipe ${DEBUG_FLAGS}". - + GCCPIE Enables Position Independent Executables (PIE) within the GNU C Compiler (GCC). Enabling PIE in the GCC makes Return Oriented Programming (ROP) attacks much more difficult to execute. - + By default the ``security_flags.inc`` file enables PIE by setting the - variable as follows: GCCPIE ?= "--enable-default-pie" - + variable as follows: + :: + + GCCPIE ?= "--enable-default-pie" + GCCVERSION Specifies the default version of the GNU C Compiler (GCC) used for compilation. By default, ``GCCVERSION`` is set to "8.x" in the ``meta/conf/distro/include/tcmode-default.inc`` include file: - GCCVERSION ?= "8.%" You can override this value by setting it in a + :: + + GCCVERSION ?= "8.%" + + You can override this value by setting it in a configuration file such as the ``local.conf``. - + GDB The minimal command and arguments to run the GNU Debugger. - + GITDIR The directory in which a local copy of a Git repository is stored when it is cloned. - + GLIBC_GENERATE_LOCALES Specifies the list of GLIBC locales to generate should you not wish to generate all LIBC locals, which can be time consuming. - + .. note:: - + If you specifically remove the locale en_US.UTF-8 , you must set IMAGE_LINGUAS appropriately. - + You can set ``GLIBC_GENERATE_LOCALES`` in your ``local.conf`` file. - By default, all locales are generated. GLIBC_GENERATE_LOCALES = - "en_GB.UTF-8 en_US.UTF-8" - + By default, all locales are generated. + :: + + GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8" + GROUPADD_PARAM When inheriting the :ref:`useradd ` class, this variable specifies for a package what parameters should be passed to the ``groupadd`` command if you wish to add a group to the system when the package is installed. - - Here is an example from the ``dbus`` recipe: GROUPADD_PARAM_${PN} = - "-r netdev" For information on the standard Linux shell command + + Here is an example from the ``dbus`` recipe: + :: + + GROUPADD_PARAM_${PN} = "-r netdev" + + For information on the standard Linux shell command ``groupadd``, see http://linux.die.net/man/8/groupadd. - + GROUPMEMS_PARAM When inheriting the :ref:`useradd ` class, this variable specifies for a package what parameters should be passed to the ``groupmems`` command if you wish to modify the members of a group when the package is installed. - + For information on the standard Linux shell command ``groupmems``, see http://linux.die.net/man/8/groupmems. - + GRUB_GFXSERIAL Configures the GNU GRand Unified Bootloader (GRUB) to have graphics and serial in the boot menu. Set this variable to "1" in your ``local.conf`` or distribution configuration file to enable graphics and serial in the menu. - + See the :ref:`grub-efi ` class for more information on how this variable is used. - + GRUB_OPTS Additional options to add to the GNU GRand Unified Bootloader (GRUB) configuration. Use a semi-colon character (``;``) to separate multiple options. - + The ``GRUB_OPTS`` variable is optional. See the :ref:`grub-efi ` class for more information on how this variable is used. - + GRUB_TIMEOUT Specifies the timeout before executing the default ``LABEL`` in the GNU GRand Unified Bootloader (GRUB). - + The ``GRUB_TIMEOUT`` variable is optional. See the :ref:`grub-efi ` class for more information on how this variable is used. - + GTKIMMODULES_PACKAGES When inheriting the :ref:`gtk-immodules-cache ` class, this variable specifies the packages that contain the GTK+ input method modules being installed when the modules are in packages other than the main package. - + HOMEPAGE Website where more information about the software the recipe is building can be found. - + HOST_ARCH The name of the target architecture, which is normally the same as :term:`TARGET_ARCH`. The OpenEmbedded build system supports many architectures. Here is an example list of architectures supported. This list is by no means complete as the architecture is - configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel - + configurable: + + - arm + - i586 + - x86_64 + - powerpc + - powerpc64 + - mips + - mipsel + HOST_CC_ARCH Specifies architecture-specific compiler flags that are passed to the C compiler. - + Default initialization for ``HOST_CC_ARCH`` varies depending on what is being built: - + - :term:`TARGET_CC_ARCH` when building for the target - + - ``BUILD_CC_ARCH`` when building for the build host (i.e. ``-native``) - + - ``BUILDSDK_CC_ARCH`` when building for an SDK (i.e. ``nativesdk-``) - + HOST_OS Specifies the name of the target operating system, which is normally the same as the :term:`TARGET_OS`. The variable can be set to "linux" for ``glibc``-based systems and to "linux-musl" for ``musl``. For ARM/EABI targets, there are also "linux-gnueabi" and "linux-musleabi" values possible. - + HOST_PREFIX Specifies the prefix for the cross-compile toolchain. ``HOST_PREFIX`` is normally the same as :term:`TARGET_PREFIX`. - + HOST_SYS Specifies the system, including the architecture and the operating system, for which the build is occurring in the context of the current recipe. - + The OpenEmbedded build system automatically sets this variable based on :term:`HOST_ARCH`, :term:`HOST_VENDOR`, and :term:`HOST_OS` variables. - + .. note:: - + You do not need to set the variable yourself. - + Consider these two examples: - + - Given a native recipe on a 32-bit x86 machine running Linux, the value is "i686-linux". - + - Given a recipe being built for a little-endian MIPS target running Linux, the value might be "mipsel-linux". - + HOSTTOOLS A space-separated list (filter) of tools on the build host that should be allowed to be called from within build tasks. Using this @@ -2546,10 +2794,10 @@ system and gives an overview of their function and contents. specified in the value of ``HOSTTOOLS`` is not found on the build host, the OpenEmbedded build system produces an error and the build is not started. - + For additional information, see :term:`HOSTTOOLS_NONFATAL`. - + HOSTTOOLS_NONFATAL A space-separated list (filter) of tools on the build host that should be allowed to be called from within build tasks. Using this @@ -2558,44 +2806,51 @@ system and gives an overview of their function and contents. does not produce an error if a tool specified in the value of ``HOSTTOOLS_NONFATAL`` is not found on the build host. Thus, you can use ``HOSTTOOLS_NONFATAL`` to filter optional host tools. - + HOST_VENDOR Specifies the name of the vendor. ``HOST_VENDOR`` is normally the same as :term:`TARGET_VENDOR`. - + ICECC_DISABLED Disables or enables the ``icecc`` (Icecream) function. For more information on this function and best practices for using this variable, see the ":ref:`icecc.bbclass `" section. - + Setting this variable to "1" in your ``local.conf`` disables the - function: ICECC_DISABLED ??= "1" To enable the function, set the - variable as follows: ICECC_DISABLED = "" - + function: + :: + + ICECC_DISABLED ??= "1" + + To enable the function, set the variable as follows: + :: + + ICECC_DISABLED = "" + ICECC_ENV_EXEC Points to the ``icecc-create-env`` script that you provide. This variable is used by the :ref:`icecc ` class. You set this variable in your ``local.conf`` file. - + If you do not point to a script that you provide, the OpenEmbedded build system uses the default script provided by the ``icecc-create-env.bb`` recipe, which is a modified version and not the one that comes with ``icecc``. - + ICECC_PARALLEL_MAKE Extra options passed to the ``make`` command during the :ref:`ref-tasks-compile` task that specify parallel compilation. This variable usually takes the form of "-j x", where x represents the maximum number of parallel threads ``make`` can run. - + .. note:: - + The options passed affect builds on all enabled machines on the network, which are machines running the iceccd daemon. - + If your enabled machines support multiple cores, coming up with the maximum number of parallel threads that gives you the best performance could take some experimentation since machine speed, @@ -2604,37 +2859,37 @@ system and gives an overview of their function and contents. :term:`PARALLEL_MAKE` variable, there is no rule-of-thumb for setting ``ICECC_PARALLEL_MAKE`` to achieve optimal performance. - + If you do not set ``ICECC_PARALLEL_MAKE``, the build system does not use it (i.e. the system does not detect and assign the number of cores as is done with ``PARALLEL_MAKE``). - + ICECC_PATH The location of the ``icecc`` binary. You can set this variable in your ``local.conf`` file. If your ``local.conf`` file does not define this variable, the :ref:`icecc ` class attempts to define it by locating ``icecc`` using ``which``. - + ICECC_USER_CLASS_BL Identifies user classes that you do not want the Icecream distributed compile support to consider. This variable is used by the :ref:`icecc ` class. You set this variable in your ``local.conf`` file. - + When you list classes using this variable, you are "blacklisting" them from distributed compilation across remote hosts. Any classes you list will be distributed and compiled locally. - + ICECC_USER_PACKAGE_BL Identifies user recipes that you do not want the Icecream distributed compile support to consider. This variable is used by the :ref:`icecc ` class. You set this variable in your ``local.conf`` file. - + When you list packages using this variable, you are "blacklisting" them from distributed compilation across remote hosts. Any packages you list will be distributed and compiled locally. - + ICECC_USER_PACKAGE_WL Identifies user recipes that use an empty :term:`PARALLEL_MAKE` variable that you want to @@ -2642,67 +2897,76 @@ system and gives an overview of their function and contents. distributed compile support. This variable is used by the :ref:`icecc ` class. You set this variable in your ``local.conf`` file. - + IMAGE_BASENAME The base name of image output files. This variable defaults to the recipe name (``${``\ :term:`PN`\ ``}``). - + IMAGE_BOOT_FILES A space-separated list of files installed into the boot partition when preparing an image using the Wic tool with the - ``bootimg-partition`` or ``bootimg-efi`` source plugin. By default, + ``bootimg-partition`` or ``bootimg-efi`` source plugin. By default, the files are installed under the same name as the source files. To change the installed name, separate it from the original name with a semi-colon (;). Source files need to be located in :term:`DEPLOY_DIR_IMAGE`. Here are two - examples: IMAGE_BOOT_FILES = "u-boot.img uImage;kernel" - IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}" - + examples: + :: + + IMAGE_BOOT_FILES = "u-boot.img uImage;kernel" + IMAGE_BOOT_FILES = "u-boot.${UBOOT_SUFFIX} ${KERNEL_IMAGETYPE}" + Alternatively, source files can be picked up using a glob pattern. In this case, the destination file must have the same name as the base name of the source file path. To install files into a directory within the target location, pass its name after a semi-colon (;). - Here are two examples: IMAGE_BOOT_FILES = "bcm2835-bootfiles/*" - IMAGE_BOOT_FILES = "bcm2835-bootfiles/*;boot/" The first example + Here are two examples: + :: + + IMAGE_BOOT_FILES = "bcm2835-bootfiles/*" + IMAGE_BOOT_FILES = "bcm2835-bootfiles/*;boot/" + + The first example installs all files from ``${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles`` into the root of the target partition. The second example installs the same files into a ``boot`` directory within the target partition. - - You can find information on how to use the Wic tool in the "`Creating - Partitioned Images Using - Wic <&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic>`__" + + You can find information on how to use the Wic tool in the + ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`" section of the Yocto Project Development Tasks Manual. Reference - material for Wic is located in the "`OpenEmbedded Kickstart (.wks) - Reference <&YOCTO_DOCS_REF_URL;#ref-kickstart>`__" chapter. - + material for Wic is located in the + ":doc:`../ref-manual/ref-kickstart`" chapter. + IMAGE_CLASSES A list of classes that all images should inherit. You typically use this variable to specify the list of classes that register the different types of images the OpenEmbedded build system creates. - + The default value for ``IMAGE_CLASSES`` is ``image_types``. You can set this variable in your ``local.conf`` or in a distribution configuration file. - + For more information, see ``meta/classes/image_types.bbclass`` in the :term:`Source Directory`. - + IMAGE_CMD Specifies the command to create the image file for a specific image type, which corresponds to the value set set in :term:`IMAGE_FSTYPES`, (e.g. ``ext3``, ``btrfs``, and so forth). When setting this variable, you should use an override for the associated type. Here is an example: - IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \\ --faketime - --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \\ - ${EXTRA_IMAGECMD}" - + :: + + IMAGE_CMD_jffs2 = "mkfs.jffs2 --root=${IMAGE_ROOTFS} \ + --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 \ + ${EXTRA_IMAGECMD}" + You typically do not need to set this variable unless you are adding support for a new image type. For more examples on how to set this variable, see the :ref:`image_types ` class file, which is ``meta/classes/image_types.bbclass``. - + IMAGE_DEVICE_TABLES Specifies one or more files that contain custom device tables that are passed to the ``makedevs`` command as part of creating an image. @@ -2712,55 +2976,55 @@ system and gives an overview of their function and contents. :term:`BBPATH`. For details on how you should write device table files, see ``meta/files/device_table-minimal.txt`` as an example. - + IMAGE_FEATURES The primary list of features to include in an image. Typically, you configure this variable in an image recipe. Although you can use this variable from your ``local.conf`` file, which is found in the :term:`Build Directory`, best practices dictate that you do not. - + .. note:: - + To enable extra features from outside the image recipe, use the EXTRA_IMAGE_FEATURES variable. - + For a list of image features that ships with the Yocto Project, see the "`Image Features <#ref-features-image>`__" section. - + For an example that shows how to customize your image by using this - variable, see the "`Customizing Images Using Custom - ``IMAGE_FEATURES`` and - ``EXTRA_IMAGE_FEATURES`` <&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures>`__" + variable, see the ":ref:`usingpoky-extend-customimage-imagefeatures`" section in the Yocto Project Development Tasks Manual. - + IMAGE_FSTYPES Specifies the formats the OpenEmbedded build system uses during the build when creating the root filesystem. For example, setting ``IMAGE_FSTYPES`` as follows causes the build system to create root filesystems using two formats: ``.ext3`` and ``.tar.bz2``: - IMAGE_FSTYPES = "ext3 tar.bz2" - + :: + + IMAGE_FSTYPES = "ext3 tar.bz2" + For the complete list of supported image formats from which you can choose, see :term:`IMAGE_TYPES`. - + .. note:: - + - If an image recipe uses the "inherit image" line and you are setting ``IMAGE_FSTYPES`` inside the recipe, you must set ``IMAGE_FSTYPES`` prior to using the "inherit image" line. - + - Due to the way the OpenEmbedded build system processes this variable, you cannot update its contents by using ``_append`` or ``_prepend``. You must use the ``+=`` operator to add one or more options to the ``IMAGE_FSTYPES`` variable. - + IMAGE_INSTALL Used by recipes to specify the packages to install into an image through the :ref:`image ` class. Use the ``IMAGE_INSTALL`` variable with care to avoid ordering issues. - + Image recipes set ``IMAGE_INSTALL`` to specify the packages to install into an image through ``image.bbclass``. Additionally, "helper" classes such as the @@ -2768,14 +3032,18 @@ system and gives an overview of their function and contents. take lists used with ``IMAGE_FEATURES`` and turn them into auto-generated entries in ``IMAGE_INSTALL`` in addition to its default contents. - + When you use this variable, it is best to use it as follows: - IMAGE_INSTALL_append = " package-name" Be sure to include the space + :: + + IMAGE_INSTALL_append = " package-name" + + Be sure to include the space between the quotation character and the start of the package name or names. - + .. note:: - + - When working with a ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__ image, do not use the ``IMAGE_INSTALL`` variable to specify @@ -2783,11 +3051,10 @@ system and gives an overview of their function and contents. :term:`PACKAGE_INSTALL` variable, which allows the initial RAM filesystem (initramfs) recipe to use a fixed set of packages and not be affected by ``IMAGE_INSTALL``. - For information on creating an initramfs, see the "`Building an - Initial RAM Filesystem (initramfs) - Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" + For information on creating an initramfs, see the + ":ref:`building-an-initramfs-image`" section in the Yocto Project Development Tasks Manual. - + - Using ``IMAGE_INSTALL`` with the :ref:`+= ` BitBake operator within the ``/conf/local.conf`` file or from @@ -2802,7 +3069,7 @@ system and gives an overview of their function and contents. within an image recipe may or may not succeed depending on the specific situation. In both these cases, the behavior is contrary to how most users expect the ``+=`` operator to work. - + IMAGE_LINGUAS Specifies the list of locales to install into the image during the root filesystem construction process. The OpenEmbedded build system @@ -2810,39 +3077,50 @@ system and gives an overview of their function and contents. into separate packages. Setting the ``IMAGE_LINGUAS`` variable ensures that any locale packages that correspond to packages already selected for installation into the image are also installed. Here is - an example: IMAGE_LINGUAS = "pt-br de-de" - + an example: + :: + + IMAGE_LINGUAS = "pt-br de-de" + In this example, the build system ensures any Brazilian Portuguese and German locale files that correspond to packages in the image are installed (i.e. ``*-locale-pt-br`` and ``*-locale-de-de`` as well as ``*-locale-pt`` and ``*-locale-de``, since some software packages only provide locale files by language and not by country-specific language). - + See the :term:`GLIBC_GENERATE_LOCALES` variable for information on generating GLIBC locales. - + IMAGE_MANIFEST The manifest file for the image. This file lists all the installed packages that make up the image. The file contains package - information on a line-per-package basis as follows: packagename - packagearch version - + information on a line-per-package basis as follows: + :: + + packagename packagearch version + The :ref:`image ` class defines the manifest - file as follows: IMAGE_MANIFEST = - "${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest" The location is + file as follows: + :: + + IMAGE_MANIFEST ="${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.manifest" + + The location is derived using the :term:`DEPLOY_DIR_IMAGE` and :term:`IMAGE_NAME` variables. You can find - information on how the image is created in the "`Image - Generation <&YOCTO_DOCS_OM_URL;#image-generation-dev-environment>`__" + information on how the image is created in the ":ref:`image-generation-dev-environment`" section in the Yocto Project Overview and Concepts Manual. - + IMAGE_NAME The name of the output image files minus the extension. This variable is derived using the :term:`IMAGE_BASENAME`, :term:`MACHINE`, and :term:`DATETIME` - variables: IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}" - + variables: + :: + + IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}" + IMAGE_OVERHEAD_FACTOR Defines a multiplier that the build system applies to the initial image size for cases when the multiplier times the returned disk @@ -2858,18 +3136,20 @@ system and gives an overview of their function and contents. not produce an image with all the theoretical free disk space. See ``IMAGE_ROOTFS_SIZE`` for information on how the build system determines the overall image size. - + The default 30% free disk space typically gives the image enough room to boot and allows for basic post installs while still leaving a small amount of free disk space. If 30% free space is inadequate, you can increase the default value. For example, the following setting - gives you 50% free space added to the image: IMAGE_OVERHEAD_FACTOR = - "1.5" - + gives you 50% free space added to the image: + :: + + IMAGE_OVERHEAD_FACTOR = "1.5" + Alternatively, you can ensure a specific amount of free disk space is added to the image by using the ``IMAGE_ROOTFS_EXTRA_SPACE`` variable. - + IMAGE_PKGTYPE Defines the package type (i.e. DEB, RPM, IPK, or TAR) used by the OpenEmbedded build system. The variable is defined appropriately by @@ -2877,84 +3157,92 @@ system and gives an overview of their function and contents. :ref:`package_rpm `, :ref:`package_ipk `, or :ref:`package_tar ` class. - + .. note:: - + The package_tar class is broken and is not supported. It is recommended that you do not use it. - + The :ref:`populate_sdk_* ` and :ref:`image ` classes use the ``IMAGE_PKGTYPE`` for packaging up images and SDKs. - + You should not set the ``IMAGE_PKGTYPE`` manually. Rather, the variable is set indirectly through the appropriate :ref:`package_* ` class using the :term:`PACKAGE_CLASSES` variable. The OpenEmbedded build system uses the first package type (e.g. DEB, RPM, or IPK) that appears with the variable - + .. note:: - + Files using the .tar format are never used as a substitute packaging format for DEB, RPM, and IPK formatted files for your image or SDK. - + IMAGE_POSTPROCESS_COMMAND Specifies a list of functions to call once the OpenEmbedded build system creates the final image output files. You can specify - functions separated by semicolons: IMAGE_POSTPROCESS_COMMAND += - "function; ... " - + functions separated by semicolons: + :: + + IMAGE_POSTPROCESS_COMMAND += "function; ... " + If you need to pass the root filesystem path to a command within the function, you can use ``${IMAGE_ROOTFS}``, which points to the directory that becomes the root filesystem image. See the :term:`IMAGE_ROOTFS` variable for more information. - + IMAGE_PREPROCESS_COMMAND Specifies a list of functions to call before the OpenEmbedded build system creates the final image output files. You can specify - functions separated by semicolons: IMAGE_PREPROCESS_COMMAND += - "function; ... " - + functions separated by semicolons: + :: + + IMAGE_PREPROCESS_COMMAND += "function; ... " + If you need to pass the root filesystem path to a command within the function, you can use ``${IMAGE_ROOTFS}``, which points to the directory that becomes the root filesystem image. See the :term:`IMAGE_ROOTFS` variable for more information. - + IMAGE_ROOTFS The location of the root filesystem while it is under construction (i.e. during the :ref:`ref-tasks-rootfs` task). This variable is not configurable. Do not change it. - + IMAGE_ROOTFS_ALIGNMENT Specifies the alignment for the output image file in Kbytes. If the size of the image is not a multiple of this value, then the size is rounded up to the nearest multiple of the value. The default value is "1". See :term:`IMAGE_ROOTFS_SIZE` for additional information. - + IMAGE_ROOTFS_EXTRA_SPACE Defines additional free disk space created in the image in Kbytes. By default, this variable is set to "0". This free disk space is added to the image after the build system determines the image size as described in ``IMAGE_ROOTFS_SIZE``. - + This variable is particularly useful when you want to ensure that a specific amount of free disk space is available on a device after an image is installed and running. For example, to be sure 5 Gbytes of free disk space is available, set the variable as follows: - IMAGE_ROOTFS_EXTRA_SPACE = "5242880" - + :: + + IMAGE_ROOTFS_EXTRA_SPACE = "5242880" + For example, the Yocto Project Build Appliance specifically requests - 40 Gbytes of extra space with the line: IMAGE_ROOTFS_EXTRA_SPACE = - "41943040" - + 40 Gbytes of extra space with the line: + :: + + IMAGE_ROOTFS_EXTRA_SPACE = "41943040" + IMAGE_ROOTFS_SIZE Defines the size in Kbytes for the generated image. The OpenEmbedded build system determines the final size for the generated image using @@ -2962,45 +3250,87 @@ system and gives an overview of their function and contents. the generated image, a requested size for the image, and requested additional free disk space to be added to the image. Programatically, the build system determines the final size of the generated image as - follows: if (image-du \* overhead) < rootfs-size: - internal-rootfs-size = rootfs-size + xspace else: - internal-rootfs-size = (image-du \* overhead) + xspace where: - image-du = Returned value of the du command on the image. overhead = - IMAGE_OVERHEAD_FACTOR rootfs-size = IMAGE_ROOTFS_SIZE - internal-rootfs-size = Initial root filesystem size before any - modifications. xspace = IMAGE_ROOTFS_EXTRA_SPACE - + follows: + :: + + if (image-du * overhead) < rootfs-size: + internal-rootfs-size = rootfs-size + xspace + else: + internal-rootfs-size = (image-du * overhead) + xspace + where: + image-du = Returned value of the du command on the image. + overhead = IMAGE_OVERHEAD_FACTOR + rootfs-size = IMAGE_ROOTFS_SIZE + internal-rootfs-size = Initial root filesystem size before any modifications. + xspace = IMAGE_ROOTFS_EXTRA_SPACE + See the :term:`IMAGE_OVERHEAD_FACTOR` and :term:`IMAGE_ROOTFS_EXTRA_SPACE` variables for related information. - + IMAGE_TYPEDEP Specifies a dependency from one image type on another. Here is an example from the :ref:`image-live ` class: - IMAGE_TYPEDEP_live = "ext3" - + :: + + IMAGE_TYPEDEP_live = "ext3" + In the previous example, the variable ensures that when "live" is listed with the :term:`IMAGE_FSTYPES` variable, the OpenEmbedded build system produces an ``ext3`` image first since one of the components of the live image is an ``ext3`` formatted partition containing the root filesystem. - + IMAGE_TYPES Specifies the complete list of supported image types by default: - btrfs container cpio cpio.gz cpio.lz4 cpio.lzma cpio.xz cramfs ext2 - ext2.bz2 ext2.gz ext2.lzma ext3 ext3.gz ext4 ext4.gz f2fs hddimg iso - jffs2 jffs2.sum multiubi squashfs squashfs-lz4 squashfs-lzo - squashfs-xz tar tar.bz2 tar.gz tar.lz4 tar.xz tar.zst ubi ubifs wic - wic.bz2 wic.gz wic.lzma - + + - btrfs + - container + - cpio + - cpio.gz + - cpio.lz4 + - cpio.lzma + - cpio.xz + - cramfs + - ext2 + - ext2.bz2 + - ext2.gz + - ext2.lzma + - ext3 + - ext3.gz + - ext4 + - ext4.gz + - f2fs + - hddimg + - iso + - jffs2 + - jffs2.sum + - multiubi + - squashfs + - squashfs-lz4 + - squashfs-lzo + - squashfs-xz + - tar + - tar.bz2 + - tar.gz + - tar.lz4 + - tar.xz + - tar.zst + - ubi + - ubifs + - wic + - wic.bz2 + - wic.gz + - wic.lzma + For more information about these types of images, see ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`. - + INC_PR Helps define the recipe revision for recipes that share a common ``include`` file. You can think of this variable as part of the recipe revision as set from within an include file. - + Suppose, for example, you have a set of recipes that are used across several projects. And, within each of those recipes the revision (its :term:`PR` value) is set accordingly. In this case, when @@ -3009,49 +3339,53 @@ system and gives an overview of their function and contents. updated version of the recipe. In this scenario, it can get complicated when recipes that are used in many places and provide common functionality are upgraded to a new revision. - + A more efficient way of dealing with this situation is to set the ``INC_PR`` variable inside the ``include`` files that the recipes share and then expand the ``INC_PR`` variable within the recipes to help define the recipe revision. - + The following provides an example that shows how to use the ``INC_PR`` variable given a common ``include`` file that defines the variable. Once the variable is defined in the ``include`` file, you can use the variable to set the ``PR`` values in each recipe. You will notice that when you set a recipe's ``PR`` you can provide more granular revisioning by appending values to the ``INC_PR`` variable: - recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" - recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1" - recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0" - recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" The + :: + + recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2" + recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1" + recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0" + recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3" + + The first line of the example establishes the baseline revision to be used for all recipes that use the ``include`` file. The remaining lines in the example are from individual recipes and show how the ``PR`` value is set. - + INCOMPATIBLE_LICENSE Specifies a space-separated list of license names (as they would appear in :term:`LICENSE`) that should be excluded from the build. Recipes that provide no alternatives to listed incompatible licenses are not built. Packages that are individually licensed with the specified incompatible licenses will be deleted. - + .. note:: - + This functionality is only regularly tested using the following setting: :: - + INCOMPATIBLE_LICENSE = "GPL-3.0 LGPL-3.0 AGPL-3.0" - - + + Although you can use other settings, you might be required to remove dependencies on or provide alternatives to components that are required to produce a functional system image. - + .. note:: - + It is possible to define a list of licenses that are allowed to be used instead of the licenses that are excluded. To do this, define a variable @@ -3060,10 +3394,10 @@ system and gives an overview of their function and contents. INCOMPATIBLE_LICENSE as: :: - + INCOMPATIBLE_LICENSE = "${@' '.join(sorted(set(d.getVar('AVAILABLE_LICENSES').split()) - set(d.getVar('COMPATIBLE_LICENSES').split())))}" - - + + This will result in INCOMPATIBLE_LICENSE containing the names of all licences from @@ -3071,34 +3405,36 @@ system and gives an overview of their function and contents. except the ones specified in COMPATIBLE_LICENSES , thus only allowing the latter licences to be used. - + 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 ``INHERIT`` in individual recipes. - + For more information on ``INHERIT``, see the :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`" section in the Bitbake User Manual. - + INHERIT_DISTRO Lists classes that will be inherited at the distribution level. It is unlikely that you want to edit this variable. - + The default value of the variable is set as follows in the - ``meta/conf/distro/defaultsetup.conf`` file: INHERIT_DISTRO ?= - "debian devshell sstate license" - + ``meta/conf/distro/defaultsetup.conf`` file: + :: + + INHERIT_DISTRO ?= "debian devshell sstate license" + INHIBIT_DEFAULT_DEPS Prevents the default dependencies, namely the C compiler and standard C library (libc), from being added to :term:`DEPENDS`. This variable is usually used within recipes that do not require any compilation using the C compiler. - + Set the variable to "1" to prevent the default dependencies from being added. - + INHIBIT_PACKAGE_DEBUG_SPLIT Prevents the OpenEmbedded build system from splitting out debug information during packaging. By default, the build system splits out @@ -3107,37 +3443,40 @@ system and gives an overview of their function and contents. how debug information is split out, see the :term:`PACKAGE_DEBUG_SPLIT_STYLE` variable. - + To prevent the build system from splitting out debug information during packaging, set the ``INHIBIT_PACKAGE_DEBUG_SPLIT`` variable as - follows: INHIBIT_PACKAGE_DEBUG_SPLIT = "1" - + follows: + :: + + INHIBIT_PACKAGE_DEBUG_SPLIT = "1" + INHIBIT_PACKAGE_STRIP If set to "1", causes the build to not strip binaries in resulting packages and prevents the ``-dbg`` package from containing the source files. - + By default, the OpenEmbedded build system strips binaries and puts the debugging symbols into ``${``\ :term:`PN`\ ``}-dbg``. Consequently, you should not set ``INHIBIT_PACKAGE_STRIP`` when you plan to debug in general. - + INHIBIT_SYSROOT_STRIP If set to "1", causes the build to not strip binaries in the resulting sysroot. - + By default, the OpenEmbedded build system strips binaries in the resulting sysroot. When you specifically set the ``INHIBIT_SYSROOT_STRIP`` variable to "1" in your recipe, you inhibit this stripping. - + If you want to use this variable, include the :ref:`staging ` class. This class uses a ``sys_strip()`` function to test for the variable and acts accordingly. - + .. note:: - + Use of the INHIBIT_SYSROOT_STRIP variable occurs in rare and special circumstances. For example, @@ -3145,20 +3484,20 @@ system and gives an overview of their function and contents. GCC toolchain. Furthermore, even if the toolchain's binaries are strippable, other files exist that are needed for the build that are not strippable. - + INITRAMFS_FSTYPES Defines the format for the output image of an initial RAM filesystem (initramfs), which is used during boot. Supported formats are the same as those supported by the :term:`IMAGE_FSTYPES` variable. - + The default value of this variable, which is set in the ``meta/conf/bitbake.conf`` configuration file in the :term:`Source Directory`, is "cpio.gz". The Linux kernel's initramfs mechanism, as opposed to the initial RAM filesystem `initrd `__ mechanism, expects an optionally compressed cpio archive. - + INITRAMFS_IMAGE Specifies the :term:`PROVIDES` name of an image recipe that is used to build an initial RAM filesystem (initramfs) @@ -3168,13 +3507,13 @@ system and gives an overview of their function and contents. initramfs image recipe you provide should set :term:`IMAGE_FSTYPES` to :term:`INITRAMFS_FSTYPES`. - + An initramfs image provides a temporary root filesystem used for early system initialization (e.g. loading of modules needed to locate and mount the "real" root filesystem). - + .. note:: - + See the meta/recipes-core/images/core-image-minimal-initramfs.bb recipe in the @@ -3183,24 +3522,23 @@ system and gives an overview of their function and contents. the one built to provide the initramfs image, set INITRAMFS_IMAGE to "core-image-minimal-initramfs". - + You can also find more information by referencing the ``meta-poky/conf/local.conf.sample.extended`` configuration file in the Source Directory, the :ref:`image ` class, and the :ref:`kernel ` class to see how to use the ``INITRAMFS_IMAGE`` variable. - + If ``INITRAMFS_IMAGE`` is empty, which is the default, then no initramfs image is built. - + For more information, you can also see the :term:`INITRAMFS_IMAGE_BUNDLE` variable, which allows the generated image to be bundled inside the kernel image. Additionally, for information on creating an initramfs - image, see the "`Building an Initial RAM Filesystem (initramfs) - Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section + image, see the ":ref:`building-an-initramfs-image`" section in the Yocto Project Development Tasks Manual. - + INITRAMFS_IMAGE_BUNDLE Controls whether or not the image recipe specified by :term:`INITRAMFS_IMAGE` is run through an @@ -3211,152 +3549,181 @@ system and gives an overview of their function and contents. image. This makes use of the :term:`CONFIG_INITRAMFS_SOURCE` kernel feature. - + .. note:: - + Using an extra compilation pass to bundle the initramfs avoids a circular dependency between the kernel recipe and the initramfs recipe should the initramfs include kernel modules. Should that be the case, the initramfs recipe depends on the kernel for the kernel modules, and the kernel depends on the initramfs recipe since the initramfs is bundled inside the kernel image. - + The combined binary is deposited into the ``tmp/deploy`` directory, which is part of the :term:`Build Directory`. - + Setting the variable to "1" in a configuration file causes the OpenEmbedded build system to generate a kernel image with the initramfs specified in ``INITRAMFS_IMAGE`` bundled within: - INITRAMFS_IMAGE_BUNDLE = "1" By default, the + :: + + INITRAMFS_IMAGE_BUNDLE = "1" + + By default, the :ref:`kernel ` class sets this variable to a - null string as follows: INITRAMFS_IMAGE_BUNDLE ?= "" - + null string as follows: + :: + + INITRAMFS_IMAGE_BUNDLE ?= "" + .. note:: - + You must set the INITRAMFS_IMAGE_BUNDLE variable in a configuration file. You cannot set the variable in a recipe file. - + See the :yocto_git:`local.conf.sample.extended ` file for additional information. Also, for information on creating an - initramfs, see the "`Building an Initial RAM Filesystem (initramfs) - Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section + initramfs, see the ":ref:`building-an-initramfs-image`" section in the Yocto Project Development Tasks Manual. - + INITRAMFS_LINK_NAME The link name of the initial RAM filesystem image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as - follows: INITRAMFS_LINK_NAME ?= - "initramfs-${KERNEL_ARTIFACT_LINK_NAME}" The value of the + follows: + :: + + INITRAMFS_LINK_NAME ?= "initramfs-${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same - file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= - "${MACHINE}" - + file, has the following value: + :: + + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" + See the :term:`MACHINE` variable for additional information. - + INITRAMFS_NAME The base name of the initial RAM filesystem image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as - follows: INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}" The - value of the :term:`KERNEL_ARTIFACT_NAME` + follows: + :: + + INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}" + + The value of the :term:`KERNEL_ARTIFACT_NAME` variable, which is set in the same file, has the following value: - KERNEL_ARTIFACT_NAME ?= - "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" - + :: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + INITRD Indicates list of filesystem images to concatenate and use as an initial RAM disk (``initrd``). - + The ``INITRD`` variable is an optional variable used with the :ref:`image-live ` class. - + INITRD_IMAGE When building a "live" bootable image (i.e. when :term:`IMAGE_FSTYPES` contains "live"), ``INITRD_IMAGE`` specifies the image recipe that should be built to provide the initial RAM disk image. The default value is "core-image-minimal-initramfs". - + See the :ref:`image-live ` class for more information. - + INITSCRIPT_NAME The filename of the initialization script as installed to ``${sysconfdir}/init.d``. - + This variable is used in recipes when using ``update-rc.d.bbclass``. The variable is mandatory. - + INITSCRIPT_PACKAGES A list of the packages that contain initscripts. If multiple packages are specified, you need to append the package name to the other ``INITSCRIPT_*`` as an override. - + This variable is used in recipes when using ``update-rc.d.bbclass``. The variable is optional and defaults to the :term:`PN` variable. - + INITSCRIPT_PARAMS Specifies the options to pass to ``update-rc.d``. Here is an example: - INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ." - + :: + + INITSCRIPT_PARAMS = "start 99 5 2 . stop 20 0 1 6 ." + In this example, the script has a runlevel of 99, starts the script in initlevels 2 and 5, and stops the script in levels 0, 1 and 6. - + The variable's default value is "defaults", which is set in the :ref:`update-rc.d ` class. - + The value in ``INITSCRIPT_PARAMS`` is passed through to the ``update-rc.d`` command. For more information on valid parameters, please see the ``update-rc.d`` manual page at http://www.tin.org/bin/man.cgi?section=8&topic=update-rc.d. - + INSANE_SKIP Specifies the QA checks to skip for a specific package within a recipe. For example, to skip the check for symbolic link ``.so`` files in the main package of a recipe, add the following to the recipe. The package name override must be used, which in this example - is ``${PN}``: INSANE_SKIP_${PN} += "dev-so" - + is ``${PN}``: + :: + + INSANE_SKIP_${PN} += "dev-so" + See the ":ref:`insane.bbclass `" section for a list of the valid QA checks you can specify using this variable. - + INSTALL_TIMEZONE_FILE By default, the ``tzdata`` recipe packages an ``/etc/timezone`` file. Set the ``INSTALL_TIMEZONE_FILE`` variable to "0" at the configuration level to disable this behavior. - + IPK_FEED_URIS When the IPK backend is in use and package management is enabled on the target, you can use this variable to set up ``opkg`` in the target image to point to package feeds on a nominated server. Once the feed is established, you can perform installations or upgrades using the package manager at runtime. - + KARCH Defines the kernel architecture used when assembling the - configuration. Architectures supported for this release are: powerpc - i386 x86_64 arm qemu mips - - You define the ``KARCH`` variable in the `BSP - Descriptions <&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions>`__. - + configuration. Architectures supported for this release are: + + - powerpc + - i386 + - x86_64 + - arm + - qemu + - mips + + You define the ``KARCH`` variable in the :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`. + KBRANCH A regular expression used by the build process to explicitly identify the kernel branch that is validated, patched, and configured during a build. You must set this variable to ensure the exact kernel branch you want is being used by the build process. - + Values for this variable are set in the kernel's recipe file and the kernel's append file. For example, if you are using the ``linux-yocto_4.12`` kernel, the kernel recipe file is the ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` file. ``KBRANCH`` - is set as follows in that kernel recipe file: KBRANCH ?= - "standard/base" - + is set as follows in that kernel recipe file: + :: + + KBRANCH ?= "standard/base" + This variable is also used from the kernel's append file to identify the kernel branch specific to a particular machine or target hardware. Continuing with the previous kernel example, the kernel's @@ -3366,17 +3733,22 @@ system and gives an overview of their function and contents. machines (``meta-yocto-bsp``) is named ``meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend``. Here are the related statements from that append file: - KBRANCH_genericx86 = "standard/base" KBRANCH_genericx86-64 = - "standard/base" KBRANCH_edgerouter = "standard/edgerouter" - KBRANCH_beaglebone = "standard/beaglebone" The ``KBRANCH`` statements + :: + + KBRANCH_genericx86 = "standard/base" + KBRANCH_genericx86-64 = "standard/base" + KBRANCH_edgerouter = "standard/edgerouter" + KBRANCH_beaglebone = "standard/beaglebone" + + The ``KBRANCH`` statements identify the kernel branch to use when building for each supported BSP. - + KBUILD_DEFCONFIG When used with the :ref:`kernel-yocto ` class, specifies an "in-tree" kernel configuration file for use during a kernel build. - + Typically, when using a ``defconfig`` to configure a kernel during a build, you place the file in your layer in the same manner as you would place patch files and configuration fragment files (i.e. @@ -3385,46 +3757,53 @@ system and gives an overview of their function and contents. ``KBUILD_DEFCONFIG`` variable and append the :term:`KMACHINE` variable to point to the ``defconfig`` file. - + To use the variable, set it in the append file for your kernel recipe - using the following form: KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file + using the following form: + :: + + KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file + Here is an example from a "raspberrypi2" ``KMACHINE`` build that uses a ``defconfig`` file named "bcm2709_defconfig": - KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig" As an - alternative, you can use the following within your append file: - KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file For more + :: + + KBUILD_DEFCONFIG_raspberrypi2 = "bcm2709_defconfig" + + As an alternative, you can use the following within your append file: + :: + + KBUILD_DEFCONFIG_pn-linux-yocto ?= defconfig_file + + For more information on how to use the ``KBUILD_DEFCONFIG`` variable, see the - "`Using an "In-Tree" ``defconfig`` - File <&YOCTO_DOCS_KERNEL_DEV_URL;#using-an-in-tree-defconfig-file>`__" + ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`" section in the Yocto Project Linux Kernel Development Manual. - + KERNEL_ALT_IMAGETYPE Specifies an alternate kernel image type for creation in addition to the kernel image type specified using the :term:`KERNEL_IMAGETYPE` variable. - + KERNEL_ARTIFACT_NAME Specifies the name of all of the build artifacts. You can change the name of the artifacts by changing the ``KERNEL_ARTIFACT_NAME`` variable. - + The value of ``KERNEL_ARTIFACT_NAME``, which is set in the ``meta/classes/kernel-artifact-names.bbclass`` file, has the - following default value: KERNEL_ARTIFACT_NAME ?= - "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" - - See the :term:`PKGE`, :term:`PKGV`, - :term:`PKGR`, and :term:`MACHINE` + following default value: + :: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + + See the :term:`PKGE`, :term:`PKGV`, :term:`PKGR`, and :term:`MACHINE` variables for additional information. - + .. note:: - - The - IMAGE_VERSION_SUFFIX - variable is set to - DATETIME - . - + + The IMAGE_VERSION_SUFFIX variable is set to DATETIME. + KERNEL_CLASSES A list of classes defining kernel image types that the :ref:`kernel ` class should inherit. You @@ -3433,46 +3812,56 @@ system and gives an overview of their function and contents. resides in ``meta/classes/kernel-fitimage.bbclass``. You can register custom kernel image types with the ``kernel`` class using this variable. - + KERNEL_DEVICETREE Specifies the name of the generated Linux kernel device tree (i.e. the ``.dtb``) file. - + .. note:: - + Legacy support exists for specifying the full path to the device - tree. However, providing just the - .dtb - file is preferred. - + tree. However, providing just the .dtb file is preferred. + In order to use this variable, the :ref:`kernel-devicetree ` class must be inherited. - + KERNEL_DTB_LINK_NAME The link name of the kernel device tree binary (DTB). This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as - follows: KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The + follows: + :: + + KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in - the same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= - "${MACHINE}" - + the same file, has the following value: + :: + + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" + See the :term:`MACHINE` variable for additional information. - + KERNEL_DTB_NAME The base name of the kernel device tree binary (DTB). This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as - follows: KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of - the :term:`KERNEL_ARTIFACT_NAME` + follows: + :: + + KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}" + + The value of the :term:`KERNEL_ARTIFACT_NAME` variable, which is set in the same file, has the following value: - KERNEL_ARTIFACT_NAME ?= - "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" - + :: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + KERNEL_EXTRA_ARGS Specifies additional ``make`` command-line arguments the OpenEmbedded build system passes on when compiling the kernel. - + KERNEL_FEATURES Includes additional kernel metadata. In the OpenEmbedded build system, the default Board Support Packages (BSPs) @@ -3481,158 +3870,184 @@ system and gives an overview of their function and contents. variables. You can use the ``KERNEL_FEATURES`` variable from within the kernel recipe or kernel append file to further add metadata for all BSPs or specific BSPs. - + The metadata you add through this variable includes config fragments and features descriptions, which usually includes patches as well as config fragments. You typically override the ``KERNEL_FEATURES`` variable for a specific machine. In this way, you can provide validated, but optional, sets of kernel configurations and features. - + For example, the following example from the ``linux-yocto-rt_4.12`` kernel recipe adds "netfilter" and "taskstats" features to all BSPs as well as "virtio" configurations to all QEMU machines. The last two statements add specific configurations to targeted machine types: - KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc - features/taskstats/taskstats.scc" KERNEL_FEATURES_append = " - ${KERNEL_EXTRA_FEATURES}" KERNEL_FEATURES_append_qemuall = " - cfg/virtio.scc" KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc - cfg/paravirt_kvm.scc" KERNEL_FEATURES_append_qemux86-64 = " - cfg/sound.scc" - + :: + + KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc" + KERNEL_FEATURES_append = "${KERNEL_EXTRA_FEATURES}" + KERNEL_FEATURES_append_qemuall = "cfg/virtio.scc" + KERNEL_FEATURES_append_qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc" + KERNEL_FEATURES_append_qemux86-64 = "cfg/sound.scc" + KERNEL_FIT_LINK_NAME The link name of the kernel flattened image tree (FIT) image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` - file as follows: KERNEL_FIT_LINK_NAME ?= - "${KERNEL_ARTIFACT_LINK_NAME}" The value of the + file as follows: + :: + + KERNEL_FIT_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same - file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= - "${MACHINE}" - + file, has the following value: + :: + + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" + See the :term:`MACHINE` variable for additional information. - + KERNEL_FIT_NAME The base name of the kernel flattened image tree (FIT) image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` - file as follows: KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}" The - value of the :term:`KERNEL_ARTIFACT_NAME` + file as follows: + :: + + KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}" + + The value of the :term:`KERNEL_ARTIFACT_NAME` variable, which is set in the same file, has the following value: - KERNEL_ARTIFACT_NAME ?= - "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" - + :: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + KERNEL_IMAGE_LINK_NAME The link name for the kernel image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as follows: - KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value of + :: + + KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same - file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= - "${MACHINE}" - + file, has the following value: + :: + + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" + See the :term:`MACHINE` variable for additional information. - + KERNEL_IMAGE_MAXSIZE Specifies the maximum size of the kernel image file in kilobytes. If ``KERNEL_IMAGE_MAXSIZE`` is set, the size of the kernel image file is checked against the set value during the :ref:`ref-tasks-sizecheck` task. The task fails if the kernel image file is larger than the setting. - + ``KERNEL_IMAGE_MAXSIZE`` is useful for target devices that have a limited amount of space in which the kernel image must be stored. - + By default, this variable is not set, which means the size of the kernel image is not checked. - + KERNEL_IMAGE_NAME The base name of the kernel image. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as follows: - KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the + :: + + KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}" + + The value of the :term:`KERNEL_ARTIFACT_NAME` variable, which is set in the same file, has the following value: - KERNEL_ARTIFACT_NAME ?= - "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" - + :: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + KERNEL_IMAGETYPE The type of kernel to build for a device, usually set by the machine configuration files and defaults to "zImage". This variable is used when building the kernel and is passed to ``make`` as the target to build. - + If you want to build an alternate kernel image type, use the :term:`KERNEL_ALT_IMAGETYPE` variable. - + KERNEL_MODULE_AUTOLOAD Lists kernel modules that need to be auto-loaded during boot. - + .. note:: - + This variable replaces the deprecated module_autoload variable. - + You can use the ``KERNEL_MODULE_AUTOLOAD`` variable anywhere that it can be recognized by the kernel recipe or by an out-of-tree kernel module recipe (e.g. a machine configuration file, a distribution configuration file, an append file for the recipe, or the recipe itself). - - Specify it as follows: KERNEL_MODULE_AUTOLOAD += "module_name1 - module_name2 module_name3" - + + Specify it as follows: + :: + + KERNEL_MODULE_AUTOLOAD += "module_name1 module_name2 module_name3" + Including ``KERNEL_MODULE_AUTOLOAD`` causes the OpenEmbedded build system to populate the ``/etc/modules-load.d/modname.conf`` file with the list of modules to be auto-loaded on boot. The modules appear one-per-line in the file. Here is an example of the most common use - case: KERNEL_MODULE_AUTOLOAD += "module_name" - + case: + :: + + KERNEL_MODULE_AUTOLOAD += "module_name" + For information on how to populate the ``modname.conf`` file with - ``modprobe.d`` syntax lines, see the - :term:`KERNEL_MODULE_PROBECONF` - variable. - + ``modprobe.d`` syntax lines, see the :term:`KERNEL_MODULE_PROBECONF` variable. + KERNEL_MODULE_PROBECONF Provides a list of modules for which the OpenEmbedded build system expects to find ``module_conf_``\ modname values that specify configuration for each of the modules. For information on how to provide those module configurations, see the :term:`module_conf_* ` variable. - + KERNEL_PATH The location of the kernel sources. This variable is set to the value of the :term:`STAGING_KERNEL_DIR` within the :ref:`module ` class. For information on - how this variable is used, see the "`Incorporating Out-of-Tree - Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__" + how this variable is used, see the + ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`" section in the Yocto Project Linux Kernel Development Manual. - + To help maximize compatibility with out-of-tree drivers used to build modules, the OpenEmbedded build system also recognizes and uses the :term:`KERNEL_SRC` variable, which is identical to the ``KERNEL_PATH`` variable. Both variables are common variables used by external Makefiles to point to the kernel source directory. - + KERNEL_SRC The location of the kernel sources. This variable is set to the value of the :term:`STAGING_KERNEL_DIR` within the :ref:`module ` class. For information on - how this variable is used, see the "`Incorporating Out-of-Tree - Modules <&YOCTO_DOCS_KERNEL_DEV_URL;#incorporating-out-of-tree-modules>`__" + how this variable is used, see the + ":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`" section in the Yocto Project Linux Kernel Development Manual. - + To help maximize compatibility with out-of-tree drivers used to build modules, the OpenEmbedded build system also recognizes and uses the :term:`KERNEL_PATH` variable, which is identical to the ``KERNEL_SRC`` variable. Both variables are common variables used by external Makefiles to point to the kernel source directory. - + KERNEL_VERSION Specifies the version of the kernel as extracted from ``version.h`` or ``utsrelease.h`` within the kernel sources. Effects of setting this variable do not take affect until the kernel has been configured. Consequently, attempting to refer to this variable in contexts prior to configuration will not work. - + KERNELDEPMODDEPEND Specifies whether the data referenced through :term:`PKGDATA_DIR` is needed or not. The @@ -3641,14 +4056,16 @@ system and gives an overview of their function and contents. use the data, set the ``KERNELDEPMODDEPEND`` variable in your ``initramfs`` recipe. Setting the variable there when the data is not needed avoids a potential dependency loop. - + KFEATURE_DESCRIPTION Provides a short description of a configuration fragment. You use this variable in the ``.scc`` file that describes a configuration fragment file. Here is the variable used in a file named ``smp.scc`` - to describe SMP being enabled: define KFEATURE_DESCRIPTION "Enable - SMP" - + to describe SMP being enabled: + :: + + define KFEATURE_DESCRIPTION "Enable SMP" + KMACHINE The machine as known by the kernel. Sometimes the machine name used by the kernel does not match the machine name used by the @@ -3658,77 +4075,86 @@ system and gives an overview of their function and contents. understands that machine as ``intel-core2-32``. For cases like these, the ``KMACHINE`` variable maps the kernel machine name to the OpenEmbedded build system machine name. - + These mappings between different names occur in the Yocto Linux Kernel's ``meta`` branch. As an example take a look in the ``common/recipes-kernel/linux/linux-yocto_3.19.bbappend`` file: - LINUX_VERSION_core2-32-intel-common = "3.19.0" - COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}" - SRCREV_meta_core2-32-intel-common = - "8897ef68b30e7426bc1d39895e71fb155d694974" - SRCREV_machine_core2-32-intel-common = - "43b9eced9ba8a57add36af07736344dcc383f711" - KMACHINE_core2-32-intel-common = "intel-core2-32" - KBRANCH_core2-32-intel-common = "standard/base" - KERNEL_FEATURES_append_core2-32-intel-common = - "${KERNEL_FEATURES_INTEL_COMMON}" The ``KMACHINE`` statement says + :: + + LINUX_VERSION_core2-32-intel-common = "3.19.0" + COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}" + SRCREV_meta_core2-32-intel-common = "8897ef68b30e7426bc1d39895e71fb155d694974" + SRCREV_machine_core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711" + KMACHINE_core2-32-intel-common = "intel-core2-32" + KBRANCH_core2-32-intel-common = "standard/base" + KERNEL_FEATURES_append_core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}" + + The ``KMACHINE`` statement says that the kernel understands the machine name as "intel-core2-32". However, the OpenEmbedded build system understands the machine as "core2-32-intel-common". - + KTYPE Defines the kernel type to be used in assembling the configuration. The linux-yocto recipes define "standard", "tiny", and "preempt-rt" - kernel types. See the "`Kernel - Types <&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types>`__" section in the + kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`" + section in the Yocto Project Linux Kernel Development Manual for more information on kernel types. - - You define the ``KTYPE`` variable in the `BSP - Descriptions <&YOCTO_DOCS_KERNEL_DEV_URL;#bsp-descriptions>`__. The + + You define the ``KTYPE`` variable in the + :ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`. The value you use must match the value used for the :term:`LINUX_KERNEL_TYPE` value used by the kernel recipe. - + LABELS Provides a list of targets for automatic configuration. - + See the :ref:`grub-efi ` class for more information on how this variable is used. - + LAYERDEPENDS Lists the layers, separated by spaces, on 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. Here is an example: - LAYERDEPENDS_mylayer = "anotherlayer (=3)" In this previous example, + :: + + LAYERDEPENDS_mylayer = "anotherlayer (=3)" + + In this previous example, version 3 of "anotherlayer" is compared against :term:`LAYERVERSION`\ ``_anotherlayer``. - + An error is produced if any dependency is missing or the version numbers (if specified) do not match exactly. This variable is used in the ``conf/layer.conf`` file and must be suffixed with the name of the specific layer (e.g. ``LAYERDEPENDS_mylayer``). - + 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. - + LAYERRECOMMENDS Lists the layers, separated by spaces, recommended for use with this layer. - + Optionally, you can specify a specific layer version for a recommendation by adding the version to the end of the layer name. - Here is an example: LAYERRECOMMENDS_mylayer = "anotherlayer (=3)" In - this previous example, version 3 of "anotherlayer" is compared + Here is an example: + :: + + LAYERRECOMMENDS_mylayer = "anotherlayer (=3)" + + In this previous example, version 3 of "anotherlayer" is compared against ``LAYERVERSION_anotherlayer``. - + This variable is used in the ``conf/layer.conf`` file and must be suffixed with the name of the specific layer (e.g. ``LAYERRECOMMENDS_mylayer``). - + LAYERSERIES_COMPAT Lists the versions of the :term:`OpenEmbedded-Core (OE-Core)` for which a layer is compatible. Using the ``LAYERSERIES_COMPAT`` variable @@ -3736,27 +4162,28 @@ system and gives an overview of their function and contents. 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 :yocto_wiki:`Release Name ` (e.g. DISTRO_NAME_NO_CAP). To specify multiple OE-Core versions for the - layer, use a space-separated list: LAYERSERIES_COMPAT_layer_root_name - = "DISTRO_NAME_NO_CAP DISTRO_NAME_NO_CAP_MINUS_ONE" - + layer, use a space-separated list: + :: + + LAYERSERIES_COMPAT_layer_root_name = "DISTRO_NAME_NO_CAP DISTRO_NAME_NO_CAP_MINUS_ONE" + .. note:: - + Setting 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. - - See the "`Creating Your Own - Layer <&YOCTO_DOCS_DEV_URL;#creating-your-own-layer>`__" section in - the Yocto Project Development Tasks Manual. - + + See the ":ref:`dev-manual/dev-manual-common-tasks:creating your own layer`" + section in the Yocto Project Development Tasks Manual. + LAYERVERSION Optionally specifies the version of a layer as a single number. You can use this within :term:`LAYERDEPENDS` for @@ -3764,90 +4191,98 @@ system and gives an overview of their function and contents. This variable is used in the ``conf/layer.conf`` file and must be suffixed with the name of the specific layer (e.g. ``LAYERVERSION_mylayer``). - + LD The minimal command and arguments used to run the linker. - + LDFLAGS Specifies the flags to pass to the linker. This variable is exported to an environment variable and thus made visible to the software being built during the compilation step. - + Default initialization for ``LDFLAGS`` varies depending on what is being built: - + - :term:`TARGET_LDFLAGS` when building for the target - + - :term:`BUILD_LDFLAGS` when building for the build host (i.e. ``-native``) - + - :term:`BUILDSDK_LDFLAGS` when building for an SDK (i.e. ``nativesdk-``) - + LEAD_SONAME Specifies the lead (or primary) compiled library file (i.e. ``.so``) that the :ref:`debian ` class applies its naming policy to given a recipe that packages multiple libraries. - + This variable works in conjunction with the ``debian`` class. - + LIC_FILES_CHKSUM Checksums of the license text in the recipe source code. - + This variable tracks changes in license text of the source code files. If the license text is changed, it will trigger a build failure, which gives the developer an opportunity to review any license change. - + This variable must be defined for all recipes (unless :term:`LICENSE` is set to "CLOSED"). - - For more information, see the "`Tracking License - Changes <&YOCTO_DOCS_DEV_URL;#usingpoky-configuring-LIC_FILES_CHKSUM>`__" + + For more information, see the ":ref:`usingpoky-configuring-lic_files_chksum`" section in the Yocto Project Development Tasks Manual. - + LICENSE The list of source licenses for the recipe. Follow these rules: - + - Do not use spaces within individual license names. - + - Separate license names using \| (pipe) when there is a choice between licenses. - + - Separate license names using & (ampersand) when multiple licenses exist that cover different parts of the source. - + - You can use spaces between license names. - + - For standard licenses, use the names of the files in ``meta/files/common-licenses/`` or the :term:`SPDXLICENSEMAP` flag names defined in ``meta/conf/licenses.conf``. - - Here are some examples: LICENSE = "LGPLv2.1 \| GPLv3" LICENSE = - "MPL-1 & LGPLv2.1" LICENSE = "GPLv2+" The first example is from the + + Here are some examples: + :: + + LICENSE = "LGPLv2.1 | GPLv3" + LICENSE = "MPL-1 & LGPLv2.1" + LICENSE = "GPLv2+" + + The first example is from the recipes for Qt, which the user may choose to distribute under either the LGPL version 2.1 or GPL version 3. The second example is from Cairo where two licenses cover different parts of the source code. The final example is from ``sysstat``, which presents a single license. - + You can also specify licenses on a per-package basis to handle situations where components of the output have different licenses. For example, a piece of software whose code is licensed under GPLv2 but has accompanying documentation licensed under the GNU Free - Documentation License 1.2 could be specified as follows: LICENSE = - "GFDL-1.2 & GPLv2" LICENSE_${PN} = "GPLv2" LICENSE_${PN}-doc = - "GFDL-1.2" - + Documentation License 1.2 could be specified as follows: + :: + + LICENSE = "GFDL-1.2 & GPLv2" + LICENSE_${PN} = "GPLv2" + LICENSE_${PN}-doc = "GFDL-1.2" + LICENSE_CREATE_PACKAGE Setting ``LICENSE_CREATE_PACKAGE`` to "1" causes the OpenEmbedded build system to create an extra package (i.e. ``${``\ :term:`PN`\ ``}-lic``) for each recipe and to add those packages to the :term:`RRECOMMENDS`\ ``_${PN}``. - + The ``${PN}-lic`` package installs a directory in ``/usr/share/licenses`` named ``${PN}``, which is the recipe's base name, and installs files in that directory that contain license and @@ -3857,124 +4292,149 @@ system and gives an overview of their function and contents. and copies of files marked in :term:`LIC_FILES_CHKSUM` as containing license text). - + For related information on providing license text, see the :term:`COPY_LIC_DIRS` variable, the :term:`COPY_LIC_MANIFEST` variable, and the - "`Providing License - Text <&YOCTO_DOCS_DEV_URL;#providing-license-text>`__" section in the - Yocto Project Development Tasks Manual. - + ":ref:`dev-manual/dev-manual-common-tasks:providing license text`" + section in the Yocto Project Development Tasks Manual. + LICENSE_FLAGS Specifies additional flags for a recipe you must whitelist through :term:`LICENSE_FLAGS_WHITELIST` in order to allow the recipe to be built. When providing multiple flags, separate them with spaces. - + This value is independent of :term:`LICENSE` and is typically used to mark recipes that might require additional licenses in order to be used in a commercial product. For more information, - see the "`Enabling Commercially Licensed - Recipes <&YOCTO_DOCS_DEV_URL;#enabling-commercially-licensed-recipes>`__" + see the + ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`" section in the Yocto Project Development Tasks Manual. - + LICENSE_FLAGS_WHITELIST Lists license flags that when specified in :term:`LICENSE_FLAGS` within a recipe should not prevent that recipe from being built. This practice is otherwise known as "whitelisting" license flags. For more information, see the - "`Enabling Commercially Licensed - Recipes <&YOCTO_DOCS_DEV_URL;#enabling-commercially-licensed-recipes>`__" + ":ref:`dev-manual/dev-manual-common-tasks:enabling commercially licensed recipes`" section in the Yocto Project Development Tasks Manual. - + LICENSE_PATH Path to additional licenses used during the build. By default, the OpenEmbedded build system uses ``COMMON_LICENSE_DIR`` to define the directory that holds common license text used during the build. The ``LICENSE_PATH`` variable allows you to extend that location to other - areas that have additional licenses: LICENSE_PATH += - "path-to-additional-common-licenses" - + areas that have additional licenses: + :: + + LICENSE_PATH += "path-to-additional-common-licenses" + LINUX_KERNEL_TYPE Defines the kernel type to be used in assembling the configuration. The linux-yocto recipes define "standard", "tiny", and "preempt-rt" - kernel types. See the "`Kernel - Types <&YOCTO_DOCS_KERNEL_DEV_URL;#kernel-types>`__" section in the + kernel types. See the ":ref:`kernel-dev/kernel-dev-advanced:kernel types`" + section in the Yocto Project Linux Kernel Development Manual for more information on kernel types. - + If you do not specify a ``LINUX_KERNEL_TYPE``, it defaults to "standard". Together with :term:`KMACHINE`, the ``LINUX_KERNEL_TYPE`` variable defines the search arguments used by the kernel tools to find the appropriate description within the kernel :term:`Metadata` with which to build out the sources and configuration. - + LINUX_VERSION The Linux version from ``kernel.org`` on which the Linux kernel image being built using the OpenEmbedded build system is based. You define this variable in the kernel recipe. For example, the ``linux-yocto-3.4.bb`` kernel recipe found in ``meta/recipes-kernel/linux`` defines the variables as follows: - LINUX_VERSION ?= "3.4.24" - + :: + + LINUX_VERSION ?= "3.4.24" + The ``LINUX_VERSION`` variable is used to define :term:`PV` - for the recipe: PV = "${LINUX_VERSION}+git${SRCPV}" - + for the recipe: + :: + + PV = "${LINUX_VERSION}+git${SRCPV}" + LINUX_VERSION_EXTENSION A string extension compiled into the version string of the Linux kernel built with the OpenEmbedded build system. You define this variable in the kernel recipe. For example, the linux-yocto kernel - recipes all define the variable as follows: LINUX_VERSION_EXTENSION - ?= "-yocto-${:term:`LINUX_KERNEL_TYPE`}" - + recipes all define the variable as follows: + :: + + LINUX_VERSION_EXTENSION ?= "-yocto-${LINUX_KERNEL_TYPE}" + Defining this variable essentially sets the Linux kernel configuration item ``CONFIG_LOCALVERSION``, which is visible through the ``uname`` command. Here is an example that shows the extension - assuming it was set as previously shown: $ uname -r 3.7.0-rc8-custom - + assuming it was set as previously shown: + :: + + $ uname -r + 3.7.0-rc8-custom + LOG_DIR Specifies the directory to which the OpenEmbedded build system writes overall log files. The default directory is ``${TMPDIR}/log``. - + For the directory containing logs specific to each task, see the :term:`T` variable. - + MACHINE Specifies the target device for which the image is built. You define ``MACHINE`` in the ``local.conf`` file found in the :term:`Build Directory`. By default, ``MACHINE`` is set to "qemux86", which is an x86-based architecture machine to be emulated - using QEMU: MACHINE ?= "qemux86" - + using QEMU: + :: + + MACHINE ?= "qemux86" + The variable corresponds to a machine configuration file of the same name, through which machine-specific configurations are set. Thus, when ``MACHINE`` is set to "qemux86" there exists the corresponding ``qemux86.conf`` machine configuration file, which can be found in the :term:`Source Directory` in ``meta/conf/machine``. - + The list of machines supported by the Yocto Project as shipped - include the following: MACHINE ?= "qemuarm" MACHINE ?= "qemuarm64" - MACHINE ?= "qemumips" MACHINE ?= "qemumips64" MACHINE ?= "qemuppc" - MACHINE ?= "qemux86" MACHINE ?= "qemux86-64" MACHINE ?= "genericx86" - MACHINE ?= "genericx86-64" MACHINE ?= "beaglebone" MACHINE ?= - "edgerouter" The last five are Yocto Project reference hardware + include the following: + :: + + MACHINE ?= "qemuarm" + MACHINE ?= "qemuarm64" + MACHINE ?= "qemumips" + MACHINE ?= "qemumips64" + MACHINE ?= "qemuppc" + MACHINE ?= "qemux86" + MACHINE ?= "qemux86-64" + MACHINE ?= "genericx86" + MACHINE ?= "genericx86-64" + MACHINE ?= "beaglebone" + MACHINE ?= "edgerouter" + + The last five are Yocto Project reference hardware boards, which are provided in the ``meta-yocto-bsp`` layer. - + .. note:: - + Adding additional Board Support Package (BSP) layers to your configuration adds new possible settings for MACHINE . - + MACHINE_ARCH Specifies the name of the machine-specific architecture. This variable is set automatically from :term:`MACHINE` or :term:`TUNE_PKGARCH`. You should not hand-edit the ``MACHINE_ARCH`` variable. - + MACHINE_ESSENTIAL_EXTRA_RDEPENDS A list of required machine-specific packages to install as part of the image being built. The build process depends on these packages @@ -3983,19 +4443,21 @@ system and gives an overview of their function and contents. The impact of this variable affects images based on ``packagegroup-core-boot``, including the ``core-image-minimal`` image. - + This variable is similar to the ``MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`` variable with the exception that the image being built has a build dependency on the variable's list of packages. In other words, the image will not build if a file in this list is not found. - + As an example, suppose the machine for which you are building requires ``example-init`` to be run during boot to initialize the hardware. In this case, you would use the following in the machine's - ``.conf`` configuration file: MACHINE_ESSENTIAL_EXTRA_RDEPENDS += - "example-init" - + ``.conf`` configuration file: + :: + + MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "example-init" + MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS A list of recommended machine-specific packages to install as part of the image being built. The build process does not depend on these @@ -4004,7 +4466,7 @@ system and gives an overview of their function and contents. the machine to boot. The impact of this variable affects images based on ``packagegroup-core-boot``, including the ``core-image-minimal`` image. - + This variable is similar to the ``MACHINE_ESSENTIAL_EXTRA_RDEPENDS`` variable with the exception that the image being built does not have a build dependency on the variable's list of packages. In other @@ -4013,7 +4475,7 @@ system and gives an overview of their function and contents. modules, whose functionality may be selected to be built into the kernel rather than as a module, in which case a package will not be produced. - + Consider an example where you have a custom kernel where a specific touchscreen driver is required for the machine to be usable. However, the driver can be built as a module or into the kernel depending on @@ -4024,10 +4486,12 @@ system and gives an overview of their function and contents. not fail due to the missing package. To accomplish this, assuming the package for the module was called ``kernel-module-ab123``, you would use the following in the machine's ``.conf`` configuration file: - MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123" - + :: + + MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-ab123" + .. note:: - + In this example, the kernel-module-ab123 recipe needs to explicitly set its @@ -4035,25 +4499,25 @@ system and gives an overview of their function and contents. variable to ensure that BitBake does not use the kernel recipe's PACKAGES_DYNAMIC variable to satisfy the dependency. - + Some examples of these machine essentials are flash, screen, keyboard, mouse, or touchscreen drivers (depending on the machine). - + MACHINE_EXTRA_RDEPENDS A list of machine-specific packages to install as part of the image being built that are not essential for the machine to boot. However, the build process for more fully-featured images depends on the packages being present. - + This variable affects all images based on ``packagegroup-base``, which does not include the ``core-image-minimal`` or ``core-image-full-cmdline`` images. - + The variable is similar to the ``MACHINE_EXTRA_RRECOMMENDS`` variable with the exception that the image being built has a build dependency on the variable's list of packages. In other words, the image will not build if a file in this list is not found. - + An example is a machine that has WiFi capability but is not essential for the machine to boot the image. However, if you are building a more fully-featured image, you want to enable the WiFi. The package @@ -4062,22 +4526,24 @@ system and gives an overview of their function and contents. finding the package. In this case, assuming the package for the firmware was called ``wifidriver-firmware``, you would use the following in the ``.conf`` file for the machine: - MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware" - + :: + + MACHINE_EXTRA_RDEPENDS += "wifidriver-firmware" + MACHINE_EXTRA_RRECOMMENDS A list of machine-specific packages to install as part of the image being built that are not essential for booting the machine. The image being built has no build dependency on this list of packages. - + This variable affects only images based on ``packagegroup-base``, which does not include the ``core-image-minimal`` or ``core-image-full-cmdline`` images. - + This variable is similar to the ``MACHINE_EXTRA_RDEPENDS`` variable with the exception that the image being built does not have a build dependency on the variable's list of packages. In other words, the image will build if a file in this list is not found. - + An example is a machine that has WiFi capability but is not essential For the machine to boot the image. However, if you are building a more fully-featured image, you want to enable WiFi. In this case, the @@ -4087,8 +4553,10 @@ system and gives an overview of their function and contents. not being found. To accomplish this, assuming the package for the module was called ``kernel-module-examplewifi``, you would use the following in the ``.conf`` file for the machine: - MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi" - + :: + + MACHINE_EXTRA_RRECOMMENDS += "kernel-module-examplewifi" + MACHINE_FEATURES Specifies the list of hardware features the :term:`MACHINE` is capable of supporting. For related @@ -4096,48 +4564,59 @@ system and gives an overview of their function and contents. :term:`DISTRO_FEATURES`, :term:`COMBINED_FEATURES`, and :term:`IMAGE_FEATURES` variables. - + For a list of hardware features supported by the Yocto Project as shipped, see the "`Machine Features <#ref-features-machine>`__" section. - + MACHINE_FEATURES_BACKFILL Features to be added to ``MACHINE_FEATURES`` if not also present in ``MACHINE_FEATURES_BACKFILL_CONSIDERED``. - + This variable is set in the ``meta/conf/bitbake.conf`` file. It is not intended to be user-configurable. It is best to just reference the variable to see which machine features are being backfilled for all machine configurations. See the "`Feature Backfilling <#ref-features-backfill>`__" section for more information. - + MACHINE_FEATURES_BACKFILL_CONSIDERED Features from ``MACHINE_FEATURES_BACKFILL`` that should not be backfilled (i.e. added to ``MACHINE_FEATURES``) during the build. See the "`Feature Backfilling <#ref-features-backfill>`__" section for more information. - + MACHINEOVERRIDES A colon-separated list of overrides that apply to the current machine. By default, this list includes the value of :term:`MACHINE`. - + You can extend ``MACHINEOVERRIDES`` to add extra overrides that should apply to a machine. For example, all machines emulated in QEMU (e.g. ``qemuarm``, ``qemux86``, and so forth) include a file named ``meta/conf/machine/include/qemu.inc`` that prepends the following - override to ``MACHINEOVERRIDES``: MACHINEOVERRIDES =. "qemuall:" This + override to ``MACHINEOVERRIDES``: + :: + + MACHINEOVERRIDES =. "qemuall:" + + This override allows variables to be overriden for all machines emulated in QEMU, like in the following example from the ``connman-conf`` - recipe: SRC_URI_append_qemuall = "file://wired.config \\ - file://wired-setup \\ " The underlying mechanism behind + recipe: + :: + + SRC_URI_append_qemuall = "file://wired.config \ + file://wired-setup \ + " + + The underlying mechanism behind ``MACHINEOVERRIDES`` is simply that it is included in the default value of :term:`OVERRIDES`. - + MAINTAINER The email address of the distribution maintainer. - + MIRRORS Specifies additional paths from which the OpenEmbedded build system gets source code. When the build system searches for source code, it @@ -4145,20 +4624,20 @@ system and gives an overview of their function and contents. build system tries locations defined by :term:`PREMIRRORS`, the upstream source, and then locations specified by ``MIRRORS`` in that order. - + Assuming your distribution (:term:`DISTRO`) is "poky", the default value for ``MIRRORS`` is defined in the ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository. - + MLPREFIX Specifies a prefix has been added to :term:`PN` to create a special version of a recipe or package (i.e. a Multilib version). The variable is used in places where the prefix needs to be added to or removed from a the name (e.g. the :term:`BPN` variable). ``MLPREFIX`` gets set when a prefix has been added to ``PN``. - + .. note:: - + The "ML" in MLPREFIX stands for "MultiLib". This representation is historical and comes @@ -4169,7 +4648,7 @@ system and gives an overview of their function and contents. was turned into a prefix, it made sense to set MLPREFIX for it as well. - + To help understand when ``MLPREFIX`` might be needed, consider when :term:`BBCLASSEXTEND` is used to provide a ``nativesdk`` version of a recipe in addition to the target version. @@ -4177,25 +4656,37 @@ system and gives an overview of their function and contents. recipes by using :term:`DEPENDS`, then a dependency on "foo" will automatically get rewritten to a dependency on "nativesdk-foo". However, dependencies like the following will not - get rewritten automatically: do_foo[depends] += "recipe:do_foo" If - you want such a dependency to also get transformed, you can do the - following: do_foo[depends] += "${MLPREFIX}recipe:do_foo" - + get rewritten automatically: + :: + + do_foo[depends] += "recipe:do_foo" + + If you want such a dependency to also get transformed, you can do the + following: + :: + + do_foo[depends] += "${MLPREFIX}recipe:do_foo" + module_autoload This variable has been replaced by the ``KERNEL_MODULE_AUTOLOAD`` variable. You should replace all occurrences of ``module_autoload`` with additions to ``KERNEL_MODULE_AUTOLOAD``, for example: - module_autoload_rfcomm = "rfcomm" - - should now be replaced with: KERNEL_MODULE_AUTOLOAD += "rfcomm" See - the :term:`KERNEL_MODULE_AUTOLOAD` - variable for more information. - + :: + + module_autoload_rfcomm = "rfcomm" + + should now be replaced with: + :: + + KERNEL_MODULE_AUTOLOAD += "rfcomm" + + See the :term:`KERNEL_MODULE_AUTOLOAD` variable for more information. + module_conf - Specifies ```modprobe.d`http://linux.die.net/man/5/modprobe.d + Specifies `modprobe.d `_ syntax lines for inclusion in the ``/etc/modprobe.d/modname.conf`` file. - + You can use this variable anywhere that it can be recognized by the kernel recipe or out-of-tree kernel module recipe (e.g. a machine configuration file, a distribution configuration file, an append file @@ -4203,64 +4694,80 @@ system and gives an overview of their function and contents. must also be sure to list the module name in the :term:`KERNEL_MODULE_AUTOLOAD` variable. - - Here is the general syntax: module_conf_module_name = - "modprobe.d-syntax" You must use the kernel module name override. - + + Here is the general syntax: + :: + + module_conf_module_name = "modprobe.d-syntax" + + You must use the kernel module name override. + Run ``man modprobe.d`` in the shell to find out more information on the exact syntax you want to provide with ``module_conf``. - + Including ``module_conf`` causes the OpenEmbedded build system to populate the ``/etc/modprobe.d/modname.conf`` file with ``modprobe.d`` syntax lines. Here is an example that adds the options ``arg1`` and ``arg2`` to a module named ``mymodule``: - module_conf_mymodule = "options mymodule arg1=val1 arg2=val2" - + :: + + module_conf_mymodule = "options mymodule arg1=val1 arg2=val2" + For information on how to specify kernel modules to auto-load on - boot, see the - :term:`KERNEL_MODULE_AUTOLOAD` - variable. - + boot, see the :term:`KERNEL_MODULE_AUTOLOAD` variable. + MODULE_TARBALL_DEPLOY Controls creation of the ``modules-*.tgz`` file. Set this variable to "0" to disable creation of this file, which contains all of the kernel modules resulting from a kernel build. - + MODULE_TARBALL_LINK_NAME The link name of the kernel module tarball. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as follows: - MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" The value + :: + + MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}" + + The value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the - same file, has the following value: KERNEL_ARTIFACT_LINK_NAME ?= - "${MACHINE}" - - See the :term:`MACHINE` variable for additional - information. - + same file, has the following value: + :: + + KERNEL_ARTIFACT_LINK_NAME ?= "${MACHINE}" + + See the :term:`MACHINE` variable for additional information. + MODULE_TARBALL_NAME The base name of the kernel module tarball. This variable is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as follows: - MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}" The value of the - :term:`KERNEL_ARTIFACT_NAME` variable, + :: + + MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}" + + The value of the :term:`KERNEL_ARTIFACT_NAME` variable, which is set in the same file, has the following value: - KERNEL_ARTIFACT_NAME ?= - "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" - + :: + + KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}" + MULTIMACH_TARGET_SYS Uniquely identifies the type of the target system for which packages are being built. This variable allows output for different types of target systems to be put into different subdirectories of the same output directory. - + The default value of this variable is: - ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS} Some classes (e.g. + :: + + ${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS} + + Some classes (e.g. :ref:`cross-canadian `) modify the ``MULTIMACH_TARGET_SYS`` value. - + See the :term:`STAMP` variable for an example. See the - :term:`STAGING_DIR_TARGET` variable for - more information. - + :term:`STAGING_DIR_TARGET` variable for more information. + NATIVELSBSTRING A string identifying the host distribution. Strings consist of the host distributor ID followed by the release, as reported by the @@ -4268,17 +4775,17 @@ system and gives an overview of their function and contents. example, when running a build on Ubuntu 12.10, the value is "Ubuntu-12.10". If this information is unable to be determined, the value resolves to "Unknown". - + This variable is used by default to isolate native shared state packages for different distributions (e.g. to avoid problems with ``glibc`` version incompatibilities). Additionally, the variable is checked against :term:`SANITY_TESTED_DISTROS` if that variable is set. - + NM The minimal command and arguments to run ``nm``. - + NO_GENERIC_LICENSE Avoids QA errors when you use a non-common, non-CLOSED license in a recipe. Packages exist, such as the linux-firmware package, with many @@ -4287,60 +4794,71 @@ system and gives an overview of their function and contents. which are only applicable to a specific package. ``NO_GENERIC_LICENSE`` is used to allow copying a license that does not exist in common licenses. - + The following example shows how to add ``NO_GENERIC_LICENSE`` to a - recipe: NO_GENERIC_LICENSE[license_name] = - "license_file_in_fetched_source" The following is an example that + recipe: + :: + + NO_GENERIC_LICENSE[license_name] = "license_file_in_fetched_source" + + The following is an example that uses the ``LICENSE.Abilis.txt`` file as the license from the fetched - source: NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt" - + source: + :: + + NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt" + NO_RECOMMENDATIONS Prevents installation of all "recommended-only" packages. Recommended-only packages are packages installed only through the :term:`RRECOMMENDS` variable). Setting the - ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on: - NO_RECOMMENDATIONS = "1" - + ``NO_RECOMMENDATIONS`` variable to "1" turns this feature on: :: + + NO_RECOMMENDATIONS = "1" + You can set this variable globally in your ``local.conf`` file or you can attach it to a specific image recipe by using the recipe name - override: NO_RECOMMENDATIONS_pn-target_image = "1" - + override: :: + + NO_RECOMMENDATIONS_pn-target_image = "1" + It is important to realize that if you choose to not install packages using this variable and some other packages are dependent on them (i.e. listed in a recipe's :term:`RDEPENDS` variable), the OpenEmbedded build system ignores your request and will install the packages to avoid dependency errors. - + .. note:: - + Some recommended packages might be required for certain system functionality, such as kernel modules. It is up to you to add - packages with the - IMAGE_INSTALL - variable. - + packages with the IMAGE_INSTALL variable. + Support for this variable exists only when using the IPK and RPM packaging backend. Support does not exist for DEB. - + See the :term:`BAD_RECOMMENDATIONS` and the :term:`PACKAGE_EXCLUDE` variables for related information. - + NOAUTOPACKAGEDEBUG Disables auto package from splitting ``.debug`` files. If a recipe requires ``FILES_${PN}-dbg`` to be set manually, the ``NOAUTOPACKAGEDEBUG`` can be defined allowing you to define the - content of the debug package. For example: NOAUTOPACKAGEDEBUG = "1" - FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*" FILES_${PN}-dbg - = "/usr/src/debug/" FILES_${QT_BASE_NAME}-demos-doc = - "${docdir}/${QT_DIR_NAME}/qch/qt.qch" - + content of the debug package. For example: + :: + + NOAUTOPACKAGEDEBUG = "1" + FILES_${PN}-dev = "${includedir}/${QT_DIR_NAME}/Qt/*" + FILES_${PN}-dbg = "/usr/src/debug/" + FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch" + OBJCOPY The minimal command and arguments to run ``objcopy``. - + OBJDUMP The minimal command and arguments to run ``objdump``. - + OE_BINCONFIG_EXTRA_MANGLE When inheriting the :ref:`binconfig ` class, this variable specifies additional arguments passed to the "sed" @@ -4349,60 +4867,66 @@ system and gives an overview of their function and contents. results in all paths in these scripts being changed to point into the ``sysroots/`` directory so that all builds that use the script will use the correct directories for the cross compiling layout. - - See the ``meta/classes/binconfig.bbclass`` in the + + See the ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory` for details on how this class applies these additional sed command arguments. For general information on the ``binconfig`` class, see the ":ref:`binconfig.bbclass `" section. - + OE_IMPORTS An internal variable used to tell the OpenEmbedded build system what Python modules to import for every Python function run by the system. - + .. note:: - + Do not set this variable. It is for internal use only. - + OE_INIT_ENV_SCRIPT The name of the build environment setup script for the purposes of setting up the environment within the extensible SDK. The default value is "oe-init-build-env". - + If you use a custom script to set up your build environment, set the ``OE_INIT_ENV_SCRIPT`` variable to its name. - + OE_TERMINAL Controls how the OpenEmbedded build system spawns interactive terminals on the host development system (e.g. using the BitBake command with the ``-c devshell`` command-line option). For more - information, see the "`Using a Development - Shell <&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell>`__" section in + information, see the ":ref:`platdev-appdev-devshell`" section in the Yocto Project Development Tasks Manual. - + You can use the following values for the ``OE_TERMINAL`` variable: - auto gnome xfce rxvt screen konsole none - + + - auto + - gnome + - xfce + - rxvt + - screen + - konsole + - none + OEROOT The directory from which the top-level build environment setup script is sourced. The Yocto Project provides a top-level build environment setup script: ````` <#structure-core-script>`__. When you run this script, the ``OEROOT`` variable resolves to the directory that contains the script. - + For additional information on how this variable is used, see the initialization script. - + OLDEST_KERNEL Declares the oldest version of the Linux kernel that the produced binaries must support. This variable is passed into the build of the Embedded GNU C Library (``glibc``). - + The default for this variable comes from the ``meta/conf/bitbake.conf`` configuration file. You can override this default by setting the variable in a custom distribution configuration file. - + OVERRIDES A colon-separated list of overrides that currently apply. Overrides are a BitBake mechanism that allows variables to be selectively @@ -4410,26 +4934,33 @@ system and gives an overview of their function and contents. ``OVERRIDES`` represents the "state" during building, which includes the current recipe being built, the machine for which it is being built, and so forth. - + As an example, if the string "an-override" appears as an element in the colon-separated list in ``OVERRIDES``, then the following assignment will override ``FOO`` with the value "overridden" at the - end of parsing: FOO_an-override = "overridden" See the + end of parsing: + :: + + FOO_an-override = "overridden" + + See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:conditional syntax (overrides)`" section in the BitBake User Manual for more information on the overrides mechanism. - + The default value of ``OVERRIDES`` includes the values of the :term:`CLASSOVERRIDE`, :term:`MACHINEOVERRIDES`, and :term:`DISTROOVERRIDES` variables. Another important override included by default is ``pn-${PN}``. This override allows variables to be set for a single recipe within configuration - (``.conf``) files. Here is an example: FOO_pn-myrecipe = - "myrecipe-specific value" - + (``.conf``) files. Here is an example: + :: + + FOO_pn-myrecipe = "myrecipe-specific value" + .. note:: - + An easy way to see what overrides apply is to search for OVERRIDES in the output of the @@ -4438,128 +4969,134 @@ system and gives an overview of their function and contents. Viewing Variable Values " section in the Yocto Project Development Tasks Manual for more information. - + P The recipe name and version. ``P`` is comprised of the following: - ${PN}-${PV} - + :: + + ${PN}-${PV} + PACKAGE_ADD_METADATA This variable defines additional metdata to add to packages. - + You may find you need to inject additional metadata into packages. This variable allows you to do that by setting the injected data as the value. Multiple fields can be added by splitting the content with the literal separator "\n". - + The suffixes '_IPK', '_DEB', or '_RPM' can be applied to the variable to do package type specific settings. It can also be made package specific by using the package name as a suffix. - - You can find out more about applying this variable in the "`Adding - custom metadata to - packages <&YOCTO_DOCS_DEV_URL;#adding-custom-metadata-to-packages>`__" + + You can find out more about applying this variable in the + ":ref:`dev-manual/dev-manual-common-tasks:adding custom metadata to packages`" section in the Yocto Project Development Tasks Manual. - + PACKAGE_ARCH The architecture of the resulting package or packages. - + By default, the value of this variable is set to :term:`TUNE_PKGARCH` when building for the target, :term:`BUILD_ARCH` when building for the build host, and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building for the SDK. - + .. note:: - + See SDK_ARCH for more information. - + However, if your recipe's output packages are built specific to the target machine rather than generally for the architecture of the machine, you should set ``PACKAGE_ARCH`` to the value of :term:`MACHINE_ARCH` in the recipe as follows: - PACKAGE_ARCH = "${MACHINE_ARCH}" - + :: + + PACKAGE_ARCH = "${MACHINE_ARCH}" + PACKAGE_ARCHS Specifies a list of architectures compatible with the target machine. This variable is set automatically and should not normally be hand-edited. Entries are separated using spaces and listed in order of priority. The default value for ``PACKAGE_ARCHS`` is "all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}". - + PACKAGE_BEFORE_PN Enables easily adding packages to ``PACKAGES`` before ``${PN}`` so that those added packages can pick up files that would normally be included in the default package. - + PACKAGE_CLASSES This variable, which is set in the ``local.conf`` configuration file found in the ``conf`` folder of the :term:`Build Directory`, specifies the package manager the OpenEmbedded build system uses when packaging data. - + You can provide one or more of the following arguments for the variable: PACKAGE_CLASSES ?= "package_rpm package_deb package_ipk package_tar" - + .. note:: - + While it is a legal option, the package_tar class has limited functionality due to no support for package dependencies by that backend. Therefore, it is recommended that you do not use it. - + The build system uses only the first argument in the list as the package manager when creating your image or SDK. However, packages will be created using any additional packaging classes you specify. For example, if you use the following in your ``local.conf`` file: - PACKAGE_CLASSES ?= "package_ipk" The OpenEmbedded build system uses + :: + + PACKAGE_CLASSES ?= "package_ipk" + + The OpenEmbedded build system uses the IPK package manager to create your image or SDK. - + For information on packaging and build performance effects as a result of the package manager in use, see the ":ref:`package.bbclass `" section. - + PACKAGE_DEBUG_SPLIT_STYLE Determines how to split up the binary and debug information when creating ``*-dbg`` packages to be used with the GNU Project Debugger (GDB). - + With the ``PACKAGE_DEBUG_SPLIT_STYLE`` variable, you can control where debug information, which can include or exclude source files, is stored: - + - ".debug": Debug symbol files are placed next to the binary in a ``.debug`` directory on the target. For example, if a binary is installed into ``/bin``, the corresponding debug symbol files are installed in ``/bin/.debug``. Source files are placed in ``/usr/src/debug``. - + - "debug-file-directory": Debug symbol files are placed under ``/usr/lib/debug`` on the target, and separated by the path from where the binary is installed. For example, if a binary is installed in ``/bin``, the corresponding debug symbols are installed in ``/usr/lib/debug/bin``. Source files are placed in ``/usr/src/debug``. - + - "debug-without-src": The same behavior as ".debug" previously described with the exception that no source files are installed. - + - "debug-with-srcpkg": The same behavior as ".debug" previously described with the exception that all source files are placed in a separate ``*-src`` pkg. This is the default behavior. - + You can find out more about debugging using GDB by reading the - "`Debugging With the GNU Project Debugger (GDB) - Remotely <&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug>`__" section + ":ref:`platdev-gdb-remotedebug`" section in the Yocto Project Development Tasks Manual. - + PACKAGE_EXCLUDE_COMPLEMENTARY Prevents specific packages from being installed when you are installing complementary packages. - + You might find that you want to prevent installing certain packages when you are installing complementary packages. For example, if you are using :term:`IMAGE_FEATURES` to install @@ -4567,16 +5104,21 @@ system and gives an overview of their function and contents. particular multilib. If you find yourself in this situation, you can use the ``PACKAGE_EXCLUDE_COMPLEMENTARY`` variable to specify regular expressions to match the packages you want to exclude. - + PACKAGE_EXCLUDE Lists packages that should not be installed into an image. For - example: PACKAGE_EXCLUDE = "package_name package_name package_name - ..." - + example: + :: + + PACKAGE_EXCLUDE = "package_name package_name package_name ..." + You can set this variable globally in your ``local.conf`` file or you can attach it to a specific image recipe by using the recipe name - override: PACKAGE_EXCLUDE_pn-target_image = "package_name" - + override: + :: + + PACKAGE_EXCLUDE_pn-target_image = "package_name" + If you choose to not install a package using this variable and some other package is dependent on it (i.e. listed in a recipe's :term:`RDEPENDS` variable), the OpenEmbedded build @@ -4584,19 +5126,19 @@ system and gives an overview of their function and contents. halts the process with a fatal error, you can use the variable with an iterative development process to remove specific components from a system. - + Support for this variable exists only when using the IPK and RPM packaging backend. Support does not exist for DEB. - + See the :term:`NO_RECOMMENDATIONS` and the :term:`BAD_RECOMMENDATIONS` variables for related information. - + PACKAGE_EXTRA_ARCHS Specifies the list of architectures compatible with the device CPU. This variable is useful when you build for several different devices that use miscellaneous processors such as XScale and ARM926-EJS. - + PACKAGE_FEED_ARCHS Optionally specifies the package architectures used as part of the package feed URIs during the build. When used, the @@ -4605,9 +5147,9 @@ system and gives an overview of their function and contents. :term:`PACKAGE_FEED_URIS` and :term:`PACKAGE_FEED_BASE_PATHS` variables. - + .. note:: - + You can use the PACKAGE_FEEDS_ARCHS variable to whitelist specific package architectures. If you do @@ -4615,73 +5157,91 @@ system and gives an overview of their function and contents. case, you can omit this variable. Omitting the variable results in all available architectures for the current machine being included into remote package feeds. - + Consider the following example where the ``PACKAGE_FEED_URIS``, ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are - defined in your ``local.conf`` file: PACKAGE_FEED_URIS = - "https://example.com/packagerepos/release \\ - https://example.com/packagerepos/updates" PACKAGE_FEED_BASE_PATHS = - "rpm rpm-dev" PACKAGE_FEED_ARCHS = "all core2-64" Given these - settings, the resulting package feeds are as follows: - https://example.com/packagerepos/release/rpm/all - https://example.com/packagerepos/release/rpm/core2-64 - https://example.com/packagerepos/release/rpm-dev/all - https://example.com/packagerepos/release/rpm-dev/core2-64 - https://example.com/packagerepos/updates/rpm/all - https://example.com/packagerepos/updates/rpm/core2-64 - https://example.com/packagerepos/updates/rpm-dev/all - https://example.com/packagerepos/updates/rpm-dev/core2-64 - + defined in your ``local.conf`` file: + :: + + PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \ + https://example.com/packagerepos/updates" + PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev" + PACKAGE_FEED_ARCHS = "all core2-64" + + Given these settings, the resulting package feeds are as follows: + :: + + https://example.com/packagerepos/release/rpm/all + https://example.com/packagerepos/release/rpm/core2-64 + https://example.com/packagerepos/release/rpm-dev/all + https://example.com/packagerepos/release/rpm-dev/core2-64 + https://example.com/packagerepos/updates/rpm/all + https://example.com/packagerepos/updates/rpm/core2-64 + https://example.com/packagerepos/updates/rpm-dev/all + https://example.com/packagerepos/updates/rpm-dev/core2-64 + PACKAGE_FEED_BASE_PATHS Specifies the base path used when constructing package feed URIs. The ``PACKAGE_FEED_BASE_PATHS`` variable makes up the middle portion of a package feed URI used by the OpenEmbedded build system. The base path lies between the :term:`PACKAGE_FEED_URIS` and :term:`PACKAGE_FEED_ARCHS` variables. - + Consider the following example where the ``PACKAGE_FEED_URIS``, ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are - defined in your ``local.conf`` file: PACKAGE_FEED_URIS = - "https://example.com/packagerepos/release \\ - https://example.com/packagerepos/updates" PACKAGE_FEED_BASE_PATHS = - "rpm rpm-dev" PACKAGE_FEED_ARCHS = "all core2-64" Given these - settings, the resulting package feeds are as follows: - https://example.com/packagerepos/release/rpm/all - https://example.com/packagerepos/release/rpm/core2-64 - https://example.com/packagerepos/release/rpm-dev/all - https://example.com/packagerepos/release/rpm-dev/core2-64 - https://example.com/packagerepos/updates/rpm/all - https://example.com/packagerepos/updates/rpm/core2-64 - https://example.com/packagerepos/updates/rpm-dev/all - https://example.com/packagerepos/updates/rpm-dev/core2-64 - + defined in your ``local.conf`` file: + :: + + PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \ + https://example.com/packagerepos/updates" + PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev" + PACKAGE_FEED_ARCHS = "all core2-64" + + Given these settings, the resulting package feeds are as follows: + :: + + https://example.com/packagerepos/release/rpm/all + https://example.com/packagerepos/release/rpm/core2-64 + https://example.com/packagerepos/release/rpm-dev/all + https://example.com/packagerepos/release/rpm-dev/core2-64 + https://example.com/packagerepos/updates/rpm/all + https://example.com/packagerepos/updates/rpm/core2-64 + https://example.com/packagerepos/updates/rpm-dev/all + https://example.com/packagerepos/updates/rpm-dev/core2-64 + PACKAGE_FEED_URIS Specifies the front portion of the package feed URI used by the OpenEmbedded build system. Each final package feed URI is comprised of ``PACKAGE_FEED_URIS``, :term:`PACKAGE_FEED_BASE_PATHS`, and :term:`PACKAGE_FEED_ARCHS` variables. - + Consider the following example where the ``PACKAGE_FEED_URIS``, ``PACKAGE_FEED_BASE_PATHS``, and ``PACKAGE_FEED_ARCHS`` variables are - defined in your ``local.conf`` file: PACKAGE_FEED_URIS = - "https://example.com/packagerepos/release \\ - https://example.com/packagerepos/updates" PACKAGE_FEED_BASE_PATHS = - "rpm rpm-dev" PACKAGE_FEED_ARCHS = "all core2-64" Given these - settings, the resulting package feeds are as follows: - https://example.com/packagerepos/release/rpm/all - https://example.com/packagerepos/release/rpm/core2-64 - https://example.com/packagerepos/release/rpm-dev/all - https://example.com/packagerepos/release/rpm-dev/core2-64 - https://example.com/packagerepos/updates/rpm/all - https://example.com/packagerepos/updates/rpm/core2-64 - https://example.com/packagerepos/updates/rpm-dev/all - https://example.com/packagerepos/updates/rpm-dev/core2-64 - + defined in your ``local.conf`` file: + :: + + PACKAGE_FEED_URIS = "https://example.com/packagerepos/release \ + https://example.com/packagerepos/updates" + PACKAGE_FEED_BASE_PATHS = "rpm rpm-dev" + PACKAGE_FEED_ARCHS = "all core2-64" + + Given these settings, the resulting package feeds are as follows: + :: + + https://example.com/packagerepos/release/rpm/all + https://example.com/packagerepos/release/rpm/core2-64 + https://example.com/packagerepos/release/rpm-dev/all + https://example.com/packagerepos/release/rpm-dev/core2-64 + https://example.com/packagerepos/updates/rpm/all + https://example.com/packagerepos/updates/rpm/core2-64 + https://example.com/packagerepos/updates/rpm-dev/all + https://example.com/packagerepos/updates/rpm-dev/core2-64 + PACKAGE_INSTALL The final list of packages passed to the package manager for installation into the image. - + Because the package manager controls actual installation of all packages, the list of packages passed using ``PACKAGE_INSTALL`` is not the final list of packages that are actually installed. This @@ -4693,21 +5253,20 @@ system and gives an overview of their function and contents. ```core-image-minimal-initramfs`` <#images-core-image-minimal-initramfs>`__ image. When working with an initial RAM filesystem (initramfs) image, use the ``PACKAGE_INSTALL`` variable. For information on creating an - initramfs, see the "`Building an Initial RAM Filesystem (initramfs) - Image <&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image>`__" section + initramfs, see the ":ref:`building-an-initramfs-image`" section in the Yocto Project Development Tasks Manual. - + PACKAGE_INSTALL_ATTEMPTONLY Specifies a list of packages the OpenEmbedded build system attempts to install when creating an image. If a listed package fails to install, the build system does not generate an error. This variable is generally not user-defined. - + PACKAGE_PREPROCESS_FUNCS Specifies a list of functions run to pre-process the :term:`PKGD` directory prior to splitting the files out to individual packages. - + PACKAGE_WRITE_DEPS Specifies a list of dependencies for post-installation and pre-installation scripts on native/cross tools. If your @@ -4715,93 +5274,114 @@ system and gives an overview of their function and contents. creation time rather than on the target but depends on a native tool in order to execute, you need to list the tools in ``PACKAGE_WRITE_DEPS``. - + For information on running post-installation scripts, see the - "`Post-Installation - Scripts <&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts>`__" + ":ref:`dev-manual/dev-manual-common-tasks:post-installation scripts`" section in the Yocto Project Development Tasks Manual. - + PACKAGECONFIG This variable provides a means of enabling or disabling features of a recipe on a per-recipe basis. ``PACKAGECONFIG`` blocks are defined in recipes when you specify features and then arguments that define feature behaviors. Here is the basic block structure (broken over - multiple lines for readability): PACKAGECONFIG ??= "f1 f2 f3 ..." - PACKAGECONFIG[f1] = "\\ --with-f1, \\ --without-f1, \\ - build-deps-for-f1, \\ runtime-deps-for-f1, \\ - runtime-recommends-for-f1, \\ packageconfig-conflicts-for-f1 \\ " - PACKAGECONFIG[f2] = "\\ ... and so on and so on ... - + multiple lines for readability): + :: + + PACKAGECONFIG ??= "f1 f2 f3 ..." + PACKAGECONFIG[f1] = "\ + --with-f1, \ + --without-f1, \ + build-deps-for-f1, \ + runtime-deps-for-f1, \ + runtime-recommends-for-f1, \ + packageconfig-conflicts-for-f1" + PACKAGECONFIG[f2] = "\ + ... and so on and so on ... + The ``PACKAGECONFIG`` variable itself specifies a space-separated list of the features to enable. Following the features, you can determine the behavior of each feature by providing up to six order-dependent arguments, which are separated by commas. You can omit any argument you like but must retain the separating commas. The order is important and specifies the following: - + 1. Extra arguments that should be added to the configure script argument list (:term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS`) if the feature is enabled. - + 2. Extra arguments that should be added to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS`` if the feature is disabled. - + 3. Additional build dependencies (:term:`DEPENDS`) that should be added if the feature is enabled. - + 4. Additional runtime dependencies (:term:`RDEPENDS`) that should be added if the feature is enabled. - + 5. Additional runtime recommendations (:term:`RRECOMMENDS`) that should be added if the feature is enabled. - + 6. Any conflicting (that is, mutually exclusive) ``PACKAGECONFIG`` settings for this feature. - + Consider the following ``PACKAGECONFIG`` block taken from the ``librsvg`` recipe. In this example the feature is ``gtk``, which has three arguments that determine the feature's behavior. - PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3" The + :: + + PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3" + + The ``--with-gtk3`` and ``gtk+3`` arguments apply only if the feature is enabled. In this case, ``--with-gtk3`` is added to the configure script argument list and ``gtk+3`` is added to ``DEPENDS``. On the other hand, if the feature is disabled say through a ``.bbappend`` file in another layer, then the second argument ``--without-gtk3`` is added to the configure script instead. - + The basic ``PACKAGECONFIG`` structure previously described holds true regardless of whether you are creating a block or changing a block. When creating a block, use the structure inside your recipe. - + If you want to change an existing ``PACKAGECONFIG`` block, you can do so one of two ways: - + - *Append file:* Create an append file named recipename\ ``.bbappend`` in your layer and override the value of ``PACKAGECONFIG``. You can either completely override the - variable: PACKAGECONFIG = "f4 f5" Or, you can just append the - variable: PACKAGECONFIG_append = " f4" - + variable: + :: + + PACKAGECONFIG = "f4 f5" + + Or, you can just append the variable: + :: + + PACKAGECONFIG_append = " f4" + - *Configuration file:* This method is identical to changing the block through an append file except you edit your ``local.conf`` or ``mydistro.conf`` file. As with append files previously described, you can either completely override the variable: PACKAGECONFIG_pn-recipename = "f4 f5" Or, you can just amend the - variable: PACKAGECONFIG_append_pn-recipename = " f4" - + variable: + :: + + PACKAGECONFIG_append_pn-recipename = " f4" + PACKAGECONFIG_CONFARGS A space-separated list of configuration options generated from the :term:`PACKAGECONFIG` setting. - + Classes such as :ref:`autotools ` and :ref:`cmake ` use ``PACKAGECONFIG_CONFARGS`` to pass ``PACKAGECONFIG`` options to ``configure`` and ``cmake``, respectively. If you are using ``PACKAGECONFIG`` but not a class that handles the ``do_configure`` task, then you need to use ``PACKAGECONFIG_CONFARGS`` appropriately. - + PACKAGEGROUP_DISABLE_COMPLEMENTARY For recipes inheriting the :ref:`packagegroup ` class, setting @@ -4809,25 +5389,27 @@ system and gives an overview of their function and contents. normal complementary packages (i.e. ``-dev``, ``-dbg``, and so forth) should not be automatically created by the ``packagegroup`` recipe, which is the default behavior. - + PACKAGES The list of packages the recipe creates. The default value is the - following: ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale - ${PACKAGE_BEFORE_PN} ${PN} - + following: + :: + + ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN} + During packaging, the :ref:`ref-tasks-package` task goes through ``PACKAGES`` and uses the :term:`FILES` variable corresponding to each package to assign files to the package. If a file matches the ``FILES`` variable for more than one package in ``PACKAGES``, it will be assigned to the earliest (leftmost) package. - + Packages in the variable's list that are empty (i.e. where none of the patterns in ``FILES_``\ pkg match any files installed by the :ref:`ref-tasks-install` task) are not generated, unless generation is forced through the :term:`ALLOW_EMPTY` variable. - + PACKAGES_DYNAMIC A promise that your recipe satisfies runtime dependencies for optional modules that are found in other recipes. @@ -4840,17 +5422,17 @@ system and gives an overview of their function and contents. to include that package in an image, you will get a dependency failure from the packaging system during the :ref:`ref-tasks-rootfs` task. - + Typically, if there is a chance that such a situation can occur and the package that is not created is valid without the dependency being satisfied, then you should use :term:`RRECOMMENDS` (a soft runtime dependency) instead of ``RDEPENDS``. - + For an example of how to use the ``PACKAGES_DYNAMIC`` variable when - you are splitting packages, see the "`Handling Optional Module - Packaging <&YOCTO_DOCS_DEV_URL;#handling-optional-module-packaging>`__" + you are splitting packages, see the + ":ref:`dev-manual/dev-manual-common-tasks:handling optional module packaging`" section in the Yocto Project Development Tasks Manual. - + PACKAGESPLITFUNCS Specifies a list of functions run to perform additional splitting of files into individual packages. Recipes can either prepend to this @@ -4860,16 +5442,16 @@ system and gives an overview of their function and contents. :term:`FILES`, :term:`RDEPENDS` and other packaging variables appropriately in order to perform the desired splitting. - + PARALLEL_MAKE Extra options passed to the ``make`` command during the :ref:`ref-tasks-compile` task in order to specify parallel compilation on the local build host. This variable is usually in the form "-j x", where x represents the maximum number of parallel threads ``make`` can run. - + .. note:: - + In order for PARALLEL_MAKE to be effective, @@ -4881,12 +5463,12 @@ system and gives an overview of their function and contents. . An easy way to ensure this is to use the oe_runmake function. - + By default, the OpenEmbedded build system automatically sets this variable to be equal to the number of cores the build system uses. - + .. note:: - + If the software being built experiences dependency issues during the do_compile @@ -4896,50 +5478,49 @@ system and gives an overview of their function and contents. addressing race conditions, see the " Debugging Parallel Make Races " section in the Yocto Project Development Tasks Manual. - + For single socket systems (i.e. one CPU), you should not have to override this variable to gain optimal parallelism during builds. However, if you have very large systems that employ multiple physical CPUs, you might want to make sure the ``PARALLEL_MAKE`` variable is not set higher than "-j 20". - - For more information on speeding up builds, see the "`Speeding Up a - Build <&YOCTO_DOCS_DEV_URL;#speeding-up-a-build>`__" section in the - Yocto Project Development Tasks Manual. - + + For more information on speeding up builds, see the + ":ref:`dev-manual/dev-manual-common-tasks:speeding up a build`" + section in the Yocto Project Development Tasks Manual. + PARALLEL_MAKEINST Extra options passed to the ``make install`` command during the :ref:`ref-tasks-install` task in order to specify parallel installation. This variable defaults to the value of :term:`PARALLEL_MAKE`. - + .. note:: - + In order for ``PARALLEL_MAKEINST`` to be effective, ``make`` must be called with ``${``\ :term:`EXTRA_OEMAKE`\ ``}``. An easy way to ensure this is to use the ``oe_runmake`` function. - + If the software being built experiences dependency issues during the ``do_install`` task that result in race conditions, you can clear the ``PARALLEL_MAKEINST`` variable within the recipe as a workaround. For information on addressing race conditions, see the - "`Debugging Parallel Make - Races <&YOCTO_DOCS_DEV_URL;#debugging-parallel-make-races>`__" + ":ref:`dev-manual/dev-manual-common-tasks:debugging parallel make races`" section in the Yocto Project Development Tasks Manual. - + PATCHRESOLVE Determines the action to take when a patch fails. You can set this variable to one of two values: "noop" and "user". - + The default value of "noop" causes the build to simply fail when the OpenEmbedded build system cannot successfully apply a patch. Setting the value to "user" causes the build system to launch a shell and places you in the right location so that you can manually resolve the conflicts. - + Set this variable in your ``local.conf`` file. - + PATCHTOOL Specifies the utility used to apply patches for a recipe during the :ref:`ref-tasks-patch` task. You can specify one of @@ -4947,24 +5528,28 @@ system and gives an overview of their function and contents. is "quilt" except for the quilt-native recipe itself. Because the quilt tool is not available at the time quilt-native is being patched, it uses "patch". - + If you wish to use an alternative patching tool, set the variable in - the recipe using one of the following: PATCHTOOL = "patch" PATCHTOOL - = "quilt" PATCHTOOL = "git" - + the recipe using one of the following: + :: + + PATCHTOOL = "patch" + PATCHTOOL = "quilt" + PATCHTOOL = "git" + 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. - + ``PE`` is the default value of the :term:`PKGE` variable. - + PF Specifies the recipe or package name and includes all version and revision numbers (i.e. ``glibc-2.13-r20+svnr15508/`` and ``bash-4.2-r1/``). This variable is comprised of the following: ${:term:`PN`}-${:term:`EXTENDPE`}${:term:`PV`}-${:term:`PR`} - + PIXBUF_PACKAGES When inheriting the :ref:`pixbufcache ` class, this variable identifies packages that contain the pixbuf @@ -4972,139 +5557,158 @@ system and gives an overview of their function and contents. class assumes that the loaders are in the recipe's main package (i.e. ``${``\ :term:`PN`\ ``}``). Use this variable if the loaders you need are in a package other than that main package. - + PKG The name of the resulting package created by the OpenEmbedded build system. - + .. note:: - + When using the PKG variable, you must use a package name override. - + For example, when the :ref:`debian ` class renames the output package, it does so by setting ``PKG_packagename``. - + PKG_CONFIG_PATH The path to ``pkg-config`` files for the current build context. ``pkg-config`` reads this variable from the environment. - + PKGD Points to the destination directory for files to be packaged before they are split into individual packages. This directory defaults to - the following: ${WORKDIR}/package - + the following: + :: + + ${WORKDIR}/package + Do not change this default. - + PKGDATA_DIR Points to a shared, global-state directory that holds data generated during the packaging process. During the packaging process, the :ref:`ref-tasks-packagedata` task packages data for each recipe and installs it into this temporary, shared area. This directory defaults to the following, which you should not - change: ${STAGING_DIR_HOST}/pkgdata For examples of how this data is - used, see the "`Automatically Added Runtime - Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__" + change: + :: + + ${STAGING_DIR_HOST}/pkgdata + + For examples of how this data is used, see the + ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`" section in the Yocto Project Overview and Concepts Manual and the - "`Viewing Package Information with - ``oe-pkgdata-util`` <&YOCTO_DOCS_DEV_URL;#viewing-package-information-with-oe-pkgdata-util>`__" + ":ref:`dev-manual/dev-manual-common-tasks:viewing package information with \`\`oe-pkgdata-util\`\``" section in the Yocto Project Development Tasks Manual. For more information on the shared, global-state directory, see :term:`STAGING_DIR_HOST`. - + PKGDEST Points to the parent directory for files to be packaged after they have been split into individual packages. This directory defaults to - the following: ${WORKDIR}/packages-split - + the following: + :: + + ${WORKDIR}/packages-split + Under this directory, the build system creates directories for each package specified in :term:`PACKAGES`. Do not change this default. - + PKGDESTWORK Points to a temporary work area where the :ref:`ref-tasks-package` task saves package metadata. The ``PKGDESTWORK`` location defaults to the following: - ${WORKDIR}/pkgdata Do not change this default. - + :: + + ${WORKDIR}/pkgdata + + Do not change this default. + The :ref:`ref-tasks-packagedata` task copies the package metadata from ``PKGDESTWORK`` to :term:`PKGDATA_DIR` to make it available globally. - + PKGE The epoch of the package(s) built by the recipe. By default, ``PKGE`` is set to :term:`PE`. - + PKGR The revision of the package(s) built by the recipe. By default, ``PKGR`` is set to :term:`PR`. - + PKGV The version of the package(s) built by the recipe. By default, ``PKGV`` is set to :term:`PV`. - + PN This variable can have two separate functions depending on the context: a recipe name or a resulting package name. - + ``PN`` refers to a recipe name in the context of a file used by the OpenEmbedded build system as input to create a package. The name is normally extracted from the recipe file name. For example, if the recipe is named ``expat_2.0.1.bb``, then the default value of ``PN`` will be "expat". - + The variable refers to a package name in the context of a file created or produced by the OpenEmbedded build system. - + If applicable, the ``PN`` variable also contains any special suffix or prefix. For example, using ``bash`` to build packages for the native machine, ``PN`` is ``bash-native``. Using ``bash`` to build packages for the target and for Multilib, ``PN`` would be ``bash`` and ``lib64-bash``, respectively. - + PNBLACKLIST Lists recipes you do not want the OpenEmbedded build system to build. This variable works in conjunction with the :ref:`blacklist ` class, which is inherited globally. - + To prevent a recipe from being built, use the ``PNBLACKLIST`` variable in your ``local.conf`` file. Here is an example that - prevents ``myrecipe`` from being built: PNBLACKLIST[myrecipe] = "Not - supported by our organization." - + prevents ``myrecipe`` from being built: + :: + + PNBLACKLIST[myrecipe] = "Not supported by our organization." + POPULATE_SDK_POST_HOST_COMMAND Specifies a list of functions to call once the OpenEmbedded build system has created the host part of the SDK. You can specify - functions separated by semicolons: POPULATE_SDK_POST_HOST_COMMAND += - "function; ... " - + functions separated by semicolons: + :: + + POPULATE_SDK_POST_HOST_COMMAND += "function; ... " + If you need to pass the SDK path to a command within a function, you can use ``${SDK_DIR}``, which points to the parent directory used by the OpenEmbedded build system when creating SDK output. See the :term:`SDK_DIR` variable for more information. - + POPULATE_SDK_POST_TARGET_COMMAND Specifies a list of functions to call once the OpenEmbedded build system has created the target part of the SDK. You can specify - functions separated by semicolons: POPULATE_SDK_POST_TARGET_COMMAND - += "function; ... " - + functions separated by semicolons: + :: + + POPULATE_SDK_POST_TARGET_COMMAND += "function; ... " + If you need to pass the SDK path to a command within a function, you can use ``${SDK_DIR}``, which points to the parent directory used by the OpenEmbedded build system when creating SDK output. See the :term:`SDK_DIR` variable for more information. - + PR The revision of the recipe. The default value for this variable is "r0". Subsequent revisions of the recipe conventionally have the values "r1", "r2", and so forth. When :term:`PV` increases, ``PR`` is conventionally reset to "r0". - + .. note:: - + The OpenEmbedded build system does not need the aid of PR to know when to rebuild a recipe. The build system uses the task @@ -5114,7 +5718,7 @@ system and gives an overview of their function and contents. and shared state cache mechanisms. - + The ``PR`` variable primarily becomes significant when a package manager dynamically installs packages on an already built image. In this case, ``PR``, which is the default value of @@ -5124,37 +5728,45 @@ system and gives an overview of their function and contents. the same ``PV`` usually means that the packages all install the same upstream version, but with later (``PR``) version packages including packaging fixes. - + .. note:: - + PR does not need to be increased for changes that do not change the package contents or metadata. - + Because manually managing ``PR`` can be cumbersome and error-prone, - an automated solution exists. See the "`Working With a PR - Service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__" section + an automated solution exists. See the + ":ref:`dev-manual/dev-manual-common-tasks:working with a pr service`" section in the Yocto Project Development Tasks Manual for more information. - + PREFERRED_PROVIDER If multiple recipes provide the same item, this variable determines which recipe is preferred and thus provides the item (i.e. the preferred provider). You should always suffix this variable with the name of the provided item. And, you should define the variable using the preferred recipe's name (:term:`PN`). Here is a common - example: PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" In the - previous example, multiple recipes are providing "virtual/kernel". + example: + :: + + PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" + + In the previous example, multiple recipes are providing "virtual/kernel". The ``PREFERRED_PROVIDER`` variable is set with the name (``PN``) of the recipe you prefer to provide "virtual/kernel". - - Following are more examples: PREFERRED_PROVIDER_virtual/xserver = - "xserver-xf86" PREFERRED_PROVIDER_virtual/libgl ?= "mesa" For more - information, see the "`Using Virtual - Providers <&YOCTO_DOCS_DEV_URL;#metadata-virtual-providers>`__" + + Following are more examples: + :: + + PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86" + PREFERRED_PROVIDER_virtual/libgl ?= "mesa" + + For more + information, see the ":ref:`metadata-virtual-providers`" section in the Yocto Project Development Tasks Manual. - + .. note:: - + If you use a virtual/\* item with @@ -5166,56 +5778,69 @@ system and gives an overview of their function and contents. is prevented from building, which is usually desirable since this mechanism is designed to select between mutually exclusive alternative providers. - + PREFERRED_VERSION If multiple versions of recipes exist, this variable determines which version is given preference. You must always suffix the variable with the :term:`PN` you want to select, and you should set the :term:`PV` accordingly for precedence. - + The ``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 = "3.4.0" - PREFERRED_VERSION_linux-yocto = "5.0%" - + two examples: + :: + + PREFERRED_VERSION_python = "3.4.0" + PREFERRED_VERSION_linux-yocto = "5.0%" + .. note:: - - The use of the " - % - " character is limited in that it only works at the end of the + + 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. - + The specified version is matched against :term:`PV`, which does not necessarily match the version part of the recipe's filename. For example, consider two recipes ``foo_1.2.bb`` and ``foo_git.bb`` - where ``foo_git.bb`` contains the following assignment: PV = - "1.1+git${SRCPV}" In this case, the correct way to select + where ``foo_git.bb`` contains the following assignment: + :: + + PV = "1.1+git${SRCPV}" + + In this case, the correct way to select ``foo_git.bb`` is by using an assignment such as the following: - PREFERRED_VERSION_foo = "1.1+git%" Compare that previous example + :: + + PREFERRED_VERSION_foo = "1.1+git%" + + Compare that previous example against the following incorrect example, which does not work: - PREFERRED_VERSION_foo = "git" - + :: + + PREFERRED_VERSION_foo = "git" + Sometimes the ``PREFERRED_VERSION`` variable can be set by configuration files in a way that is hard to change. You can use :term:`OVERRIDES` to set a machine-specific - override. Here is an example: PREFERRED_VERSION_linux-yocto_qemux86 = - "5.0%" Although not recommended, worst case, you can also use the + override. Here is an example: + :: + + PREFERRED_VERSION_linux-yocto_qemux86 = "5.0%" + + Although not recommended, worst case, you can also use the "forcevariable" override, which is the strongest override possible. - Here is an example: PREFERRED_VERSION_linux-yocto_forcevariable = - "5.0%" - + Here is an example: + :: + + PREFERRED_VERSION_linux-yocto_forcevariable = "5.0%" + .. note:: - - The - \_forcevariable - override is not handled specially. This override only works - because the default value of - OVERRIDES - includes "forcevariable". - + + The \_forcevariable override is not handled specially. This override + only works because the default value of OVERRIDES includes "forcevariable". + PREMIRRORS Specifies additional paths from which the OpenEmbedded build system gets source code. When the build system searches for source code, it @@ -5223,35 +5848,40 @@ system and gives an overview of their function and contents. build system tries locations defined by ``PREMIRRORS``, the upstream source, and then locations specified by :term:`MIRRORS` in that order. - + Assuming your distribution (:term:`DISTRO`) is "poky", the default value for ``PREMIRRORS`` is defined in the ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository. - + Typically, you could add a specific server for the build system to attempt before any others by adding something like the following to the ``local.conf`` configuration file in the - :term:`Build Directory`: PREMIRRORS_prepend = "\\ - git://.*/.\* http://www.yoctoproject.org/sources/ \\n \\ ftp://.*/.\* - http://www.yoctoproject.org/sources/ \\n \\ http://.*/.\* - http://www.yoctoproject.org/sources/ \\n \\ https://.*/.\* - http://www.yoctoproject.org/sources/ \\n" These changes cause the + :term:`Build Directory`: + :: + + PREMIRRORS_prepend = "\ + git://.*/.* http://www.yoctoproject.org/sources/ \n \ + ftp://.*/.* http://www.yoctoproject.org/sources/ \n \ + http://.*/.* http://www.yoctoproject.org/sources/ \n \ + https://.*/.* http://www.yoctoproject.org/sources/ \n" + + 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. - + PRIORITY Indicates the importance of a package. - + ``PRIORITY`` is considered to be part of the distribution policy because the importance of any given recipe depends on the purpose for which the distribution is being produced. Thus, ``PRIORITY`` is not normally set within recipes. - + You can set ``PRIORITY`` to "required", "standard", "extra", and "optional", which is the default. - + PRIVATE_LIBS Specifies libraries installed within a recipe that should be ignored by the OpenEmbedded build system's shared library resolver. This @@ -5261,16 +5891,23 @@ system and gives an overview of their function and contents. private libraries to be set as a dependency on other unrelated packages that should instead depend on the package providing the standard version of the library. - + Libraries specified in this variable should be specified by their file name. For example, from the Firefox recipe in meta-browser: - PRIVATE_LIBS = "libmozjs.so \\ libxpcom.so \\ libnspr4.so \\ - libxul.so \\ libmozalloc.so \\ libplc4.so \\ libplds4.so" - - For more information, see the "`Automatically Added Runtime - Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__" + :: + + PRIVATE_LIBS = "libmozjs.so \ + libxpcom.so \ + libnspr4.so \ + libxul.so \ + libmozalloc.so \ + libplc4.so \ + libplds4.so" + + For more information, see the + ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`" section in the Yocto Project Overview and Concepts Manual. - + PROVIDES A list of aliases by which a particular recipe can be known. By default, a recipe's own ``PN`` is implicitly already in its @@ -5279,13 +5916,18 @@ system and gives an overview of their function and contents. aliases are synonyms for the recipe and can be useful for satisfying dependencies of other recipes during the build as specified by ``DEPENDS``. - + Consider the following example ``PROVIDES`` statement from the recipe - file ``eudev_3.2.9.bb``: PROVIDES = "udev" The ``PROVIDES`` statement + file ``eudev_3.2.9.bb``: + :: + + PROVIDES = "udev" + + The ``PROVIDES`` statement results in the "eudev" recipe also being available as simply "udev". - + .. note:: - + Given that a recipe's own recipe name is already implicitly in its own PROVIDES @@ -5293,12 +5935,12 @@ system and gives an overview of their function and contents. using a simple assignment will be sufficient. In other words, while you could write: :: - + PROVIDES += "udev" - - + + in the above, the "+=" is overkill and unnecessary. - + In addition to providing recipes under alternate names, the ``PROVIDES`` mechanism is also used to implement virtual targets. A virtual target is a name that corresponds to some particular @@ -5306,48 +5948,52 @@ system and gives an overview of their function and contents. functionality in question list the virtual target in ``PROVIDES``. Recipes that depend on the functionality in question can include the virtual target in ``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. - + The :term:`PREFERRED_PROVIDER` variable is used to select which particular recipe provides a virtual target. - + .. note:: - + A corresponding mechanism for virtual runtime dependencies (packages) exists. However, the mechanism does not depend on any special functionality beyond ordinary variable assignments. For example, ``VIRTUAL-RUNTIME_dev_manager`` refers to the package of the component that manages the ``/dev`` directory. - + Setting the "preferred provider" for runtime dependencies is as simple as using the following assignment in a configuration file: - :: - + VIRTUAL-RUNTIME_dev_manager = "udev" - - + + PRSERV_HOST The network based :term:`PR` service host and port. - + The ``conf/local.conf.sample.extended`` configuration file in the :term:`Source Directory` shows how the - ``PRSERV_HOST`` variable is set: PRSERV_HOST = "localhost:0" You must - set the variable if you want to automatically start a local `PR - service <&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service>`__. You can + ``PRSERV_HOST`` variable is set: + :: + + PRSERV_HOST = "localhost:0" + + You must + set the variable if you want to automatically start a local :ref:`PR + service `. You can set ``PRSERV_HOST`` to other values to use a remote PR service. - + PTEST_ENABLED - Specifies whether or not `Package - Test <&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest>`__ (ptest) + Specifies whether or not :ref:`Package + Test ` (ptest) functionality is enabled when building a recipe. You should not set this variable directly. Enabling and disabling building Package Tests at build time should be done by adding "ptest" to (or removing it from) :term:`DISTRO_FEATURES`. - + PV The version of the recipe. The version is normally extracted from the recipe filename. For example, if the recipe is named @@ -5355,9 +6001,9 @@ system and gives an overview of their function and contents. ``PV`` is generally not overridden within a recipe unless it is building an unstable (i.e. development) version from a source code repository (e.g. Git or Subversion). - + ``PV`` is the default value of the :term:`PKGV` variable. - + PYTHON_ABI When used by recipes that inherit the :ref:`distutils3 `, @@ -5367,15 +6013,15 @@ system and gives an overview of their function and contents. Application Binary Interface (ABI) currently in use for Python. By default, the ABI is "m". You do not have to set this variable as the OpenEmbedded build system sets it for you. - + The OpenEmbedded build system uses the ABI to construct directory names used when installing the Python headers and libraries in sysroot (e.g. ``.../python3.3m/...``). - + Recipes that inherit the ``distutils`` class during cross-builds also use this variable to locate the headers and libraries of the appropriate Python that the extension is targeting. - + PYTHON_PN When used by recipes that inherit the `distutils3 `, @@ -5385,43 +6031,62 @@ system and gives an overview of their function and contents. major Python version being built. For Python 3.x, ``PYTHON_PN`` would be "python3". You do not have to set this variable as the OpenEmbedded build system automatically sets it for you. - + The variable allows recipes to use common infrastructure such as the - following: DEPENDS += "${PYTHON_PN}-native" In the previous example, + following: + :: + + DEPENDS += "${PYTHON_PN}-native" + + In the previous example, the version of the dependency is ``PYTHON_PN``. - + RANLIB The minimal command and arguments to run ``ranlib``. - + RCONFLICTS The list of packages that conflict with packages. Note that packages will not be installed if conflicting packages are not first removed. - + Like all package-controlling variables, you must always use them in conjunction with a package name override. Here is an example: - RCONFLICTS_${PN} = "another_conflicting_package_name" - + :: + + RCONFLICTS_${PN} = "another_conflicting_package_name" + BitBake, which the OpenEmbedded build system uses, 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 - ``RCONFLICTS`` variable: RCONFLICTS_${PN} = "package (operator - version)" For ``operator``, you can specify the following: = < > <= + ``RCONFLICTS`` variable: + :: + + RCONFLICTS_${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``: RCONFLICTS_${PN} = "foo (>= 1.2)" - + greater of the package ``foo``: + :: + + RCONFLICTS_${PN} = "foo (>= 1.2)" + RDEPENDS Lists runtime dependencies of a package. These dependencies are other packages that must be installed in order for the package to function correctly. As an example, the following assignment declares that the package ``foo`` needs the packages ``bar`` and ``baz`` to be - installed: RDEPENDS_foo = "bar baz" The most common types of package + installed: + :: + + RDEPENDS_foo = "bar baz" + + The most common types of package runtime dependencies are automatically detected and added. Therefore, most recipes do not need to set ``RDEPENDS``. For more information, - see the "`Automatically Added Runtime - Dependencies <&YOCTO_DOCS_OM_URL;#automatically-added-runtime-dependencies>`__" + see the + ":ref:`overview-manual/overview-manual-concepts:automatically added runtime dependencies`" section in the Yocto Project Overview and Concepts Manual. - + The practical effect of the above ``RDEPENDS`` assignment is that ``bar`` and ``baz`` will be declared as dependencies inside the package ``foo`` when it is written out by one of the @@ -5431,7 +6096,7 @@ system and gives an overview of their function and contents. :term:`PACKAGE_CLASSES`. When the corresponding package manager installs the package, it will know to also install the packages on which it depends. - + To ensure that the packages ``bar`` and ``baz`` get built, the previous ``RDEPENDS`` assignment also causes a task dependency to be added. This dependency is from the recipe's @@ -5439,26 +6104,31 @@ system and gives an overview of their function and contents. :ref:`ref-tasks-compile`) task to the ``do_package_write_*`` task of the recipes that build ``bar`` and ``baz``. - + The names of the packages you list within ``RDEPENDS`` must be the names of other packages - they cannot be recipe names. Although package names and recipe names usually match, the important point here is that you are providing package names within the ``RDEPENDS`` variable. For an example of the default list of packages created from a recipe, see the :term:`PACKAGES` variable. - + Because the ``RDEPENDS`` variable applies to packages being built, you should always use the variable in a form with an attached package name (remember that a single recipe can build multiple packages). For example, suppose you are building a development package that depends on the ``perl`` package. In this case, you would use the following - ``RDEPENDS`` statement: RDEPENDS_${PN}-dev += "perl" In the example, + ``RDEPENDS`` statement: + :: + + RDEPENDS_${PN}-dev += "perl" + + In the example, the development package depends on the ``perl`` package. Thus, the ``RDEPENDS`` variable has the ``${PN}-dev`` package name as part of the variable. - + .. note:: - + RDEPENDS_${PN}-dev includes ${ @@ -5472,7 +6142,7 @@ system and gives an overview of their function and contents. when modifying RDEPENDS_${PN}-dev . Use the "+=" operator rather than the "=" operator. - + The package names you use with ``RDEPENDS`` must appear as they would in the ``PACKAGES`` variable. The :term:`PKG` variable allows a different name to be used for the final package (e.g. the @@ -5480,31 +6150,38 @@ system and gives an overview of their function and contents. packages), but this final package name cannot be used with ``RDEPENDS``, which makes sense as ``RDEPENDS`` is meant to be independent of the package format used. - + BitBake, which the OpenEmbedded build system uses, 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 - ``RDEPENDS`` variable: RDEPENDS_${PN} = "package (operator version)" + ``RDEPENDS`` variable: + :: + + RDEPENDS_${PN} = "package (operator version)" + For operator, you can specify the following: = < > <= >= For version, provide the version number. - + .. note:: - + You can use EXTENDPKGV to provide a full package version specification. - + For example, the following sets up a dependency on version 1.2 or - greater of the package ``foo``: RDEPENDS_${PN} = "foo (>= 1.2)" - + greater of the package ``foo``: + :: + + RDEPENDS_${PN} = "foo (>= 1.2)" + For information on build-time dependencies, see the :term:`DEPENDS` variable. You can also see the ":ref:`Tasks `" and ":ref:`Dependencies `" sections in the BitBake User Manual for additional information on tasks and dependencies. - + REQUIRED_DISTRO_FEATURES When inheriting the :ref:`distro_features_check ` @@ -5514,115 +6191,136 @@ system and gives an overview of their function and contents. ``REQUIRED_DISTRO_FEATURES`` variable lists a feature that does not appear in ``DISTRO_FEATURES`` within the current configuration, an error occurs and the build stops. - + RM_WORK_EXCLUDE With ``rm_work`` enabled, this variable specifies a list of recipes whose work directories should not be removed. See the ":ref:`rm_work.bbclass `" section for more details. - + ROOT_HOME Defines the root home directory. By default, this directory is set as - follows in the BitBake configuration file: ROOT_HOME ??= "/home/root" - + follows in the BitBake configuration file: + :: + + ROOT_HOME ??= "/home/root" + .. note:: - + This default value is likely used because some embedded solutions prefer to have a read-only root filesystem and prefer to keep writeable data in one place. - + You can override the default by setting the variable in any layer or in the ``local.conf`` file. Because the default is set using a "weak" assignment (i.e. "??="), you can use either of the following forms to - define your override: ROOT_HOME = "/root" ROOT_HOME ?= "/root" These + define your override: + :: + + ROOT_HOME = "/root" + ROOT_HOME ?= "/root" + + These override examples use ``/root``, which is probably the most commonly used override. - + ROOTFS Indicates a filesystem image to include as the root filesystem. - + The ``ROOTFS`` variable is an optional variable used with the :ref:`image-live ` class. - + ROOTFS_POSTINSTALL_COMMAND Specifies a list of functions to call after the OpenEmbedded build system has installed packages. You can specify functions separated by - semicolons: ROOTFS_POSTINSTALL_COMMAND += "function; ... " - + semicolons: + :: + + ROOTFS_POSTINSTALL_COMMAND += "function; ... " + If you need to pass the root filesystem path to a command within a function, you can use ``${IMAGE_ROOTFS}``, which points to the directory that becomes the root filesystem image. See the :term:`IMAGE_ROOTFS` variable for more information. - + ROOTFS_POSTPROCESS_COMMAND Specifies a list of functions to call once the OpenEmbedded build system has created the root filesystem. You can specify functions - separated by semicolons: ROOTFS_POSTPROCESS_COMMAND += "function; ... - " - + separated by semicolons: + :: + + ROOTFS_POSTPROCESS_COMMAND += "function; ... " + If you need to pass the root filesystem path to a command within a function, you can use ``${IMAGE_ROOTFS}``, which points to the directory that becomes the root filesystem image. See the :term:`IMAGE_ROOTFS` variable for more information. - + ROOTFS_POSTUNINSTALL_COMMAND Specifies a list of functions to call after the OpenEmbedded build system has removed unnecessary packages. When runtime package management is disabled in the image, several packages are removed including ``base-passwd``, ``shadow``, and ``update-alternatives``. You can specify functions separated by semicolons: - ROOTFS_POSTUNINSTALL_COMMAND += "function; ... " - + :: + + ROOTFS_POSTUNINSTALL_COMMAND += "function; ... " + If you need to pass the root filesystem path to a command within a function, you can use ``${IMAGE_ROOTFS}``, which points to the directory that becomes the root filesystem image. See the :term:`IMAGE_ROOTFS` variable for more information. - + ROOTFS_PREPROCESS_COMMAND Specifies a list of functions to call before the OpenEmbedded build system has created the root filesystem. You can specify functions - separated by semicolons: ROOTFS_PREPROCESS_COMMAND += "function; ... - " - + separated by semicolons: + :: + + ROOTFS_PREPROCESS_COMMAND += "function; ... " + If you need to pass the root filesystem path to a command within a function, you can use ``${IMAGE_ROOTFS}``, which points to the directory that becomes the root filesystem image. See the :term:`IMAGE_ROOTFS` variable for more information. - + 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 ``RDEPENDS``). - + .. note:: - + A package's own name is implicitly already in its RPROVIDES list. - + 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" - + example: + :: + + RPROVIDES_${PN} = "widget-abi-2" + 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 rather uses them for extended usability. To specify runtime dependencies for packages, see the ``RDEPENDS`` variable. - + The package manager will automatically install the ``RRECOMMENDS`` list of packages when installing the built package. However, you can prevent listed packages from being installed by using the :term:`BAD_RECOMMENDATIONS`, :term:`NO_RECOMMENDATIONS`, and :term:`PACKAGE_EXCLUDE` variables. - + Packages specified in ``RRECOMMENDS`` need not actually be produced. However, a recipe must exist that provides each package, either through the :term:`PACKAGES` or @@ -5630,55 +6328,93 @@ system and gives an overview of their function and contents. :term:`RPROVIDES` variable, or an error will occur during the build. If such a recipe does exist and the package is not produced, the build continues without error. - + Because the ``RRECOMMENDS`` variable applies to packages being built, you should always attach an override to the variable to specify the particular package whose usability is being extended. For example, suppose you are building a development package that is extended to support wireless functionality. In this case, you would use the - following: RRECOMMENDS_${PN}-dev += "wireless_package_name" In the + following: + :: + + RRECOMMENDS_${PN}-dev += "wireless_package_name" + + In the example, the package name (``${PN}-dev``) must appear as it would in the ``PACKAGES`` namespace before any renaming of the output package by classes such as ``debian.bbclass``. - + BitBake, which the OpenEmbedded build system uses, 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 - ``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)" - + ``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)" + RREPLACES A list of packages replaced by a package. The package manager uses this variable to determine which package should be installed to replace other package(s) during an upgrade. In order to also have the other package(s) removed at the same time, you must add the name of the other package to the ``RCONFLICTS`` variable. - + As with all package-controlling variables, you must use this variable in conjunction with a package name override. Here is an example: - RREPLACES_${PN} = "other_package_being_replaced" - + :: + + RREPLACES_${PN} = "other_package_being_replaced" + BitBake, which the OpenEmbedded build system uses, supports specifying versioned replacements. 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 - ``RREPLACES`` variable: RREPLACES_${PN} = "package (operator - version)" For ``operator``, you can specify the following: = < > <= - >= For example, the following sets up a replacement using version 1.2 - or greater of the package ``foo``: RREPLACES_${PN} = "foo (>= 1.2)" - + ``RREPLACES`` variable: + :: + + RREPLACES_${PN} = "package (operator version)" + + For ``operator``, you can specify the following: + + - = + - < + - > + - <= + - >= + + For example, the following sets up a replacement using version 1.2 + or greater of the package ``foo``: + :: + + RREPLACES_${PN} = "foo (>= 1.2)" + RSUGGESTS A list of additional packages that you can suggest for installation by the package manager at the time a package is installed. Not all package managers support this functionality. - + As with all package-controlling variables, you must always use this variable in conjunction with a package name override. Here is an - example: RSUGGESTS_${PN} = "useful_package another_package" - + example: + :: + + RSUGGESTS_${PN} = "useful_package another_package" + S The location in the :term:`Build Directory` where unpacked recipe source code resides. By default, this directory is @@ -5689,27 +6425,33 @@ system and gives an overview of their function and contents. fetched from an SCM such as Git or Subversion, then you must set ``S`` in the recipe so that the OpenEmbedded build system knows where to find the unpacked source. - + As an example, assume a :term:`Source Directory` top-level folder named ``poky`` and a default Build Directory at ``poky/build``. In this case, the work directory the build system uses to keep the unpacked recipe for ``db`` is the following: - poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19 The - unpacked source code resides in the ``db-5.1.19`` folder. - + :: + + poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19 + + The unpacked source code resides in the ``db-5.1.19`` folder. + This next example assumes a Git repository. By default, Git repositories are cloned to ``${WORKDIR}/git`` during :ref:`ref-tasks-fetch`. Since this path is different from the default value of ``S``, you must set it specifically so the - source can be located: SRC_URI = "git://path/to/repo.git" S = - "${WORKDIR}/git" - + source can be located: + :: + + SRC_URI = "git://path/to/repo.git" + S = "${WORKDIR}/git" + SANITY_REQUIRED_UTILITIES Specifies a list of command-line utilities that should be checked for during the initial sanity checking process when running BitBake. If any of the utilities are not installed on the build host, then BitBake immediately exits with an error. - + SANITY_TESTED_DISTROS A list of the host distribution identifiers that the build system has been tested against. Identifiers consist of the host distributor ID @@ -5720,25 +6462,31 @@ system and gives an overview of their function and contents. :term:`NATIVELSBSTRING` does not appear in the list, then the build system reports a warning that indicates the current host distribution has not been tested as a build host. - + SDK_ARCH The target architecture for the SDK. Typically, you do not directly set this variable. Instead, use :term:`SDKMACHINE`. - + SDK_DEPLOY The directory set up and used by the :ref:`populate_sdk_base ` class to which the SDK is deployed. The ``populate_sdk_base`` class defines - ``SDK_DEPLOY`` as follows: SDK_DEPLOY = "${TMPDIR}/deploy/sdk" - + ``SDK_DEPLOY`` as follows: + :: + + SDK_DEPLOY = "${TMPDIR}/deploy/sdk" + SDK_DIR The parent directory used by the OpenEmbedded build system when creating SDK output. The :ref:`populate_sdk_base ` class defines - the variable as follows: SDK_DIR = "${WORKDIR}/sdk" - + the variable as follows: + :: + + SDK_DIR = "${WORKDIR}/sdk" + .. note:: - + The SDK_DIR directory is a temporary directory as it is part of @@ -5746,47 +6494,53 @@ system and gives an overview of their function and contents. . The final output directory is SDK_DEPLOY . - + SDK_EXT_TYPE Controls whether or not shared state artifacts are copied into the extensible SDK. The default value of "full" copies all of the required shared state artifacts into the extensible SDK. The value "minimal" leaves these artifacts out of the SDK. - + .. note:: - + If you set the variable to "minimal", you need to ensure SSTATE_MIRRORS is set in the SDK's configuration to enable the artifacts to be fetched as needed. - + SDK_HOST_MANIFEST The manifest file for the host part of the SDK. This file lists all the installed packages that make up the host part of the SDK. The file contains package information on a line-per-package basis as - follows: packagename packagearch version - + follows: + :: + + packagename packagearch version + The :ref:`populate_sdk_base ` class - defines the manifest file as follows: SDK_HOST_MANIFEST = - "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" The location is - derived using the :term:`SDK_DEPLOY` and + defines the manifest file as follows: + :: + + SDK_HOST_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest" + + The location is derived using the :term:`SDK_DEPLOY` and :term:`TOOLCHAIN_OUTPUTNAME` variables. - + SDK_INCLUDE_PKGDATA When set to "1", specifies to include the packagedata for all recipes in the "world" target in the extensible SDK. Including this data allows the ``devtool search`` command to find these recipes in search results, as well as allows the ``devtool add`` command to map dependencies more effectively. - + .. note:: - + Enabling the SDK_INCLUDE_PKGDATA variable significantly increases build time because all of world needs to be built. Enabling the variable also slightly increases the size of the extensible SDK. - + SDK_INCLUDE_TOOLCHAIN When set to "1", specifies to include the toolchain in the extensible SDK. Including the toolchain is useful particularly when @@ -5795,375 +6549,417 @@ system and gives an overview of their function and contents. toolchain. For example, suppose you want to use the toolchain from an IDE or from other tools and you do not want to perform additional steps to install the toolchain. - + The ``SDK_INCLUDE_TOOLCHAIN`` variable defaults to "0" if ``SDK_EXT_TYPE`` is set to "minimal", and defaults to "1" if ``SDK_EXT_TYPE`` is set to "full". - + SDK_INHERIT_BLACKLIST A list of classes to remove from the :term:`INHERIT` value globally within the extensible SDK configuration. The :ref:`populate-sdk-ext ` class sets the - default value: SDK_INHERIT_BLACKLIST ?= "buildhistory icecc" - + default value: + :: + + SDK_INHERIT_BLACKLIST ?= "buildhistory icecc" + Some classes are not generally applicable within the extensible SDK context. You can use this variable to disable those classes. - + For additional information on how to customize the extensible SDK's - configuration, see the "`Configuring the Extensible - SDK <&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk>`__" + configuration, see the + ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. - + SDK_LOCAL_CONF_BLACKLIST A list of variables not allowed through from the OpenEmbedded build system configuration into the extensible SDK configuration. Usually, these are variables that are specific to the machine on which the build system is running and thus would be potentially problematic within the extensible SDK. - + By default, ``SDK_LOCAL_CONF_BLACKLIST`` is set in the :ref:`populate-sdk-ext ` class and excludes the following variables: - :term:`CONF_VERSION` - :term:`BB_NUMBER_THREADS` - :term:`bitbake:BB_NUMBER_PARSE_THREADS` - :term:`PARALLEL_MAKE` - :term:`PRSERV_HOST` - :term:`SSTATE_MIRRORS` :term:`DL_DIR` - :term:`SSTATE_DIR` :term:`TMPDIR` - :term:`BB_SERVER_TIMEOUT` - + + - :term:`CONF_VERSION` + - :term:`BB_NUMBER_THREADS` + - :term:`bitbake:BB_NUMBER_PARSE_THREADS` + - :term:`PARALLEL_MAKE` + - :term:`PRSERV_HOST` + - :term:`SSTATE_MIRRORS` :term:`DL_DIR` + - :term:`SSTATE_DIR` :term:`TMPDIR` + - :term:`BB_SERVER_TIMEOUT` + For additional information on how to customize the extensible SDK's - configuration, see the "`Configuring the Extensible - SDK <&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk>`__" + configuration, see the + ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. - + SDK_LOCAL_CONF_WHITELIST A list of variables allowed through from the OpenEmbedded build system configuration into the extensible SDK configuration. By default, the list of variables is empty and is set in the :ref:`populate-sdk-ext ` class. - + This list overrides the variables specified using the :term:`SDK_LOCAL_CONF_BLACKLIST` variable as well as any variables identified by automatic blacklisting due to the "/" character being found at the start of the value, which is usually indicative of being a path and thus might not be valid on the system where the SDK is installed. - + For additional information on how to customize the extensible SDK's - configuration, see the "`Configuring the Extensible - SDK <&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk>`__" + configuration, see the + ":ref:`sdk-manual/sdk-appendix-customizing:configuring the extensible sdk`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. - + SDK_NAME The base name for SDK output files. The name is derived from the :term:`DISTRO`, :term:`TCLIBC`, :term:`SDK_ARCH`, :term:`IMAGE_BASENAME`, and - :term:`TUNE_PKGARCH` variables: SDK_NAME = - "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}" - + :term:`TUNE_PKGARCH` variables: + :: + + SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${IMAGE_BASENAME}-${TUNE_PKGARCH}" + SDK_OS Specifies the operating system for which the SDK will be built. The default value is the value of :term:`BUILD_OS`. - + SDK_OUTPUT The location used by the OpenEmbedded build system when creating SDK output. The :ref:`populate_sdk_base ` - class defines the variable as follows: SDK_DIR = "${WORKDIR}/sdk" - SDK_OUTPUT = "${SDK_DIR}/image" SDK_DEPLOY = "${DEPLOY_DIR}/sdk" - + class defines the variable as follows: + :: + + SDK_DIR = "${WORKDIR}/sdk" + SDK_OUTPUT = "${SDK_DIR}/image" + SDK_DEPLOY = "${DEPLOY_DIR}/sdk" + .. note:: - - The - SDK_OUTPUT - directory is a temporary directory as it is part of - WORKDIR - by way of - SDK_DIR - . The final output directory is - SDK_DEPLOY - . - + + The SDK_OUTPUT directory is a temporary directory as it is part of + WORKDIR by way of SDK_DIR. The final output directory is + SDK_DEPLOY. + SDK_PACKAGE_ARCHS Specifies a list of architectures compatible with the SDK machine. This variable is set automatically and should not normally be hand-edited. Entries are separated using spaces and listed in order of priority. The default value for ``SDK_PACKAGE_ARCHS`` is "all any noarch ${SDK_ARCH}-${SDKPKGSUFFIX}". - + SDK_POSTPROCESS_COMMAND Specifies a list of functions to call once the OpenEmbedded build system creates the SDK. You can specify functions separated by semicolons: SDK_POSTPROCESS_COMMAND += "function; ... " - + If you need to pass an SDK path to a command within a function, you can use ``${SDK_DIR}``, which points to the parent directory used by the OpenEmbedded build system when creating SDK output. See the :term:`SDK_DIR` variable for more information. - + SDK_PREFIX The toolchain binary prefix used for ``nativesdk`` recipes. The OpenEmbedded build system uses the ``SDK_PREFIX`` value to set the :term:`TARGET_PREFIX` when building ``nativesdk`` recipes. The default value is "${SDK_SYS}-". - + SDK_RECRDEP_TASKS A list of shared state tasks added to the extensible SDK. By default, - the following tasks are added: do_populate_lic do_package_qa - do_populate_sysroot do_deploy Despite the default value of "" for the + the following tasks are added: + + - do_populate_lic + - do_package_qa + - do_populate_sysroot + - do_deploy + + Despite the default value of "" for the ``SDK_RECRDEP_TASKS`` variable, the above four tasks are always added to the SDK. To specify tasks beyond these four, you need to use the ``SDK_RECRDEP_TASKS`` variable (e.g. you are defining additional tasks that are needed in order to build :term:`SDK_TARGETS`). - + SDK_SYS Specifies the system, including the architecture and the operating system, for which the SDK will be built. - + The OpenEmbedded build system automatically sets this variable based on :term:`SDK_ARCH`, :term:`SDK_VENDOR`, and :term:`SDK_OS`. You do not need to set the ``SDK_SYS`` variable yourself. - + SDK_TARGET_MANIFEST The manifest file for the target part of the SDK. This file lists all the installed packages that make up the target part of the SDK. The file contains package information on a line-per-package basis as - follows: packagename packagearch version - + follows: + :: + + packagename packagearch version + The :ref:`populate_sdk_base ` class - defines the manifest file as follows: SDK_TARGET_MANIFEST = - "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" The location - is derived using the :term:`SDK_DEPLOY` and + defines the manifest file as follows: + :: + + SDK_TARGET_MANIFEST = "${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.target.manifest" + + The location is derived using the :term:`SDK_DEPLOY` and :term:`TOOLCHAIN_OUTPUTNAME` variables. - + SDK_TARGETS A list of targets to install from shared state as part of the standard or extensible SDK installation. The default value is "${PN}" (i.e. the image from which the SDK is built). - + The ``SDK_TARGETS`` variable is an internal variable and typically would not be changed. - + SDK_TITLE The title to be printed when running the SDK installer. By default, this title is based on the :term:`DISTRO_NAME` or :term:`DISTRO` variable and is set in the :ref:`populate_sdk_base ` class as - follows: SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or - d.getVar('DISTRO')} SDK" For the default distribution "poky", + follows: + :: + + SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK" + + For the default distribution "poky", ``SDK_TITLE`` is set to "Poky (Yocto Project Reference Distro)". - + For information on how to change this default title, see the - "`Changing the Extensible SDK Installer - Title <&YOCTO_DOCS_SDK_URL;#sdk-changing-the-sdk-installer-title>`__" + ":ref:`sdk-manual/sdk-appendix-customizing:changing the extensible sdk installer title`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. - + SDK_UPDATE_URL An optional URL for an update server for the extensible SDK. If set, the value is used as the default update server when running ``devtool sdk-update`` within the extensible SDK. - + SDK_VENDOR Specifies the name of the SDK vendor. - + SDK_VERSION Specifies the version of the SDK. The distribution configuration file (e.g. ``/meta-poky/conf/distro/poky.conf``) defines the - ``SDK_VERSION`` as follows: SDK_VERSION = - "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}" - + ``SDK_VERSION`` as follows: + :: + + SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}','snapshot')}" + For additional information, see the :term:`DISTRO_VERSION` and :term:`DATE` variables. - + SDKEXTPATH The default installation directory for the Extensible SDK. By default, this directory is based on the :term:`DISTRO` variable and is set in the :ref:`populate_sdk_base ` class as - follows: SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" For the + follows: + :: + + SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk" + + For the default distribution "poky", the ``SDKEXTPATH`` is set to "poky_sdk". - + For information on how to change this default directory, see the - "`Changing the Default SDK Installation - Directory <&YOCTO_DOCS_SDK_URL;#sdk-changing-the-default-sdk-installation-directory>`__" + ":ref:`sdk-manual/sdk-appendix-customizing:changing the default sdk installation directory`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual. - + SDKIMAGE_FEATURES Equivalent to ``IMAGE_FEATURES``. However, this variable applies to - the SDK generated from an image using the following command: $ - bitbake -c populate_sdk imagename - + the SDK generated from an image using the following command: + :: + + $ bitbake -c populate_sdk imagename + SDKMACHINE The machine for which the SDK is built. In other words, the SDK is built such that it runs on the target you specify with the ``SDKMACHINE`` value. The value points to a corresponding ``.conf`` file under ``conf/machine-sdk/``. - + You can use "i686" and "x86_64" as possible values for this variable. The variable defaults to "i686" and is set in the local.conf file in - the Build Directory. SDKMACHINE ?= "i686" - + the Build Directory. + :: + + SDKMACHINE ?= "i686" + .. note:: - + You cannot set the SDKMACHINE variable in your distribution configuration file. If you do, the configuration will not take affect. - + SDKPATH Defines the path offered to the user for installation of the SDK that is generated by the OpenEmbedded build system. The path appears as the default location for installing the SDK when you run the SDK's installation script. You can override the offered path when you run the script. - + SDKTARGETSYSROOT The full path to the sysroot used for cross-compilation within an SDK as it will be when installed into the default :term:`SDKPATH`. - + SECTION The section in which packages should be categorized. Package management utilities can make use of this variable. - + SELECTED_OPTIMIZATION Specifies the optimization flags passed to the C compiler when building for the target. The flags are passed through the default value of the :term:`TARGET_CFLAGS` variable. - + The ``SELECTED_OPTIMIZATION`` variable takes the value of ``FULL_OPTIMIZATION`` unless ``DEBUG_BUILD`` = "1". If that is the case, the value of ``DEBUG_OPTIMIZATION`` is used. - + SERIAL_CONSOLE Defines a serial console (TTY) to enable using `getty `__. Provide a value that specifies the baud rate followed by the TTY device name separated by a space. You cannot specify more than one TTY device: - SERIAL_CONSOLE = "115200 ttyS0" - + :: + + SERIAL_CONSOLE = "115200 ttyS0" + .. note:: - + The SERIAL_CONSOLE variable is deprecated. Please use the SERIAL_CONSOLES variable. - + SERIAL_CONSOLES Defines a serial console (TTY) to enable using `getty `__. Provide a value that specifies the baud rate followed by the TTY device name separated by a semicolon. Use spaces to separate multiple devices: - SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1" - + :: + + SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1" + SERIAL_CONSOLES_CHECK Specifies serial consoles, which must be listed in :term:`SERIAL_CONSOLES`, to check against ``/proc/console`` before enabling them using getty. This variable allows aliasing in the format: :. If a device was listed as "sclp_line0" in ``/dev/`` and "ttyS0" was listed in - ``/proc/console``, you would do the following: SERIAL_CONSOLES_CHECK - = "slcp_line0:ttyS0" This variable is currently only supported with - SysVinit (i.e. not with systemd). - + ``/proc/console``, you would do the following: :: + + SERIAL_CONSOLES_CHECK = "slcp_line0:ttyS0" + + This variable is currently only supported with SysVinit (i.e. not + with systemd). + SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS A list of recipe dependencies that should not be used to determine signatures of tasks from one recipe when they depend on tasks from - another recipe. For example: SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += - "intone->mplayer2" - + another recipe. For example: :: + + SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2" + In the previous example, ``intone`` depends on ``mplayer2``. - + You can use the special token ``"*"`` on the left-hand side of the dependency to match all recipes except the one on the right-hand - side. Here is an example: SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += - "*->quilt-native" - + side. Here is an example: :: + + SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "*->quilt-native" + In the previous example, all recipes except ``quilt-native`` ignore task signatures from the ``quilt-native`` recipe when determining their task signatures. - + Use of this variable is one mechanism to remove dependencies that affect task signatures and thus force rebuilds when a recipe changes. - + .. note:: - + If you add an inappropriate dependency for a recipe relationship, the software might break during runtime if the interface of the second recipe was changed after the first recipe had been built. - + SIGGEN_EXCLUDERECIPES_ABISAFE A list of recipes that are completely stable and will never change. The ABI for the recipes in the list are presented by output from the tasks run to build the recipe. Use of this variable is one way to remove dependencies from one recipe on another that affect task signatures and thus force rebuilds when the recipe changes. - + .. note:: - + If you add an inappropriate variable to this list, the software might break at runtime if the interface of the recipe was changed after the other had been built. - + SITEINFO_BITS Specifies the number of bits for the target system CPU. The value should be either "32" or "64". - + SITEINFO_ENDIANNESS Specifies the endian byte order of the target system. The value should be either "le" for little-endian or "be" for big-endian. - + SKIP_FILEDEPS Enables removal of all files from the "Provides" section of an RPM package. Removal of these files is required for packages containing prebuilt binaries and libraries such as ``libstdc++`` and ``glibc``. - + To enable file removal, set the variable to "1" in your - ``conf/local.conf`` configuration file in your: - :term:`Build Directory`. SKIP_FILEDEPS = "1" - + ``conf/local.conf`` configuration file in your: + :term:`Build Directory`. + :: + + SKIP_FILEDEPS = "1" + SOC_FAMILY Groups together machines based upon the same family of SOC (System On Chip). You typically set this variable in a common ``.inc`` file that you include in the configuration files of all the machines. - + .. note:: - + You must include conf/machine/include/soc-family.inc for this variable to appear in MACHINEOVERRIDES . - + SOLIBS Defines the suffix for shared libraries used on the target platform. By default, this suffix is ".so.*" for all Linux-based systems and is defined in the ``meta/conf/bitbake.conf`` configuration file. - + You will see this variable referenced in the default values of ``FILES_${PN}``. - + SOLIBSDEV Defines the suffix for the development symbolic link (symlink) for shared libraries on the target platform. By default, this suffix is ".so" for Linux-based systems and is defined in the ``meta/conf/bitbake.conf`` configuration file. - + You will see this variable referenced in the default values of ``FILES_${PN}-dev``. - + SOURCE_MIRROR_FETCH When you are fetching files to create a mirror of sources (i.e. creating a source mirror), setting ``SOURCE_MIRROR_FETCH`` to "1" in @@ -6175,69 +6971,75 @@ system and gives an overview of their function and contents. variable and :term:`COMPATIBLE_HOST` variables specify compatibility with a machine other than that of the current machine or host. - + .. note:: - + Do not set the SOURCE_MIRROR_FETCH variable unless you are creating a source mirror. In other words, do not set the variable during a normal build. - + SOURCE_MIRROR_URL Defines your own :term:`PREMIRRORS` from which to first fetch source before attempting to fetch from the upstream specified in :term:`SRC_URI`. - + To use this variable, you must globally inherit the :ref:`own-mirrors ` class and then provide - the URL to your mirrors. Here is the general syntax: INHERIT += - "own-mirrors" SOURCE_MIRROR_URL = - "http://example.com/my_source_mirror" - + the URL to your mirrors. Here is the general syntax: + :: + + INHERIT += "own-mirrors" + SOURCE_MIRROR_URL = "http://example.com/my_source_mirror" + .. note:: - + You can specify only a single URL in SOURCE_MIRROR_URL . - + SPDXLICENSEMAP Maps commonly used license names to their SPDX counterparts found in ``meta/files/common-licenses/``. For the default ``SPDXLICENSEMAP`` mappings, see the ``meta/conf/licenses.conf`` file. - + For additional information, see the :term:`LICENSE` variable. - + SPECIAL_PKGSUFFIX A list of prefixes for :term:`PN` used by the OpenEmbedded build system to create variants of recipes or packages. The list specifies the prefixes to strip off during certain circumstances such as the generation of the :term:`BPN` variable. - + SPL_BINARY The file type for the Secondary Program Loader (SPL). Some devices use an SPL from which to boot (e.g. the BeagleBone development board). For such cases, you can declare the file type of the SPL binary in the ``u-boot.inc`` include file, which is used in the U-Boot recipe. - + The SPL file type is set to "null" by default in the ``u-boot.inc`` - file as follows: # Some versions of u-boot build an SPL (Second - Program Loader) image that # should be packaged along with the u-boot - binary as well as placed in the # deploy directory. For those - versions they can set the following variables # to allow packaging - the SPL. SPL_BINARY ?= "" SPL_BINARYNAME ?= - "${@os.path.basename(d.getVar("SPL_BINARY"))}" SPL_IMAGE ?= - "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}" SPL_SYMLINK ?= - "${SPL_BINARYNAME}-${MACHINE}" The ``SPL_BINARY`` variable helps form + file as follows: + :: + + # Some versions of u-boot build an SPL (Second Program Loader) image that + # should be packaged along with the u-boot binary as well as placed in the + # deploy directory. For those versions they can set the following variables + # to allow packaging the SPL. + SPL_BINARY ?= "" + SPL_BINARYNAME ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}" + SPL_IMAGE ?= "${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}" + SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}" + + The ``SPL_BINARY`` variable helps form various ``SPL_*`` variables used by the OpenEmbedded build system. - - See the BeagleBone machine configuration example in the "`Creating a - new BSP Layer Using the ``bitbake-layers`` - Script <&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-bitbake-layers-script>`__" + + See the BeagleBone machine configuration example in the + ":ref:`dev-manual/dev-manual-common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`" section in the Yocto Project Board Support Package Developer's Guide for additional information. - + SRC_URI The list of source files - local or remote. This variable tells the OpenEmbedded build system which bits to pull in for the build and how @@ -6247,34 +7049,34 @@ system and gives an overview of their function and contents. append file needs to fetch a tarball, apply two patches, and include a custom file, the recipe or append file would include four instances of the variable. - + 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:`Fetchers `" section in the BitBake User Manual. - - - *``file://`` -* Fetches files, which are usually files shipped + + - ``file://`` - Fetches files, which are usually files shipped with the :term:`Metadata`, from the local machine (e.g. - `patch <&YOCTO_DOCS_OM_URL;#patching-dev-environment>`__ files). + :ref:`patch ` files). 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 + + - ``${BPN}`` - The base recipe name without any special suffix or version numbers. - - - *``${BP}`` -* ``${BPN}-${PV}``. The base recipe name and + + - ``${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. - + .. note:: - + If you want the build system to pick up files specified through a SRC_URI @@ -6284,127 +7086,133 @@ system and gives an overview of their function and contents. variable by also using the FILESEXTRAPATHS variable from within your append file. - - - *``bzr://`` -* Fetches files from a Bazaar revision control + + - ``bzr://`` - Fetches files from a Bazaar revision control repository. - - - *``git://`` -* Fetches files from a Git revision control + + - ``git://`` - Fetches files from a Git revision control repository. - - - *``osc://`` -* Fetches files from an OSC (OpenSUSE Build service) + + - ``osc://`` - Fetches files from an OSC (OpenSUSE Build service) revision control repository. - - - *``repo://`` -* Fetches files from a repo (Git) repository. - - - *``ccrc://`` -* Fetches files from a ClearCase repository. - - - *``http://`` -* Fetches files from the Internet using ``http``. - - - *``https://`` -* Fetches files from the Internet using ``https``. - - - *``ftp://`` -* Fetches files from the Internet using ``ftp``. - - - *``cvs://`` -* Fetches files from a CVS revision control + + - ``repo://`` - Fetches files from a repo (Git) repository. + + - ``ccrc://`` - Fetches files from a ClearCase repository. + + - ``http://`` - Fetches files from the Internet using ``http``. + + - ``https://`` - Fetches files from the Internet using ``https``. + + - ``ftp://`` - Fetches files from the Internet using ``ftp``. + + - ``cvs://`` - Fetches files from a CVS revision control repository. - - - *``hg://`` -* Fetches files from a Mercurial (``hg``) revision + + - ``hg://`` - Fetches files from a Mercurial (``hg``) revision control repository. - - - *``p4://`` -* Fetches files from a Perforce (``p4``) revision + + - ``p4://`` - Fetches files from a Perforce (``p4``) revision control repository. - - - *``ssh://`` -* Fetches files from a secure shell. - - - *``svn://`` -* Fetches files from a Subversion (``svn``) revision + + - ``ssh://`` - Fetches files from a secure shell. + + - ``svn://`` - Fetches files from a Subversion (``svn``) revision control repository. - - - *``npm://`` -* Fetches JavaScript modules from a registry. - + + - ``npm://`` - Fetches JavaScript modules from a registry. + Standard and recipe-specific options for ``SRC_URI`` exist. Here are standard options: - - - *``apply`` -* Whether to apply the patch or not. The default + + - ``apply`` - Whether to apply the patch or not. The default action is to apply the patch. - - - *``striplevel`` -* Which striplevel to use when applying the + + - ``striplevel`` - Which striplevel to use when applying the patch. The default level is 1. - - - *``patchdir`` -* Specifies the directory in which the patch should + + - ``patchdir`` - Specifies the directory in which the patch should be applied. The default is ``${``\ :term:`S`\ ``}``. - + Here are options specific to recipes building code from a revision control system: - - - *``mindate`` -* Apply the patch only if + + - ``mindate`` - Apply the patch only if :term:`SRCDATE` is equal to or greater than ``mindate``. - - - *``maxdate`` -* Apply the patch only if ``SRCDATE`` is not later + + - ``maxdate`` - Apply the patch only if ``SRCDATE`` is not later than ``maxdate``. - - - *``minrev`` -* Apply the patch only if ``SRCREV`` is equal to or + + - ``minrev`` - Apply the patch only if ``SRCREV`` is equal to or greater than ``minrev``. - - - *``maxrev`` -* Apply the patch only if ``SRCREV`` is not later + + - ``maxrev`` - Apply the patch only if ``SRCREV`` is not later than ``maxrev``. - - - *``rev`` -* Apply the patch only if ``SRCREV`` is equal to + + - ``rev`` - Apply the patch only if ``SRCREV`` is equal to ``rev``. - - - *``notrev`` -* Apply the patch only if ``SRCREV`` is not equal to + + - ``notrev`` - Apply the patch only if ``SRCREV`` is not equal to ``rev``. - + Here are some additional options worth mentioning: - - - *``unpack`` -* Controls whether or not to unpack the file if it is + + - ``unpack`` - Controls whether or not to unpack the file if it is an archive. The default action is to unpack the file. - - - *``destsuffix`` -* Places the file (or extracts its contents) into + + - ``destsuffix`` - Places the file (or extracts its contents) into the specified subdirectory of :term:`WORKDIR` when the Git fetcher is used. - - - *``subdir`` -* Places the file (or extracts its contents) into the + + - ``subdir`` - Places the file (or extracts its contents) into the specified subdirectory of ``WORKDIR`` when the local (``file://``) fetcher is used. - - - *``localdir`` -* Places the file (or extracts its contents) into + + - ``localdir`` - Places the file (or extracts its contents) into the specified subdirectory of ``WORKDIR`` when the CVS fetcher is used. - - - *``subpath`` -* Limits the checkout to a specific subpath of the + + - ``subpath`` - Limits the checkout to a specific subpath of the tree when using the Git fetcher is used. - - - *``name`` -* Specifies a name to be used for association with + + - ``name`` - Specifies a name to be used for association with ``SRC_URI`` checksums when you have more than one file specified in ``SRC_URI``. - - - *``downloadfilename`` -* Specifies the filename used when storing + + - ``downloadfilename`` - Specifies the filename used when storing the downloaded file. - + SRC_URI_OVERRIDES_PACKAGE_ARCH By default, the OpenEmbedded build system automatically detects whether ``SRC_URI`` contains files that are machine-specific. If so, the build system automatically changes ``PACKAGE_ARCH``. Setting this variable to "0" disables this behavior. - + 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). - + SRCPV Returns the version string of the current package. This string is used to help define the value of :term:`PV`. - + The ``SRCPV`` variable is defined in the ``meta/conf/bitbake.conf`` configuration file in the :term:`Source Directory` as - follows: SRCPV = "${@bb.fetch2.get_srcrev(d)}" - + follows: + :: + + SRCPV = "${@bb.fetch2.get_srcrev(d)}" + Recipes that need to define ``PV`` do so with the help of the ``SRCPV``. For example, the ``ofono`` recipe (``ofono_git.bb``) located in ``meta/recipes-connectivity`` in the Source Directory - defines ``PV`` as follows: PV = "0.12-git${SRCPV}" - + defines ``PV`` as follows: + :: + + PV = "0.12-git${SRCPV}" + SRCREV The revision of the source code used to build the package. This variable applies to Subversion, Git, Mercurial, and Bazaar only. Note @@ -6412,9 +7220,9 @@ system and gives an overview of their function and contents. performing a query on the remote repository every time BitBake parses your recipe, you should specify a ``SRCREV`` that is a full revision identifier and not just a tag. - + .. note:: - + For information on limitations when inheriting the latest revision of software using SRCREV @@ -6423,10 +7231,10 @@ system and gives an overview of their function and contents. variable description and the " Automatically Incrementing a Binary Package Revision Number " section, which is in the Yocto Project Development Tasks Manual. - + SSTATE_DIR The directory for the shared state cache. - + SSTATE_MIRROR_ALLOW_NETWORK If set to "1", allows fetches from mirrors that are specified in :term:`SSTATE_MIRRORS` to work even when @@ -6435,19 +7243,19 @@ system and gives an overview of their function and contents. you have set ``SSTATE_MIRRORS`` to point to an internal server for your shared state cache, but you want to disable any other fetching from the network. - + SSTATE_MIRRORS Configures the OpenEmbedded build system to search other mirror locations for prebuilt cache data objects before building out the data. This variable works like fetcher :term:`MIRRORS` and :term:`PREMIRRORS` and points to the cache locations to check for the shared state (sstate) objects. - + You can specify a filesystem directory or a remote URL such as HTTP or FTP. The locations you specify need to contain the shared state cache (sstate-cache) results from previous builds. The sstate-cache you point to can also be from builds on other machines. - + When pointing to sstate build artifacts on another machine that uses a different GCC version for native builds, you must configure ``SSTATE_MIRRORS`` with a regular expression that maps local search @@ -6455,24 +7263,27 @@ system and gives an overview of their function and contents. :term:`NATIVELSBSTRING` set by the :ref:`uninative ` class. For example, the following maps the local search path ``universal-4.9`` to the - server-provided path server_url_sstate_path: SSTATE_MIRRORS ?= - file://universal-4.9/(.*) - http://server_url_sstate_path/universal-4.8/\1 \\n - + server-provided path server_url_sstate_path: + :: + + SSTATE_MIRRORS ?= "file://universal-4.9/(.*) http://server_url_sstate_path/universal-4.8/\1 \n" + If a mirror uses the same structure as :term:`SSTATE_DIR`, you need to add "PATH" at the end as shown in the examples below. The build system substitutes the - correct path within the directory structure. SSTATE_MIRRORS ?= "\\ - file://.\* - http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \\n \\ - file://.\* file:///some-local-dir/sstate/PATH" - + correct path within the directory structure. + :: + + SSTATE_MIRRORS ?= "\ + file://.* http://someserver.tld/share/sstate/PATH;downloadfilename=PATH \n \ + file://.* file:///some-local-dir/sstate/PATH" + SSTATE_SCAN_FILES Controls the list of files the OpenEmbedded build system scans for hardcoded installation paths. The variable uses a space-separated list of filenames (not paths) with standard wildcard characters allowed. - + During a build, the OpenEmbedded build system creates a shared state (sstate) object during the first stage of preparing the sysroots. That object is scanned for hardcoded paths for original installation @@ -6482,32 +7293,32 @@ system and gives an overview of their function and contents. than the variable being comprehensively set. The :ref:`sstate ` class specifies the default list of files. - + For details on the process, see the :ref:`staging ` class. - + STAGING_BASE_LIBDIR_NATIVE Specifies the path to the ``/lib`` subdirectory of the sysroot directory for the build host. - + STAGING_BASELIBDIR Specifies the path to the ``/lib`` subdirectory of the sysroot directory for the target for which the current recipe is being built (:term:`STAGING_DIR_HOST`). - + STAGING_BINDIR Specifies the path to the ``/usr/bin`` subdirectory of the sysroot directory for the target for which the current recipe is being built (:term:`STAGING_DIR_HOST`). - + STAGING_BINDIR_CROSS Specifies the path to the directory containing binary configuration scripts. These scripts provide configuration information for other software that wants to make use of libraries or include files provided by the software associated with the script. - + .. note:: - + This style of build configuration has been largely replaced by pkg-config . Consequently, if @@ -6516,36 +7327,34 @@ system and gives an overview of their function and contents. recommended you use pkg-config instead of a provided configuration script. - + STAGING_BINDIR_NATIVE Specifies the path to the ``/usr/bin`` subdirectory of the sysroot directory for the build host. - + STAGING_DATADIR Specifies the path to the ``/usr/share`` subdirectory of the sysroot directory for the target for which the current recipe is being built (:term:`STAGING_DIR_HOST`). - + STAGING_DATADIR_NATIVE Specifies the path to the ``/usr/share`` subdirectory of the sysroot directory for the build host. - + STAGING_DIR Helps construct the ``recipe-sysroots`` directory, which is used during packaging. - + For information on how staging for recipe-specific sysroots occurs, see the :ref:`ref-tasks-populate_sysroot` - task, the "`Sharing Files Between - Recipes <&YOCTO_DOCS_DEV_URL;#new-sharing-files-between-recipes>`__" + task, the ":ref:`sdk-manual/sdk-extensible:sharing files between recipes`" section in the Yocto Project Development Tasks Manual, the - "`Configuration, Compilation, and - Staging <&YOCTO_DOCS_OM_URL;#configuration-compilation-and-staging-dev-environment>`__" + ":ref:`configuration-compilation-and-staging-dev-environment`" section in the Yocto Project Overview and Concepts Manual, and the :term:`SYSROOT_DIRS` variable. - + .. note:: - + Recipes should never write files directly under the STAGING_DIR directory because the OpenEmbedded build system manages the @@ -6557,7 +7366,7 @@ system and gives an overview of their function and contents. do_install task and then the OpenEmbedded build system will stage a subset of those files into the sysroot. - + STAGING_DIR_HOST Specifies the path to the sysroot directory for the system on which the component is built to run (the system that hosts the component). @@ -6568,16 +7377,16 @@ system and gives an overview of their function and contents. :term:`STAGING_DIR_NATIVE`. Depending on the type of recipe and the build target, ``STAGING_DIR_HOST`` can have the following values: - + - For recipes building for the target machine, the value is "${:term:`STAGING_DIR`}/${:term:`MACHINE`}". - + - For native recipes building for the build host, the value is empty given the assumption that when building for the build host, the build host's own directories should be used. - + .. note:: - + ``-native`` recipes are not installed into host paths like such as ``/usr``. Rather, these recipes are installed into ``STAGING_DIR_NATIVE``. When compiling ``-native`` recipes, @@ -6586,7 +7395,7 @@ system and gives an overview of their function and contents. :term:`CFLAGS` are set up so that both host paths and ``STAGING_DIR_NATIVE`` are searched for libraries and headers using, for example, GCC's ``-isystem`` option. - + Thus, the emphasis is that the ``STAGING_DIR*`` variables should be viewed as input variables by tasks such as :ref:`ref-tasks-configure`, @@ -6595,17 +7404,17 @@ system and gives an overview of their function and contents. root correspond to ``STAGING_DIR_HOST`` makes conceptual sense for ``-native`` recipes, as they make use of host headers and libraries. - + STAGING_DIR_NATIVE Specifies the path to the sysroot directory used when building components that run on the build host itself. - + STAGING_DIR_TARGET Specifies the path to the sysroot used for the system for which the component generates code. For components that do not generate code, which is the majority, ``STAGING_DIR_TARGET`` is set to match :term:`STAGING_DIR_HOST`. - + Some recipes build binaries that can run on the target system but those binaries in turn generate code for another different system (e.g. cross-canadian recipes). Using terminology from GNU, the @@ -6615,171 +7424,203 @@ system and gives an overview of their function and contents. system. The ``STAGING_DIR_HOST`` variable points to the sysroot used for the "HOST" system, while ``STAGING_DIR_TARGET`` points to the sysroot used for the "TARGET" system. - + STAGING_ETCDIR_NATIVE Specifies the path to the ``/etc`` subdirectory of the sysroot directory for the build host. - + STAGING_EXECPREFIXDIR Specifies the path to the ``/usr`` subdirectory of the sysroot directory for the target for which the current recipe is being built (:term:`STAGING_DIR_HOST`). - + STAGING_INCDIR Specifies the path to the ``/usr/include`` subdirectory of the sysroot directory for the target for which the current recipe being built (:term:`STAGING_DIR_HOST`). - + STAGING_INCDIR_NATIVE Specifies the path to the ``/usr/include`` subdirectory of the sysroot directory for the build host. - + STAGING_KERNEL_BUILDDIR Points to the directory containing the kernel build artifacts. Recipes building software that needs to access kernel build artifacts (e.g. ``systemtap-uprobes``) can look in the directory specified with the ``STAGING_KERNEL_BUILDDIR`` variable to find these artifacts after the kernel has been built. - + STAGING_KERNEL_DIR The directory with kernel headers that are required to build out-of-tree modules. - + STAGING_LIBDIR Specifies the path to the ``/usr/lib`` subdirectory of the sysroot directory for the target for which the current recipe is being built (:term:`STAGING_DIR_HOST`). - + STAGING_LIBDIR_NATIVE Specifies the path to the ``/usr/lib`` subdirectory of the sysroot directory for the build host. - + 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. Currently, the default assignment for ``STAMP`` as set in the ``meta/conf/bitbake.conf`` - file is: STAMP = - "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}" - + file is: + :: + + STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}" + For information on how BitBake uses stamp files to determine if a - task should be rerun, see the "`Stamp Files and the Rerunning of - Tasks <&YOCTO_DOCS_OM_URL;#stamp-files-and-the-rerunning-of-tasks>`__" + task should be rerun, see the + ":ref:`overview-manual/overview-manual-concepts:stamp files and the rerunning of tasks`" section in the Yocto Project Overview and Concepts Manual. - + See :term:`STAMPS_DIR`, :term:`MULTIMACH_TARGET_SYS`, :term:`PN`, :term:`EXTENDPE`, :term:`PV`, and :term:`PR` for related variable information. - + STAMPS_DIR Specifies the base directory in which the OpenEmbedded build system places stamps. The default directory is ``${TMPDIR}/stamps``. - + STRIP The minimal command and arguments to run ``strip``, which is used to strip symbols. - + SUMMARY The short (72 characters or less) summary of the binary package for packaging systems such as ``opkg``, ``rpm``, or ``dpkg``. By default, ``SUMMARY`` is used to define the :term:`DESCRIPTION` variable if ``DESCRIPTION`` is not set in the recipe. - + SVNDIR The directory in which files checked out of a Subversion system are stored. - + SYSLINUX_DEFAULT_CONSOLE Specifies the kernel boot default console. If you want to use a console other than the default, set this variable in your recipe as follows where "X" is the console number you want to use: - SYSLINUX_DEFAULT_CONSOLE = "console=ttyX" - + :: + + SYSLINUX_DEFAULT_CONSOLE = "console=ttyX" + The :ref:`syslinux ` class initially sets this variable to null but then checks for a value later. - + SYSLINUX_OPTS Lists additional options to add to the syslinux file. You need to set this variable in your recipe. If you want to list multiple options, separate the options with a semicolon character (``;``). - + The :ref:`syslinux ` class uses this variable to create a set of options. - + SYSLINUX_SERIAL Specifies the alternate serial port or turns it off. To turn off serial, set this variable to an empty string in your recipe. The variable's default value is set in the :ref:`syslinux ` class as follows: - SYSLINUX_SERIAL ?= "0 115200" - + :: + + SYSLINUX_SERIAL ?= "0 115200" + The class checks for and uses the variable as needed. - + SYSLINUX_SPLASH An ``.LSS`` file used as the background for the VGA boot menu when you use the boot menu. You need to set this variable in your recipe. - + The :ref:`syslinux ` class checks for this variable and if found, the OpenEmbedded build system installs the splash screen. - + SYSLINUX_SERIAL_TTY Specifies the alternate console=tty... kernel boot argument. The variable's default value is set in the :ref:`syslinux ` class as follows: - SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200" - + :: + + SYSLINUX_SERIAL_TTY ?= "console=ttyS0,115200" + The class checks for and uses the variable as needed. - + SYSROOT_DESTDIR Points to the temporary directory under the work directory (default "``${``\ :term:`WORKDIR`\ ``}/sysroot-destdir``") where the files populated into the sysroot are assembled during the :ref:`ref-tasks-populate_sysroot` task. - + SYSROOT_DIRS Directories that are staged into the sysroot by the :ref:`ref-tasks-populate_sysroot` task. By - default, the following directories are staged: SYSROOT_DIRS = " \\ - ${includedir} \\ ${libdir} \\ ${base_libdir} \\ - ${nonarch_base_libdir} \\ ${datadir} \\ " - + default, the following directories are staged: + :: + + SYSROOT_DIRS = " \ + ${includedir} \ + ${libdir} \ + ${base_libdir} \ + ${nonarch_base_libdir} \ + ${datadir} \ + " + SYSROOT_DIRS_BLACKLIST Directories that are not staged into the sysroot by the :ref:`ref-tasks-populate_sysroot` task. You can use this variable to exclude certain subdirectories of directories listed in :term:`SYSROOT_DIRS` from staging. By default, the following directories are not staged: - SYSROOT_DIRS_BLACKLIST = " \\ ${mandir} \\ ${docdir} \\ ${infodir} \\ - ${datadir}/locale \\ ${datadir}/applications \\ ${datadir}/fonts \\ - ${datadir}/pixmaps \\ " - + :: + + SYSROOT_DIRS_BLACKLIST = " \ + ${mandir} \ + ${docdir} \ + ${infodir} \ + ${datadir}/locale \ + ${datadir}/applications \ + ${datadir}/fonts \ + ${datadir}/pixmaps \ + " + SYSROOT_DIRS_NATIVE Extra directories staged into the sysroot by the :ref:`ref-tasks-populate_sysroot` task for ``-native`` recipes, in addition to those specified in :term:`SYSROOT_DIRS`. By default, the following - extra directories are staged: SYSROOT_DIRS_NATIVE = " \\ ${bindir} \\ - ${sbindir} \\ ${base_bindir} \\ ${base_sbindir} \\ ${libexecdir} \\ - ${sysconfdir} \\ ${localstatedir} \\ " - + extra directories are staged: + :: + + SYSROOT_DIRS_NATIVE = " \ + ${bindir} \ + ${sbindir} \ + ${base_bindir} \ + ${base_sbindir} \ + ${libexecdir} \ + ${sysconfdir} \ + ${localstatedir} \ + " + .. note:: - + Programs built by -native recipes run directly from the sysroot ( STAGING_DIR_NATIVE ), which is why additional directories containing program executables and supporting files need to be staged. - + SYSROOT_PREPROCESS_FUNCS A list of functions to execute after files are staged into the sysroot. These functions are usually used to apply additional processing on the staged files, or to stage additional files. - + SYSTEMD_AUTO_ENABLE When inheriting the :ref:`systemd ` class, this variable specifies whether the specified service in @@ -6787,111 +7628,138 @@ system and gives an overview of their function and contents. automatically or not. By default, the service is enabled to automatically start at boot time. The default setting is in the :ref:`systemd ` class as follows: - SYSTEMD_AUTO_ENABLE ??= "enable" - + :: + + SYSTEMD_AUTO_ENABLE ??= "enable" + You can disable the service by setting the variable to "disable". - + SYSTEMD_BOOT_CFG When :term:`EFI_PROVIDER` is set to "systemd-boot", the ``SYSTEMD_BOOT_CFG`` variable specifies the configuration file that should be used. By default, the :ref:`systemd-boot ` class sets the - ``SYSTEMD_BOOT_CFG`` as follows: SYSTEMD_BOOT_CFG ?= - "${:term:`S`}/loader.conf" - + ``SYSTEMD_BOOT_CFG`` as follows: + :: + + SYSTEMD_BOOT_CFG ?= "${:term:`S`}/loader.conf" + For information on Systemd-boot, see the `Systemd-boot documentation `__. - + SYSTEMD_BOOT_ENTRIES When :term:`EFI_PROVIDER` is set to "systemd-boot", the ``SYSTEMD_BOOT_ENTRIES`` variable specifies a list of entry files (``*.conf``) to install that contain one boot entry per file. By default, the :ref:`systemd-boot ` class sets the - ``SYSTEMD_BOOT_ENTRIES`` as follows: SYSTEMD_BOOT_ENTRIES ?= "" - + ``SYSTEMD_BOOT_ENTRIES`` as follows: + :: + + SYSTEMD_BOOT_ENTRIES ?= "" + For information on Systemd-boot, see the `Systemd-boot documentation `__. - + SYSTEMD_BOOT_TIMEOUT When :term:`EFI_PROVIDER` is set to "systemd-boot", the ``SYSTEMD_BOOT_TIMEOUT`` variable specifies the boot menu timeout in seconds. By default, the :ref:`systemd-boot ` class sets the - ``SYSTEMD_BOOT_TIMEOUT`` as follows: SYSTEMD_BOOT_TIMEOUT ?= "10" - + ``SYSTEMD_BOOT_TIMEOUT`` as follows: + :: + + SYSTEMD_BOOT_TIMEOUT ?= "10" + For information on Systemd-boot, see the `Systemd-boot documentation `__. - + SYSTEMD_PACKAGES When inheriting the :ref:`systemd ` class, this variable locates the systemd unit files when they are not found in the main recipe's package. By default, the ``SYSTEMD_PACKAGES`` variable is set such that the systemd unit files are assumed to - reside in the recipes main package: SYSTEMD_PACKAGES ?= "${PN}" - + reside in the recipes main package: + :: + + SYSTEMD_PACKAGES ?= "${PN}" + If these unit files are not in this recipe's main package, you need to use ``SYSTEMD_PACKAGES`` to list the package or packages in which the build system can find the systemd unit files. - + SYSTEMD_SERVICE When inheriting the :ref:`systemd ` class, this variable specifies the systemd service name for a package. - + When you specify this file in your recipe, use a package name override to indicate the package to which the value applies. Here is - an example from the connman recipe: SYSTEMD_SERVICE_${PN} = - "connman.service" - + an example from the connman recipe: + :: + + SYSTEMD_SERVICE_${PN} = "connman.service" + SYSVINIT_ENABLED_GETTYS When using - `SysVinit <&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services>`__, + :ref:`SysVinit `, specifies a space-separated list of the virtual terminals that should run a `getty `__ (allowing login), assuming :term:`USE_VT` is not set to "0". - + The default value for ``SYSVINIT_ENABLED_GETTYS`` is "1" (i.e. only run a getty on the first virtual terminal). - + T This variable points to a directory were BitBake places temporary files, which consist mostly of task logs and scripts, when building a - particular recipe. The variable is typically set as follows: T = - "${WORKDIR}/temp" - + particular recipe. The variable is typically set as follows: + :: + + T = "${WORKDIR}/temp" + The :term:`WORKDIR` is the directory into which BitBake unpacks and builds the recipe. The default ``bitbake.conf`` file sets this variable. - + The ``T`` variable is not to be confused with the :term:`TMPDIR` variable, which points to the root of the directory tree where BitBake places the output of an entire build. - + TARGET_ARCH The target machine's architecture. The OpenEmbedded build system supports many architectures. Here is an example list of architectures supported. This list is by no means complete as the architecture is - configurable: arm i586 x86_64 powerpc powerpc64 mips mipsel - + configurable: + + - arm + - i586 + - x86_64 + - powerpc + - powerpc64 + - mips + - mipsel + For additional information on machine architectures, see the :term:`TUNE_ARCH` variable. - + TARGET_AS_ARCH Specifies architecture-specific assembler flags for the target system. ``TARGET_AS_ARCH`` is initialized from :term:`TUNE_ASARGS` by default in the BitBake - configuration file (``meta/conf/bitbake.conf``): TARGET_AS_ARCH = - "${TUNE_ASARGS}" - + configuration file (``meta/conf/bitbake.conf``): + :: + + TARGET_AS_ARCH = "${TUNE_ASARGS}" + TARGET_CC_ARCH Specifies architecture-specific C compiler flags for the target system. ``TARGET_CC_ARCH`` is initialized from :term:`TUNE_CCARGS` by default. - + .. note:: - + It is a common workaround to append LDFLAGS to @@ -6900,7 +7768,7 @@ system and gives an overview of their function and contents. otherwise respect the exported LDFLAGS variable. - + TARGET_CC_KERNEL_ARCH This is a specific kernel compiler flag for a CPU or Application Binary Interface (ABI) tune. The flag is used rarely and only for @@ -6910,118 +7778,118 @@ system and gives an overview of their function and contents. different configuration. See the ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in the :term:`Source Directory` for an example. - + TARGET_CFLAGS Specifies the flags to pass to the C compiler when building for the target. When building in the target context, :term:`CFLAGS` is set to the value of this variable by default. - + Additionally, the SDK's environment setup script sets the ``CFLAGS`` variable in the environment to the ``TARGET_CFLAGS`` value so that executables built using the SDK also have the flags applied. - + TARGET_CPPFLAGS Specifies the flags to pass to the C pre-processor (i.e. to both the C and the C++ compilers) when building for the target. When building in the target context, :term:`CPPFLAGS` is set to the value of this variable by default. - + Additionally, the SDK's environment setup script sets the ``CPPFLAGS`` variable in the environment to the ``TARGET_CPPFLAGS`` value so that executables built using the SDK also have the flags applied. - + TARGET_CXXFLAGS Specifies the flags to pass to the C++ compiler when building for the target. When building in the target context, :term:`CXXFLAGS` is set to the value of this variable by default. - + Additionally, the SDK's environment setup script sets the ``CXXFLAGS`` variable in the environment to the ``TARGET_CXXFLAGS`` value so that executables built using the SDK also have the flags applied. - + TARGET_FPU Specifies the method for handling FPU code. For FPU-less targets, which include most ARM CPUs, the variable must be set to "soft". If not, the kernel emulation gets used, which results in a performance penalty. - + TARGET_LD_ARCH Specifies architecture-specific linker flags for the target system. ``TARGET_LD_ARCH`` is initialized from :term:`TUNE_LDARGS` by default in the BitBake - configuration file (``meta/conf/bitbake.conf``): TARGET_LD_ARCH = - "${TUNE_LDARGS}" - + configuration file (``meta/conf/bitbake.conf``): + :: + + TARGET_LD_ARCH = "${TUNE_LDARGS}" + TARGET_LDFLAGS Specifies the flags to pass to the linker when building for the target. When building in the target context, :term:`LDFLAGS` is set to the value of this variable by default. - + Additionally, the SDK's environment setup script sets the :term:`LDFLAGS` variable in the environment to the ``TARGET_LDFLAGS`` value so that executables built using the SDK also have the flags applied. - + TARGET_OS Specifies the target's operating system. The variable can be set to "linux" for glibc-based systems (GNU C Library) and to "linux-musl" for musl libc. For ARM/EABI targets, "linux-gnueabi" and "linux-musleabi" possible values exist. - + TARGET_PREFIX Specifies the prefix used for the toolchain binary target tools. - + Depending on the type of recipe and the build target, ``TARGET_PREFIX`` is set as follows: - + - For recipes building for the target machine, the value is "${:term:`TARGET_SYS`}-". - + - For native recipes, the build system sets the variable to the value of ``BUILD_PREFIX``. - + - For native SDK recipes (``nativesdk``), the build system sets the variable to the value of ``SDK_PREFIX``. - + TARGET_SYS Specifies the system, including the architecture and the operating system, for which the build is occurring in the context of the current recipe. - + The OpenEmbedded build system automatically sets this variable based on :term:`TARGET_ARCH`, :term:`TARGET_VENDOR`, and :term:`TARGET_OS` variables. - + .. note:: - - You do not need to set the - TARGET_SYS - variable yourself. - + + You do not need to set the TARGET_SYS variable yourself. + Consider these two examples: - + - Given a native recipe on a 32-bit, x86 machine running Linux, the value is "i686-linux". - + - Given a recipe being built for a little-endian, MIPS target running Linux, the value might be "mipsel-linux". - + TARGET_VENDOR Specifies the name of the target vendor. - + TCLIBC Specifies the GNU standard C library (``libc``) variant to use during the build process. This variable replaces ``POKYLIBC``, which is no longer supported. - + You can select "glibc", "musl", "newlib", or "baremetal" - + TCLIBCAPPEND Specifies a suffix to be appended onto the :term:`TMPDIR` value. The suffix identifies the @@ -7029,13 +7897,13 @@ system and gives an overview of their function and contents. variants with the same :term:`Build Directory`, this mechanism ensures that output for different ``libc`` variants is kept separate to avoid potential conflicts. - + In the ``defaultsetup.conf`` file, the default value of ``TCLIBCAPPEND`` is "-${TCLIBC}". However, distros such as poky, which normally only support one ``libc`` variant, set ``TCLIBCAPPEND`` to "" in their distro configuration file resulting in no suffix being applied. - + TCMODE Specifies the toolchain selector. ``TCMODE`` controls the characteristics of the generated packages and images by telling the @@ -7043,9 +7911,9 @@ system and gives an overview of their function and contents. the OpenEmbedded build system builds its own internal toolchain. The variable's default value is "default", which uses that internal toolchain. - + .. note:: - + If TCMODE is set to a value other than "default", then it is your @@ -7058,53 +7926,53 @@ system and gives an overview of their function and contents. Downloads page on the Yocto Project website and click on the "RELEASE INFORMATION" link for the appropriate release. - + The ``TCMODE`` variable is similar to :term:`TCLIBC`, which controls the variant of the GNU standard C library (``libc``) used during the build process: ``glibc`` or ``musl``. - + With additional layers, it is possible to use a pre-compiled external toolchain. One example is the Sourcery G++ Toolchain. The support for this toolchain resides in the separate Mentor Graphics ``meta-sourcery`` layer at http://github.com/MentorEmbedded/meta-sourcery/. - + The layer's ``README`` file contains information on how to use the Sourcery G++ Toolchain as an external toolchain. In summary, you must be sure to add the layer to your ``bblayers.conf`` file in front of the ``meta`` layer and then set the ``EXTERNAL_TOOLCHAIN`` variable in your ``local.conf`` file to the location in which you installed the toolchain. - + The fundamentals used for this example apply to any external toolchain. You can use ``meta-sourcery`` as a template for adding support for other external toolchains. - + TEST_EXPORT_DIR The location the OpenEmbedded build system uses to export tests when the :term:`TEST_EXPORT_ONLY` variable is set to "1". - + The ``TEST_EXPORT_DIR`` variable defaults to ``"${TMPDIR}/testimage/${PN}"``. - + TEST_EXPORT_ONLY Specifies to export the tests only. Set this variable to "1" if you do not want to run the tests but you want them to be exported in a manner that you to run them outside of the build system. - + TEST_LOG_DIR Holds the SSH log and the boot log for QEMU machines. The ``TEST_LOG_DIR`` variable defaults to ``"${WORKDIR}/testimage"``. - + .. note:: - + Actual test results reside in the task log ( log.do_testimage ), which is in the ${WORKDIR}/temp/ directory. - + TEST_POWERCONTROL_CMD For automated hardware testing, specifies the command to use to control the power of the target machine under test. Typically, this @@ -7113,7 +7981,7 @@ system and gives an overview of their function and contents. command should expect to receive as the last argument "off", "on" or "cycle" specifying to power off, on, or cycle (power off and then power on) the device, respectively. - + TEST_POWERCONTROL_EXTRA_ARGS For automated hardware testing, specifies additional arguments to pass through to the command specified in @@ -7121,30 +7989,31 @@ system and gives an overview of their function and contents. ``TEST_POWERCONTROL_EXTRA_ARGS`` is optional. You can use it if you wish, for example, to separate the machine-specific and non-machine-specific parts of the arguments. - + TEST_QEMUBOOT_TIMEOUT The time in seconds allowed for an image to boot before automated runtime tests begin to run against an image. The default timeout period to allow the boot process to reach the login prompt is 500 seconds. You can specify a different value in the ``local.conf`` file. - - For more information on testing images, see the "`Performing - Automated Runtime - Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" + + For more information on testing images, see the + ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" section in the Yocto Project Development Tasks Manual. - + TEST_SERIALCONTROL_CMD For automated hardware testing, specifies the command to use to connect to the serial console of the target machine under test. This command simply needs to connect to the serial console and forward that connection to standard input and output as any normal terminal program does. - + For example, to use the Picocom terminal program on serial device ``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows: - TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200" - + :: + + TEST_SERIALCONTROL_CMD = "picocom /dev/ttyUSB0 -b 115200" + TEST_SERIALCONTROL_EXTRA_ARGS For automated hardware testing, specifies additional arguments to pass through to the command specified in @@ -7152,238 +8021,273 @@ system and gives an overview of their function and contents. ``TEST_SERIALCONTROL_EXTRA_ARGS`` is optional. You can use it if you wish, for example, to separate the machine-specific and non-machine-specific parts of the command. - + TEST_SERVER_IP The IP address of the build machine (host machine). This IP address is usually automatically detected. However, if detection fails, this variable needs to be set to the IP address of the build machine (i.e. where the build is taking place). - + .. note:: - + The TEST_SERVER_IP variable is only used for a small number of tests such as the "dnf" test suite, which needs to download packages from WORKDIR/oe-rootfs-repo . - + TEST_TARGET Specifies the target controller to use when running tests against a - test image. The default controller to use is "qemu": TEST_TARGET = - "qemu" - + test image. The default controller to use is "qemu": + :: + + TEST_TARGET = "qemu" + A target controller is a class that defines how an image gets deployed on a target and how a target is started. A layer can extend the controllers by adding a module in the layer's ``/lib/oeqa/controllers`` directory and by inheriting the ``BaseTarget`` class, which is an abstract class that cannot be used as a value of ``TEST_TARGET``. - + You can provide the following arguments with ``TEST_TARGET``: - + - *"qemu":* Boots a QEMU image and runs the tests. See the - "`Enabling Runtime Tests on - QEMU <&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests>`__" section + ":ref:`qemu-image-enabling-tests`" section in the Yocto Project Development Tasks Manual for more information. - + - *"simpleremote":* Runs the tests on target hardware that is already up and running. The hardware can be on the network or it can be a device running an image on QEMU. You must also set :term:`TEST_TARGET_IP` when you use "simpleremote". - + .. note:: - + This argument is defined in meta/lib/oeqa/controllers/simpleremote.py . - - For information on running tests on hardware, see the "`Enabling - Runtime Tests on - Hardware <&YOCTO_DOCS_DEV_URL;#hardware-image-enabling-tests>`__" + + For information on running tests on hardware, see the + ":ref:`hardware-image-enabling-tests`" section in the Yocto Project Development Tasks Manual. - + TEST_TARGET_IP The IP address of your hardware under test. The ``TEST_TARGET_IP`` variable has no effect when :term:`TEST_TARGET` is set to "qemu". - + When you specify the IP address, you can also include a port. Here is - an example: TEST_TARGET_IP = "192.168.1.4:2201" Specifying a port is + an example: + :: + + TEST_TARGET_IP = "192.168.1.4:2201" + + Specifying a port is useful when SSH is started on a non-standard port or in cases when your hardware under test is behind a firewall or network that is not directly accessible from your host and you need to do port address translation. - + TEST_SUITES An ordered list of tests (modules) to run against an image when performing automated runtime testing. - + The OpenEmbedded build system provides a core set of tests that can be used against images. - + .. note:: - + Currently, there is only support for running these tests under QEMU. - + Tests include ``ping``, ``ssh``, ``df`` among others. You can add your own tests to the list of tests by appending ``TEST_SUITES`` as - follows: TEST_SUITES_append = " mytest" Alternatively, you can + follows: + :: + + TEST_SUITES_append = " mytest" + + Alternatively, you can provide the "auto" option to have all applicable tests run against - the image. TEST_SUITES_append = " auto" Using this option causes the + the image. + :: + + TEST_SUITES_append = " auto" + + Using this option causes the build system to automatically run tests that are applicable to the image. Tests that are not applicable are skipped. - + The order in which tests are run is important. Tests that depend on another test must appear later in the list than the test on which they depend. For example, if you append the list of tests with two tests (``test_A`` and ``test_B``) where ``test_B`` is dependent on - ``test_A``, then you must order the tests as follows: TEST_SUITES = " - test_A test_B" - - For more information on testing images, see the "`Performing - Automated Runtime - Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" + ``test_A``, then you must order the tests as follows: + :: + + TEST_SUITES = "test_A test_B" + + For more information on testing images, see the + ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" section in the Yocto Project Development Tasks Manual. - + TESTIMAGE_AUTO Automatically runs the series of automated tests for images when an image is successfully built. Setting ``TESTIMAGE_AUTO`` to "1" causes any image that successfully builds to automatically boot under QEMU. Using the variable also adds in dependencies so that any SDK for which testing is requested is automatically built first. - + These tests are written in Python making use of the ``unittest`` module, and the majority of them run commands on the target system over ``ssh``. You can set this variable to "1" in your ``local.conf`` file in the :term:`Build Directory` to have the OpenEmbedded build system automatically run these tests after an - image successfully builds: TESTIMAGE_AUTO = "1" For more information - on enabling, running, and writing these tests, see the "`Performing - Automated Runtime - Testing <&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing>`__" + image successfully builds: + + TESTIMAGE_AUTO = "1" + + For more information + on enabling, running, and writing these tests, see the + ":ref:`dev-manual/dev-manual-common-tasks:performing automated runtime testing`" section in the Yocto Project Development Tasks Manual and the ":ref:`testimage*.bbclass `" section. - + THISDIR The directory in which the file BitBake is currently parsing is located. Do not manually set this variable. - + TIME The time the build was started. Times appear using the hour, minute, and second (HMS) format (e.g. "140159" for one minute and fifty-nine seconds past 1400 hours). - + TMPDIR This variable is the base directory the OpenEmbedded build system uses for all build output and intermediate files (other than the shared state cache). By default, the ``TMPDIR`` variable points to ``tmp`` within the :term:`Build Directory`. - + If you want to establish this directory in a location other than the default, you can uncomment and edit the following statement in the ``conf/local.conf`` file in the :term:`Source Directory`: - #TMPDIR = "${TOPDIR}/tmp" An - example use for this scenario is to set ``TMPDIR`` to a local disk, + :: + + #TMPDIR = "${TOPDIR}/tmp" + + An example use for this scenario is to set ``TMPDIR`` to a local disk, which does not use NFS, while having the Build Directory use NFS. - + The filesystem used by ``TMPDIR`` must have standard filesystem semantics (i.e. mixed-case files are unique, POSIX file locking, and persistent inodes). Due to various issues with NFS and bugs in some implementations, NFS does not meet this minimum requirement. Consequently, ``TMPDIR`` cannot be on NFS. - + TOOLCHAIN_HOST_TASK This variable lists packages the OpenEmbedded build system uses when building an SDK, which contains a cross-development environment. The packages specified by this variable are part of the toolchain set that runs on the :term:`SDKMACHINE`, and each package should usually have the prefix ``nativesdk-``. For example, - consider the following command when building an SDK: $ bitbake -c - populate_sdk imagename In this case, a default list of packages is + consider the following command when building an SDK: + :: + + $ bitbake -c populate_sdk imagename + + In this case, a default list of packages is set in this variable, but you can add additional packages to the - list. See the "`Adding Individual Packages to the Standard - SDK <&YOCTO_DOCS_SDK_URL;#sdk-adding-individual-packages>`__" section + list. See the + ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual for more information. - + For background information on cross-development toolchains in the - Yocto Project development environment, see the "`Cross-Development - Toolchain - Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__" + Yocto Project development environment, see the + ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`" section in the Yocto Project Overview and Concepts Manual. For information on setting up a cross-development environment, see the - `Yocto Project Application Development and the Extensible Software - Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual. - + :doc:`../sdk-manual/sdk-manual` manual. + TOOLCHAIN_OUTPUTNAME This variable defines the name used for the toolchain output. The :ref:`populate_sdk_base ` class sets the ``TOOLCHAIN_OUTPUTNAME`` variable as follows: - TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" See + :: + + TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}" + + See the :term:`SDK_NAME` and :term:`SDK_VERSION` variables for additional information. - + TOOLCHAIN_TARGET_TASK This variable lists packages the OpenEmbedded build system uses when it creates the target part of an SDK (i.e. the part built for the target hardware), which includes libraries and headers. Use this variable to add individual packages to the part of the SDK that runs - on the target. See the "`Adding Individual Packages to the Standard - SDK <&YOCTO_DOCS_SDK_URL;#sdk-adding-individual-packages>`__" section + on the target. See the + ":ref:`sdk-manual/sdk-appendix-customizing-standard:adding individual packages to the standard sdk`" section in the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual for more information. - + For background information on cross-development toolchains in the - Yocto Project development environment, see the "`Cross-Development - Toolchain - Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__" + Yocto Project development environment, see the + ":ref:`sdk-manual/sdk-intro:the cross-development toolchain`" section in the Yocto Project Overview and Concepts Manual. For information on setting up a cross-development environment, see the - `Yocto Project Application Development and the Extensible Software - Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual. - + :doc:`../sdk-manual/sdk-manual` manual. + TOPDIR The top-level :term:`Build Directory`. BitBake automatically sets this variable when you initialize your build environment using ````` <#structure-core-script>`__. - + TRANSLATED_TARGET_ARCH A sanitized version of :term:`TARGET_ARCH`. This variable is used where the architecture is needed in a value where underscores are not allowed, for example within package filenames. In this case, dash characters replace any underscore characters used in ``TARGET_ARCH``. - + Do not edit this variable. - + TUNE_ARCH The GNU canonical architecture for a specific architecture (i.e. ``arm``, ``armeb``, ``mips``, ``mips64``, and so forth). BitBake uses this value to setup configuration. - + ``TUNE_ARCH`` definitions are specific to a given architecture. The definitions can be a single static definition, or can be dynamically adjusted. You can see details for a given CPU family by looking at the architecture's ``README`` file. For example, the - ``meta/conf/machine/include/mips/README`` file in the + ``meta/conf/machine/include/mips/README`` file in the :term:`Source Directory` provides information for ``TUNE_ARCH`` specific to the ``mips`` architecture. - + ``TUNE_ARCH`` is tied closely to :term:`TARGET_ARCH`, which defines the target machine's architecture. The BitBake configuration file (``meta/conf/bitbake.conf``) sets ``TARGET_ARCH`` as follows: - TARGET_ARCH = "${TUNE_ARCH}" - + :: + + TARGET_ARCH = "${TUNE_ARCH}" + The following list, which is by no means complete since architectures - are configurable, shows supported machine architectures: arm i586 - x86_64 powerpc powerpc64 mips mipsel - + are configurable, shows supported machine architectures: + + - arm + - i586 + - x86_64 + - powerpc + - powerpc64 + - mips + - mipsel + TUNE_ASARGS Specifies architecture-specific assembler flags for the target system. The set of flags is based on the selected tune features. @@ -7391,28 +8295,30 @@ system and gives an overview of their function and contents. typically under ``meta/conf/machine/include/`` and are influenced through :term:`TUNE_FEATURES`. For example, the ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags - for the x86 architecture as follows: TUNE_ASARGS += - "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}" - + for the x86 architecture as follows: + :: + + TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}" + .. note:: - + Board Support Packages (BSPs) select the tune. The selected tune, in turn, affects the tune variables themselves (i.e. the tune can supply its own set of flags). - + TUNE_CCARGS Specifies architecture-specific C compiler flags for the target system. The set of flags is based on the selected tune features. ``TUNE_CCARGS`` is set using the tune include files, which are typically under ``meta/conf/machine/include/`` and are influenced through :term:`TUNE_FEATURES`. - + .. note:: - + Board Support Packages (BSPs) select the tune. The selected tune, in turn, affects the tune variables themselves (i.e. the tune can supply its own set of flags). - + TUNE_LDARGS Specifies architecture-specific linker flags for the target system. The set of flags is based on the selected tune features. @@ -7420,41 +8326,49 @@ system and gives an overview of their function and contents. typically under ``meta/conf/machine/include/`` and are influenced through :term:`TUNE_FEATURES`. For example, the ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags - for the x86 architecture as follows: TUNE_LDARGS += - "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", - d)}" - + for the x86 architecture as follows: + :: + + TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}" + .. note:: - + Board Support Packages (BSPs) select the tune. The selected tune, in turn, affects the tune variables themselves (i.e. the tune can supply its own set of flags). - + TUNE_FEATURES Features used to "tune" a compiler for optimal use given a specific processor. The features are defined within the tune files and allow arguments (i.e. ``TUNE_*ARGS``) to be dynamically generated based on the features. - + The OpenEmbedded build system verifies the features to be sure they are not conflicting and that they are supported. - + The BitBake configuration file (``meta/conf/bitbake.conf``) defines - ``TUNE_FEATURES`` as follows: TUNE_FEATURES ??= - "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" See the - :term:`DEFAULTTUNE` variable for more information. - + ``TUNE_FEATURES`` as follows: + :: + + TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}" + + See the :term:`DEFAULTTUNE` variable for more information. + TUNE_PKGARCH The package architecture understood by the packaging system to define the architecture, ABI, and tuning of output packages. The specific tune is defined using the "_tune" override as follows: - TUNE_PKGARCH_tune-tune = "tune" - + :: + + TUNE_PKGARCH_tune-tune = "tune" + These tune-specific package architectures are defined in the machine include files. Here is an example of the "core2-32" tuning as used in the ``meta/conf/machine/include/tune-core2.inc`` file: - TUNE_PKGARCH_tune-core2-32 = "core2-32" - + :: + + TUNE_PKGARCH_tune-core2-32 = "core2-32" + TUNEABI An underlying Application Binary Interface (ABI) used by a particular tuning in a given toolchain layer. Providers that use prebuilt @@ -7462,11 +8376,11 @@ system and gives an overview of their function and contents. :term:`TUNEABI_OVERRIDE`, and :term:`TUNEABI_WHITELIST` variables to check compatibility of tunings against their selection of libraries. - + If ``TUNEABI`` is undefined, then every tuning is allowed. See the :ref:`sanity ` class to see how the variable is used. - + TUNEABI_OVERRIDE If set, the OpenEmbedded system ignores the :term:`TUNEABI_WHITELIST` variable. @@ -7474,10 +8388,10 @@ system and gives an overview of their function and contents. ``TUNEABI_OVERRIDE``, ``TUNEABI_WHITELIST``, and :term:`TUNEABI` variables to check compatibility of a tuning against their selection of libraries. - + See the :ref:`sanity ` class to see how the variable is used. - + TUNEABI_WHITELIST A whitelist of permissible :term:`TUNEABI` values. If ``TUNEABI_WHITELIST`` is not set, all tunes are allowed. Providers @@ -7485,100 +8399,112 @@ system and gives an overview of their function and contents. :term:`TUNEABI_OVERRIDE`, and ``TUNEABI`` variables to check compatibility of a tuning against their selection of libraries. - + See the :ref:`sanity ` class to see how the variable is used. - + TUNECONFLICTS[feature] Specifies CPU or Application Binary Interface (ABI) tuning features that conflict with feature. - + Known tuning conflicts are specified in the machine include files in the :term:`Source Directory`. Here is an example from the ``meta/conf/machine/include/mips/arch-mips.inc`` include file that lists the "o32" and "n64" features as conflicting with the "n32" - feature: TUNECONFLICTS[n32] = "o32 n64" - + feature: + :: + + TUNECONFLICTS[n32] = "o32 n64" + TUNEVALID[feature] Specifies a valid CPU or Application Binary Interface (ABI) tuning feature. The specified feature is stored as a flag. Valid features are specified in the machine include files (e.g. ``meta/conf/machine/include/arm/arch-arm.inc``). Here is an example - from that file: TUNEVALID[bigendian] = "Enable big-endian mode." - + from that file: + :: + + TUNEVALID[bigendian] = "Enable big-endian mode." + See the machine include files in the :term:`Source Directory` for these features. - + UBOOT_CONFIG Configures the :term:`UBOOT_MACHINE` and can also define :term:`IMAGE_FSTYPES` for individual cases. - - Following is an example from the ``meta-fsl-arm`` layer. UBOOT_CONFIG - ??= "sd" UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard" - UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config" - UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs" - UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config" In this example, - "sd" is selected as the configuration of the possible four for the + + Following is an example from the ``meta-fsl-arm`` layer. :: + + UBOOT_CONFIG ??= "sd" + UBOOT_CONFIG[sd] = "mx6qsabreauto_config,sdcard" + UBOOT_CONFIG[eimnor] = "mx6qsabreauto_eimnor_config" + UBOOT_CONFIG[nand] = "mx6qsabreauto_nand_config,ubifs" + UBOOT_CONFIG[spinor] = "mx6qsabreauto_spinor_config" + + In this example, "sd" is selected as the configuration of the possible four for the ``UBOOT_MACHINE``. The "sd" configuration defines "mx6qsabreauto_config" as the value for ``UBOOT_MACHINE``, while the "sdcard" specifies the ``IMAGE_FSTYPES`` to use for the U-boot image. - + For more information on how the ``UBOOT_CONFIG`` is handled, see the - ```uboot-config`http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/uboot-config.bbclass + :ref:`uboot-config ` class. UBOOT_DTB_LOADADDRESS Specifies the load address for the dtb image used by U-boot. During FIT image creation, the ``UBOOT_DTB_LOADADDRESS`` variable is used in - ``kernel-fitimage`` class to specify the load address to be used in + :ref:`kernel-fitimage ` class to specify + the load address to be used in creating the dtb sections of Image Tree Source for the FIT image. UBOOT_DTBO_LOADADDRESS Specifies the load address for the dtbo image used by U-boot. During FIT image creation, the ``UBOOT_DTBO_LOADADDRESS`` variable is used in - ``kernel-fitimage`` class to specify the load address to be used in + :ref:`kernel-fitimage ` class to specify the load address to be used in creating the dtbo sections of Image Tree Source for the FIT image. - + UBOOT_ENTRYPOINT Specifies the entry point for the U-Boot image. During U-Boot image creation, the ``UBOOT_ENTRYPOINT`` variable is passed as a command-line parameter to the ``uboot-mkimage`` utility. - + UBOOT_LOADADDRESS Specifies the load address for the U-Boot image. During U-Boot image creation, the ``UBOOT_LOADADDRESS`` variable is passed as a command-line parameter to the ``uboot-mkimage`` utility. - + UBOOT_LOCALVERSION Appends a string to the name of the local version of the U-Boot image. For example, assuming the version of the U-Boot image built was "2013.10", the full version string reported by U-Boot would be - "2013.10-yocto" given the following statement: UBOOT_LOCALVERSION = - "-yocto" - + "2013.10-yocto" given the following statement: + :: + + UBOOT_LOCALVERSION = "-yocto" + UBOOT_MACHINE Specifies the value passed on the ``make`` command line when building a U-Boot image. The value indicates the target platform configuration. You typically set this variable from the machine configuration file (i.e. ``conf/machine/machine_name.conf``). - + Please see the "Selection of Processor Architecture and Board Type" section in the U-Boot README for valid values for this variable. - + UBOOT_MAKE_TARGET Specifies the target called in the ``Makefile``. The default target is "all". UBOOT_MKIMAGE_DTCOPTS Options for the device tree compiler passed to mkimage '-D' - feature while creating FIT image in ``kernel-fitimage`` class. + feature while creating FIT image in :ref:`kernel-fitimage ` class. UBOOT_RD_LOADADDRESS Specifies the load address for the RAM disk image. During FIT image creation, the ``UBOOT_RD_LOADADDRESS`` variable is used - in ``kernel-fitimage`` class to specify the + in :ref:`kernel-fitimage ` class to specify the load address to be used in creating the Image Tree Source for the FIT image. @@ -7586,10 +8512,10 @@ system and gives an overview of their function and contents. Specifies the entrypoint for the RAM disk image. During FIT image creation, the ``UBOOT_RD_ENTRYPOINT`` variable is used - in ``kernel-fitimage`` class to specify the + in :ref:`kernel-fitimage ` class to specify the entrypoint to be used in creating the Image Tree Source for the FIT image. - + UBOOT_SIGN_ENABLE Enable signing of FIT image. The default value is "0". @@ -7628,40 +8554,44 @@ system and gives an overview of their function and contents. configure scripts. It follows that no benefit exists in seeing a warning about these options. For these cases, the options are added to ``UNKNOWN_CONFIGURE_WHITELIST``. - + The configure arguments check that uses ``UNKNOWN_CONFIGURE_WHITELIST`` is part of the :ref:`insane ` class and is only enabled if the recipe inherits the :ref:`autotools ` class. - + UPDATERCPN For recipes inheriting the :ref:`update-rc.d ` class, ``UPDATERCPN`` specifies the package that contains the initscript that is enabled. - + The default value is "${PN}". Given that almost all recipes that install initscripts package them in the main package for the recipe, you rarely need to set this variable in individual recipes. - + UPSTREAM_CHECK_GITTAGREGEX You can perform a per-recipe check for what the latest upstream source code version is by calling ``bitbake -c checkpkg`` recipe. If the recipe source code is provided from Git repositories, the OpenEmbedded build system determines the latest upstream version by picking the latest tag from the list of all repository tags. - + You can use the ``UPSTREAM_CHECK_GITTAGREGEX`` variable to provide a regular expression to filter only the relevant tags should the - default filter not work correctly. UPSTREAM_CHECK_GITTAGREGEX = - "git_tag_regex" - + default filter not work correctly. + :: + + UPSTREAM_CHECK_GITTAGREGEX = "git_tag_regex" + UPSTREAM_CHECK_REGEX Use the ``UPSTREAM_CHECK_REGEX`` variable to specify a different regular expression instead of the default one when the package checking system is parsing the page found using :term:`UPSTREAM_CHECK_URI`. - UPSTREAM_CHECK_REGEX = "package_regex" - + :: + + UPSTREAM_CHECK_REGEX = "package_regex" + UPSTREAM_CHECK_URI You can perform a per-recipe check for what the latest upstream source code version is by calling ``bitbake -c checkpkg`` recipe. If @@ -7669,43 +8599,48 @@ system and gives an overview of their function and contents. determined by fetching the directory listing where the tarball is and attempting to find a later tarball. When this approach does not work, you can use ``UPSTREAM_CHECK_URI`` to provide a different URI that - contains the link to the latest tarball. UPSTREAM_CHECK_URI = - "recipe_url" - + contains the link to the latest tarball. + :: + + UPSTREAM_CHECK_URI = "recipe_url" + USE_DEVFS Determines if ``devtmpfs`` is used for ``/dev`` population. The default value used for ``USE_DEVFS`` is "1" when no value is specifically set. Typically, you would set ``USE_DEVFS`` to "0" for a statically populated ``/dev`` directory. - - See the "`Selecting a Device - Manager <&YOCTO_DOCS_DEV_URL;#selecting-dev-manager>`__" section in + + See the ":ref:`selecting-dev-manager`" section in the Yocto Project Development Tasks Manual for information on how to use this variable. - + USE_VT When using - `SysVinit <&YOCTO_DOCS_DEV_URL;#new-recipe-enabling-system-services>`__, + :ref:`SysVinit `, determines whether or not to run a `getty `__ on any virtual terminals in order to enable logging in through those terminals. - + The default value used for ``USE_VT`` is "1" when no default value is specifically set. Typically, you would set ``USE_VT`` to "0" in the machine configuration file for machines that do not have a graphical display attached and therefore do not need virtual terminal functionality. - + USER_CLASSES A list of classes to globally inherit. These classes are used by the OpenEmbedded build system to enable extra features (e.g. ``buildstats``, ``image-mklibs``, and so forth). - - The default list is set in your ``local.conf`` file: USER_CLASSES ?= - "buildstats image-mklibs image-prelink" For more information, see + + The default list is set in your ``local.conf`` file: + :: + + USER_CLASSES ?= "buildstats image-mklibs image-prelink" + + For more information, see ``meta-poky/conf/local.conf.sample`` in the :term:`Source Directory`. - + USERADD_ERROR_DYNAMIC If set to ``error``, forces the OpenEmbedded build system to produce an error if the user identification (``uid``) and group @@ -7713,21 +8648,26 @@ system and gives an overview of their function and contents. listed in :term:`USERADD_UID_TABLES` and :term:`USERADD_GID_TABLES`. If set to ``warn``, a warning will be issued instead. - + The default behavior for the build system is to dynamically apply ``uid`` and ``gid`` values. Consequently, the ``USERADD_ERROR_DYNAMIC`` variable is by default not set. If you plan on using statically assigned ``gid`` and ``uid`` values, you should set the ``USERADD_ERROR_DYNAMIC`` variable in your ``local.conf`` - file as follows: USERADD_ERROR_DYNAMIC = "error" Overriding the + file as follows: + :: + + USERADD_ERROR_DYNAMIC = "error" + + Overriding the default behavior implies you are going to also take steps to set static ``uid`` and ``gid`` values through use of the :term:`USERADDEXTENSION`, :term:`USERADD_UID_TABLES`, and :term:`USERADD_GID_TABLES` variables. - + .. note:: - + There is a difference in behavior between setting USERADD_ERROR_DYNAMIC to @@ -7745,38 +8685,44 @@ system and gives an overview of their function and contents. , it will only report errors for recipes that are actually built. This saves you from having to add static IDs for recipes that you know will never be built. - + USERADD_GID_TABLES Specifies a password file to use for obtaining static group identification (``gid``) values when the OpenEmbedded build system adds a group to the system during package installation. - + When applying static group identification (``gid``) values, the OpenEmbedded build system looks in :term:`BBPATH` for a ``files/group`` file and then applies those ``uid`` values. Set the - variable as follows in your ``local.conf`` file: USERADD_GID_TABLES = - "files/group" - + variable as follows in your ``local.conf`` file: + :: + + + USERADD_GID_TABLES = "files/group" + .. note:: - + Setting the USERADDEXTENSION variable to "useradd-staticids" causes the build system to use static gid values. - + USERADD_PACKAGES When inheriting the :ref:`useradd ` class, this variable specifies the individual packages within the recipe that require users and/or groups to be added. - + You must set this variable if the recipe inherits the class. For example, the following enables adding a user for the main package in - a recipe: USERADD_PACKAGES = "${PN}" - + a recipe: + :: + + USERADD_PACKAGES = "${PN}" + .. note:: - + It follows that if you are going to use the USERADD_PACKAGES variable, you need to set one or more of the @@ -7786,50 +8732,57 @@ system and gives an overview of their function and contents. , or GROUPMEMS_PARAM variables. - + USERADD_PARAM When inheriting the :ref:`useradd ` class, this variable specifies for a package what parameters should pass to the ``useradd`` command if you add a user to the system when the package is installed. - - Here is an example from the ``dbus`` recipe: USERADD_PARAM_${PN} = - "--system --home ${localstatedir}/lib/dbus \\ --no-create-home - --shell /bin/false \\ --user-group messagebus" For information on the + + Here is an example from the ``dbus`` recipe: + :: + + USERADD_PARAM_${PN} = "--system --home ${localstatedir}/lib/dbus \ + --no-create-home --shell /bin/false \ + --user-group messagebus" + + For information on the standard Linux shell command ``useradd``, see http://linux.die.net/man/8/useradd. - + USERADD_UID_TABLES Specifies a password file to use for obtaining static user identification (``uid``) values when the OpenEmbedded build system adds a user to the system during package installation. - + When applying static user identification (``uid``) values, the OpenEmbedded build system looks in :term:`BBPATH` for a ``files/passwd`` file and then applies those ``uid`` values. Set the - variable as follows in your ``local.conf`` file: USERADD_UID_TABLES = - "files/passwd" - + variable as follows in your ``local.conf`` file: + :: + + USERADD_UID_TABLES = "files/passwd" + .. note:: - + Setting the USERADDEXTENSION variable to "useradd-staticids" causes the build system to use static uid values. - + USERADDEXTENSION When set to "useradd-staticids", causes the OpenEmbedded build system to base all user and group additions on a static ``passwd`` and ``group`` files found in :term:`BBPATH`. - + To use static user identification (``uid``) and group identification (``gid``) values, set the variable as follows in your ``local.conf`` file: USERADDEXTENSION = "useradd-staticids" - + .. note:: - + Setting this variable to use static uid and @@ -7837,29 +8790,29 @@ system and gives an overview of their function and contents. values causes the OpenEmbedded build system to employ the useradd-staticids class. - + If you use static ``uid`` and ``gid`` information, you must also specify the ``files/passwd`` and ``files/group`` files by setting the :term:`USERADD_UID_TABLES` and :term:`USERADD_GID_TABLES` variables. Additionally, you should also set the :term:`USERADD_ERROR_DYNAMIC` variable. - + VOLATILE_LOG_DIR Specifies the persistence of the target's ``/var/log`` directory, which is used to house postinstall target log files. - + By default, ``VOLATILE_LOG_DIR`` is set to "yes", which means the file is not persistent. You can override this setting by setting the variable to "no" to make the log directory persistent. - + WARN_QA Specifies the quality assurance checks whose failures are reported as warnings by the OpenEmbedded build system. You set this variable in your distribution configuration file. For a list of the checks you can control with this variable, see the ":ref:`insane.bbclass `" section. - + WKS_FILE_DEPENDS When placed in the recipe that builds your image, this variable lists build-time dependencies. The ``WKS_FILE_DEPENDS`` variable is only @@ -7867,39 +8820,46 @@ system and gives an overview of their function and contents. :term:`IMAGE_FSTYPES` contains entries related to Wic). If your recipe does not create Wic images, the variable has no effect. - + The ``WKS_FILE_DEPENDS`` variable is similar to the :term:`DEPENDS` variable. When you use the variable in your recipe that builds the Wic image, dependencies you list in the ``WIC_FILE_DEPENDS`` variable are added to the ``DEPENDS`` variable. - + With the ``WKS_FILE_DEPENDS`` variable, you have the possibility to specify a list of additional dependencies (e.g. native tools, bootloaders, and so forth), that are required to build Wic images. - Following is an example: WKS_FILE_DEPENDS = "some-native-tool" In the + Following is an example: + :: + + WKS_FILE_DEPENDS = "some-native-tool" + + In the previous example, some-native-tool would be replaced with an actual native tool on which the build would depend. - + WKS_FILE Specifies the location of the Wic kickstart file that is used by the OpenEmbedded build system to create a partitioned image (image\ ``.wic``). For information on how to create a partitioned - image, see the "`Creating Partitioned Images Using - Wic <&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic>`__" + image, see the + ":ref:`dev-manual/dev-manual-common-tasks:creating partitioned images using wic`" section in the Yocto Project Development Tasks Manual. For details on - the kickstart file format, see the "`OpenEmbedded Kickstart - (``.wks``) Reference <#ref-kickstart>`__" Chapter. - + the kickstart file format, see the ":doc:`../ref-manual/ref-kickstart`" Chapter. + WORKDIR The pathname of the work directory in which the OpenEmbedded build system builds a recipe. This directory is located within the :term:`TMPDIR` directory structure and is specific to the recipe being built and the system for which it is being built. - + The ``WORKDIR`` directory is defined as follows: - ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} + :: + + ${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR} + The actual directory depends on several things: - + - TMPDIR : The top-level build output directory - MULTIMACH_TARGET_SYS @@ -7916,21 +8876,24 @@ system and gives an overview of their function and contents. : The recipe version - PR : The recipe revision - + As an example, assume a Source Directory top-level folder name ``poky``, a default Build Directory at ``poky/build``, and a ``qemux86-poky-linux`` machine target system. Furthermore, suppose your recipe is named ``foo_1.3.0-r0.bb``. In this case, the work directory the build system uses to build the package would be as - follows: poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0 - + follows: + :: + + poky/build/tmp/work/qemux86-poky-linux/foo/1.3.0-r0 + XSERVER Specifies the packages that should be installed to provide an X server and drivers for the current machine, assuming your image directly includes ``packagegroup-core-x11-xserver`` or, perhaps indirectly, includes "x11-base" in :term:`IMAGE_FEATURES`. - + The default value of ``XSERVER``, if not specified in the machine configuration, is "xserver-xorg xf86-video-fbdev xf86-input-evdev". diff --git a/documentation/ref-manual/ref-varlocality.rst b/documentation/ref-manual/ref-varlocality.rst index a130945718..a95504b571 100644 --- a/documentation/ref-manual/ref-varlocality.rst +++ b/documentation/ref-manual/ref-varlocality.rst @@ -25,23 +25,23 @@ Distribution (Distro) This section lists variables whose configuration context is the distribution, or distro. -- ``DISTRO`` +- :term:`DISTRO` -- ``DISTRO_NAME`` +- :term:`DISTRO_NAME` -- ``DISTRO_VERSION`` +- :term:`DISTRO_VERSION` -- ``MAINTAINER`` +- :term:`MAINTAINER` -- ``PACKAGE_CLASSES`` +- :term:`PACKAGE_CLASSES` -- ``TARGET_OS`` +- :term:`TARGET_OS` -- ``TARGET_FPU`` +- :term:`TARGET_FPU` -- ``TCMODE`` +- :term:`TCMODE` -- ``TCLIBC`` +- :term:`TCLIBC` .. _ref-varlocality-config-machine: @@ -50,23 +50,23 @@ Machine This section lists variables whose configuration context is the machine. -- ``TARGET_ARCH`` +- :term:`TARGET_ARCH` -- ``SERIAL_CONSOLES`` +- :term:`SERIAL_CONSOLES` -- ``PACKAGE_EXTRA_ARCHS`` +- :term:`PACKAGE_EXTRA_ARCHS` -- ``IMAGE_FSTYPES`` +- :term:`IMAGE_FSTYPES` -- ``MACHINE_FEATURES`` +- :term:`MACHINE_FEATURES` -- ``MACHINE_EXTRA_RDEPENDS`` +- :term:`MACHINE_EXTRA_RDEPENDS` -- ``MACHINE_EXTRA_RRECOMMENDS`` +- :term:`MACHINE_EXTRA_RRECOMMENDS` -- ``MACHINE_ESSENTIAL_EXTRA_RDEPENDS`` +- :term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS` -- ``MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`` +- :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS` .. _ref-varlocality-config-local: @@ -76,23 +76,23 @@ Local This section lists variables whose configuration context is the local configuration through the ``local.conf`` file. -- ``DISTRO`` +- :term:`DISTRO` -- ``MACHINE`` +- :term:`MACHINE` -- ``DL_DIR`` +- :term:`DL_DIR` -- ``BBFILES`` +- :term:`BBFILES` -- ``EXTRA_IMAGE_FEATURES`` +- :term:`EXTRA_IMAGE_FEATURES` -- ``PACKAGE_CLASSES`` +- :term:`PACKAGE_CLASSES` -- ``BB_NUMBER_THREADS`` +- :term:`BB_NUMBER_THREADS` -- ``BBINCLUDELOGS`` +- :term:`BBINCLUDELOGS` -- ``ENABLE_BINARY_LOCALE_GENERATION`` +- :term:`ENABLE_BINARY_LOCALE_GENERATION` .. _ref-varlocality-recipes: @@ -109,11 +109,11 @@ Required This section lists variables that are required for recipes. -- ``LICENSE`` +- :term:`LICENSE` -- ``LIC_FILES_CHKSUM`` +- :term:`LIC_FILES_CHKSUM` -- ``SRC_URI`` - used in recipes that fetch local or remote files. +- :term:`SRC_URI` - used in recipes that fetch local or remote files. .. _ref-varlocality-recipe-dependencies: @@ -122,15 +122,15 @@ Dependencies This section lists variables that define recipe dependencies. -- ``DEPENDS`` +- :term:`DEPENDS` -- ``RDEPENDS`` +- :term:`RDEPENDS` -- ``RRECOMMENDS`` +- :term:`RRECOMMENDS` -- ``RCONFLICTS`` +- :term:`RCONFLICTS` -- ``RREPLACES`` +- :term:`RREPLACES` .. _ref-varlocality-recipe-paths: @@ -139,11 +139,11 @@ Paths This section lists variables that define recipe paths. -- ``WORKDIR`` +- :term:`WORKDIR` -- ``S`` +- :term:`S` -- ``FILES`` +- :term:`FILES` .. _ref-varlocality-recipe-build: @@ -153,14 +153,14 @@ Extra Build Information This section lists variables that define extra build information for recipes. -- ``DEFAULT_PREFERENCE`` +- :term:`DEFAULT_PREFERENCE` -- ``EXTRA_OECMAKE`` +- :term:`EXTRA_OECMAKE` -- ``EXTRA_OECONF`` +- :term:`EXTRA_OECONF` -- ``EXTRA_OEMAKE`` +- :term:`EXTRA_OEMAKE` -- ``PACKAGECONFIG_CONFARGS`` +- :term:`PACKAGECONFIG_CONFARGS` -- ``PACKAGES`` +- :term:`PACKAGES` diff --git a/documentation/ref-manual/resources.rst b/documentation/ref-manual/resources.rst index c5ddcca97f..2b82b79102 100644 --- a/documentation/ref-manual/resources.rst +++ b/documentation/ref-manual/resources.rst @@ -23,8 +23,7 @@ The Yocto Project gladly accepts contributions. You can submit changes to the project either by creating and sending pull requests, or by submitting patches through email. For information on how to do both as well as information on how to identify the maintainer for each area of -code, see the "`Submitting a Change to the Yocto -Project <&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change>`__" section in the +code, see the ":ref:`how-to-submit-a-change`" section in the Yocto Project Development Tasks Manual. .. _resources-bugtracker: @@ -48,8 +47,7 @@ A general procedure and guidelines exist for when you use Bugzilla to submit a bug. For information on how to use Bugzilla to submit a bug against the Yocto Project, see the following: -- The "`Submitting a Defect Against the Yocto - Project <&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project>`__" +- The ":ref:`dev-manual/dev-manual-common-tasks:submitting a defect against the yocto project`" section in the Yocto Project Development Tasks Manual. - The Yocto Project :yocto_wiki:`Bugzilla wiki page ` @@ -67,22 +65,22 @@ and announcements. To subscribe to one of the following mailing lists, click on the appropriate URL in the following list and follow the instructions: -- ` <&YOCTO_LISTS_URL;/listinfo/yocto>`__ - General Yocto Project +- https://lists.yoctoproject.org/g/yocto - General Yocto Project discussion mailing list. -- ` <&OE_LISTS_URL;/listinfo/openembedded-core>`__ - Discussion mailing +- https://lists.openembedded.org/g/openembedded-core - Discussion mailing list about OpenEmbedded-Core (the core metadata). -- ` <&OE_LISTS_URL;/listinfo/openembedded-devel>`__ - Discussion +- https://lists.openembedded.org/g/openembedded-devel - Discussion mailing list about OpenEmbedded. -- ` <&OE_LISTS_URL;/listinfo/bitbake-devel>`__ - Discussion mailing +- https://lists.openembedded.org/g/bitbake-devel - Discussion mailing list about the :term:`BitBake` build tool. -- ` <&YOCTO_LISTS_URL;/listinfo/poky>`__ - Discussion mailing list +- https://lists.yoctoproject.org/g/poky - Discussion mailing list about `Poky <#poky>`__. -- ` <&YOCTO_LISTS_URL;/listinfo/yocto-announce>`__ - Mailing list to +- https://lists.yoctoproject.org/g/yocto-announce - Mailing list to receive official Yocto Project release and milestone announcements. For more Yocto Project-related mailing lists, see the @@ -115,7 +113,7 @@ Here is a list of resources you might find helpful: planning, release engineering, QA & automation, a reference site map, and other resources related to the Yocto Project. -- `OpenEmbedded <&OE_HOME_URL;>`__\ *:* The build system used by the +- `OpenEmbedded `__\ *:* The build system used by the Yocto Project. This project is the upstream, generic, embedded distribution from which the Yocto Project derives its build system (Poky) and to which it contributes. @@ -127,53 +125,47 @@ Here is a list of resources you might find helpful: guide to the BitBake tool. If you want information on BitBake, see this manual. -- `Yocto Project Quick Build <&YOCTO_DOCS_BRIEF_URL;>`__\ *:* This +- :doc:`../brief-yoctoprojectqs/brief-yoctoprojectqs` *:* This short document lets you experience building an image using the Yocto Project without having to understand any concepts or details. -- `Yocto Project Overview and Concepts - Manual <&YOCTO_DOCS_OM_URL;>`__\ *:* This manual provides overview +- :doc:`../overview-manual/overview-manual` *:* This manual provides overview and conceptual information about the Yocto Project. -- `Yocto Project Development Tasks - Manual <&YOCTO_DOCS_DEV_URL;>`__\ *:* This manual is a "how-to" guide +- :doc:`../dev-manual/dev-manual` *:* This manual is a "how-to" guide that presents procedures useful to both application and system developers who use the Yocto Project. -- `Yocto Project Application Development and the Extensible Software - Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__\ *manual:* This +- :doc:`../sdk-manual/sdk-manual` *manual :* This guide provides information that lets you get going with the standard or extensible SDK. An SDK, with its cross-development toolchains, allows you to develop projects inside or outside of the Yocto Project environment. -- `Yocto Project Board Support Package (BSP) Developer's - Guide <&YOCTO_DOCS_BSP_URL;>`__\ *:* This guide defines the structure +- :doc:`../bsp-guide/bsp` *:* This guide defines the structure for BSP components. Having a commonly understood structure encourages standardization. -- `Yocto Project Linux Kernel Development - Manual <&YOCTO_DOCS_KERNEL_DEV_URL;>`__\ *:* This manual describes +- :doc:`../kernel-dev/kernel-dev` *:* This manual describes how to work with Linux Yocto kernels as well as provides a bit of conceptual information on the construction of the Yocto Linux kernel tree. -- `Yocto Project Reference Manual <&YOCTO_DOCS_REF_URL;>`__\ *:* This +- :doc:`../ref-manual/ref-manual` *:* This manual provides reference material such as variable, task, and class descriptions. -- `Yocto Project Mega-Manual <&YOCTO_DOCS_MM_URL;>`__\ *:* This manual +- `Yocto Project Mega-Manual `__\ *:* This manual is simply a single HTML file comprised of the bulk of the Yocto Project manuals. The Mega-Manual primarily exists as a vehicle by which you can easily search for phrases and terms used in the Yocto Project documentation set. -- `Yocto Project Profiling and Tracing - Manual <&YOCTO_DOCS_PROF_URL;>`__\ *:* This manual presents a set of +- :doc:`../profile-manual/profile-manual` *:* This manual presents a set of common and generally useful tracing and profiling schemes along with their applications (as appropriate) to each tool. -- `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__\ *:* This manual +- :doc:`../toaster-manual/toaster-manual` *:* This manual introduces and describes how to set up and use Toaster. Toaster is an Application Programming Interface (API) and web-based interface to the :term:`OpenEmbedded Build System`, which uses @@ -188,7 +180,7 @@ Here is a list of resources you might find helpful: the Yocto Project website and click on the "RELEASE INFORMATION" link for the appropriate release. -- `Bugzilla <&YOCTO_BUGZILLA_URL;>`__\ *:* The bug tracking application +- `Bugzilla `__\ *:* The bug tracking application the Yocto Project uses. If you find problems with the Yocto Project, you should report them using this application.