diff --git a/documentation/brief-yoctoprojectqs/index.rst b/documentation/brief-yoctoprojectqs/index.rst index 4adec9714f2f..2dccff16c995 100644 --- a/documentation/brief-yoctoprojectqs/index.rst +++ b/documentation/brief-yoctoprojectqs/index.rst @@ -410,7 +410,9 @@ layer>`: `Synaptics` license. See the :yocto_git:`ipcompliance.md ` document for more information. Add the ``synaptics-killswitch`` value to the :term:`LICENSE_FLAGS_ACCEPTED` - variable, in the ``conf/local.conf`` file of your build directory:: + variable, in the ``conf/local.conf`` file of your build directory: + + .. code-block:: bitbake LICENSE_FLAGS_ACCEPTED = "synaptics-killswitch" diff --git a/documentation/bsp-manual/bsp.rst b/documentation/bsp-manual/bsp.rst index 168d64e6ed5a..030464b74283 100644 --- a/documentation/bsp-manual/bsp.rst +++ b/documentation/bsp-manual/bsp.rst @@ -84,7 +84,9 @@ established after you run the OpenEmbedded build environment setup script (i.e. :ref:`structure-core-script`). Adding the root directory allows the :term:`OpenEmbedded Build System` to recognize the BSP -layer and from it build an image. Here is an example:: +layer and from it build an image. Here is an example: + +.. code-block:: bitbake BBLAYERS ?= " \ /usr/local/src/yocto/meta \ @@ -112,7 +114,9 @@ are known as ":term:`container layers `". An example of this type of layer is OpenEmbedded's :oe_git:`meta-openembedded ` layer. The ``meta-openembedded`` layer contains many ``meta-*`` layers. In cases like this, you need to include the names of the actual layers -you want to work with, such as:: +you want to work with, such as: + +.. code-block:: bitbake BBLAYERS ?= " \ /usr/local/src/yocto/meta \ @@ -603,7 +607,9 @@ For example, many ``tune-*`` files (e.g. ``tune-arm1136jf-s.inc``, To use an include file, you simply include them in the machine configuration file. For example, the Raspberry Pi BSP -``raspberrypi3.conf`` contains the following statement:: +``raspberrypi3.conf`` contains the following statement: + +.. code-block:: bitbake include conf/machine/include/rpi-base.inc @@ -674,7 +680,9 @@ Suppose you are using the ``linux-yocto_6.12.bb`` recipe to build the kernel. In other words, you have selected the kernel in your ``"bsp_root_name".conf`` file by adding :term:`PREFERRED_PROVIDER` and :term:`PREFERRED_VERSION` -statements as follows:: +statements as follows: + +.. code-block:: bitbake PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" PREFERRED_VERSION_linux-yocto ?= "6.12%" @@ -1027,7 +1035,9 @@ BSP-specific configuration file named ``interfaces`` to the also supports several other machines: #. Edit the ``init-ifupdown_1.0.bbappend`` file so that it contains the - following:: + following: + + .. code-block:: bitbake FILESEXTRAPATHS:prepend := "${THISDIR}/files:" @@ -1383,7 +1393,9 @@ BSP Kernel Recipe Example ------------------------- The kernel recipe used to build the kernel image for the BeagleBone -device was established in the machine configuration:: +device was established in the machine configuration: + +.. code-block:: bitbake PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto" PREFERRED_VERSION_linux-yocto ?= "6.18%" @@ -1394,7 +1406,9 @@ metadata used to build the kernel. In this case, a kernel append file kernel recipe (i.e. ``linux-yocto_6.18.bb``), which is located in :oe_git:`/openembedded-core/tree/meta/recipes-kernel/linux`. -The contents of the append file are:: +The contents of the append file are: + +.. code-block:: bitbake COMPATIBLE_MACHINE:genericarm64 = "genericarm64" COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto" diff --git a/documentation/contributor-guide/recipe-style-guide.rst b/documentation/contributor-guide/recipe-style-guide.rst index 84c6bb14e8b0..7cd3385787ee 100644 --- a/documentation/contributor-guide/recipe-style-guide.rst +++ b/documentation/contributor-guide/recipe-style-guide.rst @@ -48,7 +48,9 @@ Debian policy closely. When a recipe references a git revision that does not correspond to a released version of software (e.g. is not a tagged version), the :term:`PV` variable should include the sign ``+``, so :term:`bitbake` automatically includes package -version information during the packaging phase:: +version information during the packaging phase: + +.. code-block:: bitbake PV = "+git" @@ -95,13 +97,17 @@ Variable Formatting - When splitting a long variable over multiple lines, all continuation lines should be indented (with spaces) to align with the start of the quote on the - first line:: + first line: + + .. code-block:: bitbake FOO = "this line is \ long \ " - Instead of:: + Instead of: + + .. code-block:: bitbake FOO = "this line is \ long \ @@ -190,7 +196,9 @@ used tasks this would be: Custom tasks should be sorted similarly. -Package specific variables are typically grouped together, e.g.:: +Package specific variables are typically grouped together, e.g.: + +.. code-block:: bitbake RDEPENDS:${PN} = "foo" RDEPENDS:${PN}-libs = "bar" @@ -211,7 +219,9 @@ Recipes need to define both the :term:`LICENSE` and include ``COPYING``, :term:`LICENSE`, and ``README`` files. You could also find the information near the top of a source file. For example, given a piece of software licensed under the GNU General Public - License version 2, you would set :term:`LICENSE` as follows:: + License version 2, you would set :term:`LICENSE` as follows: + + .. code-block:: bitbake LICENSE = "GPL-2.0-only" @@ -255,7 +265,9 @@ Recipes need to define both the :term:`LICENSE` and See the ":ref:`dev-manual/new-recipe:fetching code`" section for additional information. - Here is an example that assumes the software has a ``COPYING`` file:: + Here is an example that assumes the software has a ``COPYING`` file: + + .. code-block:: bitbake LIC_FILES_CHKSUM = "file://COPYING;md5=xxx" diff --git a/documentation/profile-manual/intro.rst b/documentation/profile-manual/intro.rst index 31791255246e..24bbc952c9bd 100644 --- a/documentation/profile-manual/intro.rst +++ b/documentation/profile-manual/intro.rst @@ -41,7 +41,9 @@ an ``sdk`` image, perhaps one of:: $ bitbake core-image-rt-sdk Alternatively, you can add ``tools-profile`` to the :term:`EXTRA_IMAGE_FEATURES` line in -your ``local.conf`` file:: +your ``local.conf`` file: + +.. code-block:: bitbake EXTRA_IMAGE_FEATURES:append = " tools-profile" @@ -57,7 +59,9 @@ the tracing and profiling tools will be included in non-sdk images as well e.g.: You can prevent that by setting the :term:`INHIBIT_PACKAGE_STRIP` - variable to "1" in your ``local.conf`` when you build the image:: + variable to "1" in your ``local.conf`` when you build the image: + + .. code-block:: bitbake INHIBIT_PACKAGE_STRIP = "1" @@ -67,11 +71,15 @@ If you've already built a stripped image, you can generate debug packages (xxx-dbg) which you can manually install as needed. To generate debug info for packages, you can add ``dbg-pkgs`` to -:term:`EXTRA_IMAGE_FEATURES` in ``local.conf``. For example:: +:term:`EXTRA_IMAGE_FEATURES` in ``local.conf``. For example: + +.. code-block:: bitbake EXTRA_IMAGE_FEATURES:append = " dbg-pkgs" Additionally, in order to generate the right type of debug info, we also need to -set :term:`PACKAGE_DEBUG_SPLIT_STYLE` in the ``local.conf`` file:: +set :term:`PACKAGE_DEBUG_SPLIT_STYLE` in the ``local.conf`` file: + +.. code-block:: bitbake PACKAGE_DEBUG_SPLIT_STYLE = 'debug-file-directory'