@@ -327,8 +327,7 @@ BitBake has determined by doing the following:
In the output of the above command, you will find a line like the
following, which lists all the (inferred) variable dependencies for
the task. This list also includes indirect dependencies from
- variables depending on other variables, recursively.
- ::
+ variables depending on other variables, recursively::
Task dependencies: ['PV', 'SRCREV', 'SRC_URI', 'SRC_URI[md5sum]', 'SRC_URI[sha256sum]', 'base_do_fetch']
@@ -641,8 +640,7 @@ The syntax you use for recipes written in Bash is similar to that of
recipes written in Python described in the previous section.
Following is an example written in Bash. The code logs the progress of
-the ``do_my_function`` function.
-::
+the ``do_my_function`` function::
do_my_function() {
bbdebug 2 "Running do_my_function"
@@ -71,8 +71,7 @@ Disabling the Tool
To disable the error reporting feature, simply remove or comment out the
following statement from the end of your ``local.conf`` file in your
-:term:`Build Directory`.
-::
+:term:`Build Directory`::
INHERIT += "report-error"
@@ -154,8 +154,7 @@ or characters. A partial string will match any license that contains the
given string as the first portion of its license. For example, the
following value will also match both of the packages
previously mentioned as well as any other packages that have licenses
-starting with "commercial" or "license".
-::
+starting with "commercial" or "license"::
LICENSE_FLAGS_ACCEPTED = "commercial license"
@@ -109,8 +109,7 @@ Following are some syntax examples:
- Use this syntax to generate a recipe using code that
you extract from source. The extracted code is placed in its own layer
- defined by :term:`EXTERNALSRC`.
- ::
+ defined by :term:`EXTERNALSRC`::
recipetool create -o OUTFILE -x EXTERNALSRC source
@@ -147,8 +146,7 @@ get started. Here are some points on both methods:
- *Use and modify the following skeleton recipe:* If for some reason
you do not want to use ``recipetool`` and you cannot find an existing
recipe that is close to meeting your needs, you can use the following
- structure to provide the fundamental areas of a new recipe.
- ::
+ structure to provide the fundamental areas of a new recipe::
DESCRIPTION = ""
HOMEPAGE = ""
@@ -347,9 +345,7 @@ paste them into your recipe and then run the build again to continue.
This final example is a bit more complicated and is from the
``meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb`` recipe. The
example's :term:`SRC_URI` statement identifies multiple files as the source
-files for the recipe: a tarball, a patch file, a desktop file, and an
-icon.
-::
+files for the recipe: a tarball, a patch file, a desktop file, and an icon::
SRC_URI = "http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-${PV}.tar.bz2 \
file://xwc.patch \
@@ -1196,8 +1192,7 @@ under ``files``) requires a recipe that has the file listed in the
:ref:`ref-tasks-compile` and :ref:`ref-tasks-install` tasks. The :term:`S` variable defines the
directory containing the source code, which is set to
:term:`WORKDIR` in this case --- the
-directory BitBake uses for the build.
-::
+directory BitBake uses for the build::
SUMMARY = "Simple helloworld application"
SECTION = "examples"
@@ -1233,8 +1228,7 @@ which contains the definitions of all the steps needed to build an
Autotool-based application. The result of the build is automatically
packaged. And, if the application uses NLS for localization, packages
with local information are generated (one package per language).
-Following is one example: (``hello_2.3.bb``)
-::
+Following is one example: (``hello_2.3.bb``)::
SUMMARY = "GNU Helloworld application"
SECTION = "examples"
@@ -103,7 +103,9 @@ available. Follow these general steps to run QEMU:
automatically finds the ``bzImage-qemux86-64.bin`` image file and
the ``core-image-minimal-qemux86-64-20200218002850.rootfs.ext4``
(assuming the current build created a ``core-image-minimal``
- image).
+ image)::
+
+ $ runqemu qemux86-64
.. note::
@@ -111,14 +113,9 @@ available. Follow these general steps to run QEMU:
and uses the most recently built image according to the
timestamp.
- ::
-
- $ runqemu qemux86-64
-
- This example produces the exact same results as the previous
example. This command, however, specifically provides the image
- and root filesystem type.
- ::
+ and root filesystem type::
$ runqemu qemux86-64 core-image-minimal ext4
@@ -127,23 +124,20 @@ available. Follow these general steps to run QEMU:
variable ``FSTYPE`` to ``cpio.gz``. Also, for audio to be enabled,
an appropriate driver must be installed (see the ``audio`` option
in :ref:`dev-manual/qemu:\`\`runqemu\`\` command-line options`
- for more information).
- ::
+ for more information)::
$ runqemu qemux86-64 ramfs audio
- This example does not provide enough information for QEMU to
launch. While the command does provide a root filesystem type, it
- must also minimally provide a `MACHINE`, `KERNEL`, or `VM` option.
- ::
+ must also minimally provide a `MACHINE`, `KERNEL`, or `VM` option::
$ runqemu ext4
- This example specifies to boot a virtual machine image
(``.wic.vmdk`` file). From the ``.wic.vmdk``, ``runqemu``
determines the QEMU architecture (`MACHINE`) to be "qemux86-64" and
- the root filesystem type to be "vmdk".
- ::
+ the root filesystem type to be "vmdk"::
$ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86-64.wic.vmdk
@@ -67,8 +67,7 @@ Follow these general steps:
7. *Generate the Patch:* Once your changes work as expected, you need to
use Quilt to generate the final patch that contains all your
- modifications.
- ::
+ modifications::
$ quilt refresh
@@ -578,8 +578,7 @@ data:
Following is an example JSON file that handles test "foo" installing
package "bar" and test "foobar" installing packages "foo" and "bar".
-Once the test is complete, the packages are removed from the DUT.
-::
+Once the test is complete, the packages are removed from the DUT::
{
"foo": {
@@ -260,14 +260,7 @@ your build configuration (i.e. ``${BUILDDIR}/conf/bblayers.conf``)::
For this example, assume that the ``nano.bb`` recipe that
is upstream has a 2.9.3 version number. However, the version in the
local repository is 2.7.4. The following command from your build
-directory automatically upgrades the recipe for you:
-
-.. note::
-
- Using the ``-V`` option is not necessary. Omitting the version number causes
- ``devtool upgrade`` to upgrade the recipe to the most recent version.
-
-::
+directory automatically upgrades the recipe for you::
$ devtool upgrade nano -V 2.9.3
NOTE: Starting bitbake server...
@@ -286,6 +279,11 @@ directory automatically upgrades the recipe for you:
NOTE: Upgraded source extracted to /home/scottrif/poky/build/workspace/sources/nano
NOTE: New recipe is /home/scottrif/poky/build/workspace/recipes/nano/nano_2.9.3.bb
+.. note::
+
+ Using the ``-V`` option is not necessary. Omitting the version number causes
+ ``devtool upgrade`` to upgrade the recipe to the most recent version.
+
Continuing with this example, you can use ``devtool build`` to build the
newly upgraded recipe::
@@ -539,8 +539,7 @@ will need to boot from ``sdb`` instead of ``sda``, which is what the
The example begins by making a copy of the ``directdisk-gpt.wks`` file
in the ``scripts/lib/image/canned-wks`` directory and then by changing
-the lines that specify the target disk from which to boot.
-::
+the lines that specify the target disk from which to boot::
$ cp /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \
/home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
@@ -557,8 +556,7 @@ Once the lines are changed, the
example generates the ``directdisksdb-gpt`` image. The command points
the process at the ``core-image-minimal`` artifacts for the Next Unit of
Computing (nuc) :term:`MACHINE` the
-``local.conf``.
-::
+``local.conf``::
$ wic create directdisksdb-gpt -e core-image-minimal
INFO: Building wic-tools...
@@ -566,15 +566,7 @@ Example
Many real-world examples are more complex. Like any other ``.scc`` file,
BSP descriptions can aggregate features. Consider the Minnow BSP
definition given the ``linux-yocto-4.4`` branch of the
-``yocto-kernel-cache`` (i.e.
-``yocto-kernel-cache/bsp/minnow/minnow.scc``):
-
-.. note::
-
- Although the Minnow Board BSP is unused, the Metadata remains and is
- being used here just as an example.
-
-::
+``yocto-kernel-cache`` (i.e. ``yocto-kernel-cache/bsp/minnow/minnow.scc``)::
include cfg/x86.scc
include features/eg20t/eg20t.scc
@@ -597,6 +589,11 @@ definition given the ``linux-yocto-4.4`` branch of the
kconf hardware minnow.cfg
kconf hardware minnow-dev.cfg
+.. note::
+
+ Although the Minnow Board BSP is unused, the Metadata remains and is
+ being used here just as an example.
+
The ``minnow.scc`` description file includes a hardware configuration
fragment (``minnow.cfg``) specific to the Minnow BSP as well as several
more general configuration fragments and features enabling hardware
@@ -166,8 +166,7 @@ section:
checked out for ``poky`` is the Yocto Project &DISTRO_NAME; branch. If
you need to checkout out the &DISTRO_NAME; branch, see the
":ref:`dev-manual/start:checking out by branch in poky`"
- section in the Yocto Project Development Tasks Manual.
- ::
+ section in the Yocto Project Development Tasks Manual::
$ cd poky
$ git branch
@@ -244,16 +243,7 @@ section:
``standard/base`` branch.
The following commands show how to create a local copy of the
- ``linux-yocto-4.12`` kernel and be in the ``standard/base`` branch.
-
- .. note::
-
- The ``linux-yocto-4.12`` kernel can be used with the Yocto Project 2.4
- release and forward.
- You cannot use the ``linux-yocto-4.12`` kernel with releases prior to
- Yocto Project 2.4.
-
- ::
+ ``linux-yocto-4.12`` kernel and be in the ``standard/base`` branch::
$ cd ~
$ git clone git://git.yoctoproject.org/linux-yocto-4.12 --branch standard/base
@@ -265,6 +255,13 @@ section:
Resolving deltas: 100% (5152604/5152604), done. Checking connectivity... done.
Checking out files: 100% (59846/59846), done.
+ .. note::
+
+ The ``linux-yocto-4.12`` kernel can be used with the Yocto Project 2.4
+ release and forward.
+ You cannot use the ``linux-yocto-4.12`` kernel with releases prior to
+ Yocto Project 2.4.
+
6. *Create a Local Copy of the Kernel Cache Git Repository:* For
simplicity, it is recommended that you create your copy of the kernel
cache Git repository outside of the
@@ -428,8 +425,7 @@ As an example, consider the following append file used by the BSPs in
Here are the contents of this file. Be aware that the actual commit ID
strings in this example listing might be different than the actual
-strings in the file from the ``meta-yocto-bsp`` layer upstream.
-::
+strings in the file from the ``meta-yocto-bsp`` layer upstream::
KBRANCH:genericx86 = "standard/base"
KBRANCH:genericx86-64 = "standard/base"
@@ -490,8 +486,7 @@ For example, suppose you had some configuration options in a file called
``network_configs.cfg``. You can place that file inside a directory
named ``linux-yocto`` and then add a :term:`SRC_URI` statement such as the
following to the append file. When the OpenEmbedded build system builds
-the kernel, the configuration options are picked up and applied.
-::
+the kernel, the configuration options are picked up and applied::
SRC_URI += "file://network_configs.cfg"
@@ -766,7 +761,10 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
4. *Create the Image With the New Kernel:* Use the
``devtool build-image`` command to create a new image that has the
- new kernel.
+ new kernel::
+
+ $ cd ~
+ $ devtool build-image core-image-minimal
.. note::
@@ -776,11 +774,6 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
:yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </TipsAndTricks/KernelDevelopmentWithEsdk>`
Wiki Page.
- ::
-
- $ cd ~
- $ devtool build-image core-image-minimal
-
5. *Test the New Image:* For this example, you can run the new image
using QEMU to verify your changes:
@@ -812,8 +805,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
7. *Export the Patches and Create an Append File:* To export your
commits as patches and create a ``.bbappend`` file, use the following
- command. This example uses the previously established layer named ``meta-mylayer``.
- ::
+ command. This example uses the previously established layer named ``meta-mylayer``::
$ devtool finish linux-yocto ~/meta-mylayer
@@ -1760,8 +1752,7 @@ Here is an example that looks at what has changed in the ``emenlow``
branch of the ``linux-yocto-3.19`` kernel. The lower commit range is the
commit associated with the ``standard/base`` branch, while the upper
commit range is the commit associated with the ``standard/emenlow``
-branch.
-::
+branch::
$ git whatchanged origin/standard/base..origin/standard/emenlow
@@ -184,13 +184,7 @@ 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``:
-
-.. note::
-
- "QB" means "QEMU Boot".
-
-::
+such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``::
QB_SYSTEM_NAME: QEMU name (e.g. "qemu-system-i386")
QB_OPT_APPEND: Options to append to QEMU (e.g. "-show-cursor")
@@ -223,6 +217,10 @@ such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``:
To use ``runqemu``, set :term:`IMAGE_CLASSES` as
follows and run ``runqemu``:
+.. note::
+
+ "QB" means "QEMU Boot".
+
.. note::
For command-line syntax, use ``runqemu help``.
@@ -385,9 +385,7 @@ want to use it because the dependency on ``cdebconf`` is not easily
satisfied. Maintainers can explicit the reason that is shown by adding
the :term:`RECIPE_NO_UPDATE_REASON` variable to the corresponding recipe.
See :yocto_git:`base-passwd.bb </poky/tree/meta/recipes-core/base-passwd/base-passwd_3.5.29.bb>`
-for an example.
-
-::
+for an example::
$ devtool check-upgrade-status
...
@@ -555,8 +553,7 @@ 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
":ref:`devtool deploy-target <ref-manual/devtool-reference:deploying your software on the target machine>`"
-command.
-::
+command::
$ devtool undeploy-target recipe target
@@ -250,8 +250,7 @@ system and gives an overview of their function and contents.
Azure Storage Shared Access Signature, when using the
:ref:`Azure Storage fetcher (az://) <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`
This variable can be defined to be used by the fetcher to authenticate
- and gain access to non-public artifacts.
- ::
+ and gain access to non-public artifacts::
AZ_SAS = ""se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>""
@@ -324,8 +323,7 @@ system and gives an overview of their function and contents.
- There is limited support for wildcard matching against the beginning of
host names. For example, the following setting matches
- ``git.gnu.org``, ``ftp.gnu.org``, and ``foo.git.gnu.org``.
- ::
+ ``git.gnu.org``, ``ftp.gnu.org``, and ``foo.git.gnu.org``::
BB_ALLOWED_NETWORKS = "*.gnu.org"
@@ -529,8 +527,7 @@ system and gives an overview of their function and contents.
For performance reasons, creating and placing tarballs of these
repositories is not the default action by the OpenEmbedded build
- system.
- ::
+ system::
BB_GENERATE_MIRROR_TARBALLS = "1"
@@ -3020,8 +3017,7 @@ system and gives an overview of their function and contents.
:term:`IMAGE_LINGUAS` appropriately.
You can set :term:`GLIBC_GENERATE_LOCALES` in your ``local.conf`` file.
- By default, all locales are generated.
- ::
+ By default, all locales are generated::
GLIBC_GENERATE_LOCALES = "en_GB.UTF-8 en_US.UTF-8"
@@ -5889,8 +5885,7 @@ system and gives an overview of their function and contents.
Consider the following :term:`PACKAGECONFIG` block taken from the
``librsvg`` recipe. In this example the feature is ``gtk``, which has
- three arguments that determine the feature's behavior.
- ::
+ three arguments that determine the feature's behavior::
PACKAGECONFIG[gtk] = "--with-gtk3,--without-gtk3,gtk+3"
@@ -7821,8 +7816,7 @@ system and gives an overview of their function and contents.
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.
- ::
+ correct path within the directory structure::
SSTATE_MIRRORS ?= "\
file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \
@@ -8616,8 +8610,7 @@ system and gives an overview of their function and contents.
Alternatively, you can
provide the "auto" option to have all applicable tests run against
- the image.
- ::
+ the image::
TEST_SUITES:append = " auto"
@@ -9115,8 +9108,7 @@ system and gives an overview of their function and contents.
releases are not identified by Git tags, set :term:`UPSTREAM_CHECK_COMMITS`
to ``1`` in the recipe, and the OpenEmbedded build system
will compare the latest commit with the one currently specified
- by the recipe (:term:`SRCREV`).
- ::
+ by the recipe (:term:`SRCREV`)::
UPSTREAM_CHECK_COMMITS = "1"
@@ -9129,8 +9121,7 @@ system and gives an overview of their function and contents.
You can use the :term:`UPSTREAM_CHECK_GITTAGREGEX` variable to provide a
regular expression to filter only the relevant tags should the
- default filter not work correctly.
- ::
+ default filter not work correctly::
UPSTREAM_CHECK_GITTAGREGEX = "git_tag_regex"
@@ -9138,8 +9129,7 @@ system and gives an overview of their function and contents.
Use the :term:`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`.
- ::
+ :term:`UPSTREAM_CHECK_URI`::
UPSTREAM_CHECK_REGEX = "package_regex"
@@ -9150,8 +9140,7 @@ 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 :term:`UPSTREAM_CHECK_URI` to provide a different URI that
- contains the link to the latest tarball.
- ::
+ contains the link to the latest tarball::
UPSTREAM_CHECK_URI = "recipe_url"
@@ -9162,8 +9151,7 @@ system and gives an overview of their function and contents.
:term:`UPSTREAM_CHECK_GITTAGREGEX` and :term:`UPSTREAM_CHECK_COMMITS` variables in
the recipe allows to determine what the latest upstream version is,
you can set :term:`UPSTREAM_VERSION_UNKNOWN` to ``1`` in the recipe
- to acknowledge that the check cannot be performed.
- ::
+ to acknowledge that the check cannot be performed::
UPSTREAM_VERSION_UNKNOWN = "1"
@@ -111,8 +111,7 @@ build the SDK installer. Follow these steps:
the Source Directory (i.e. ``poky``), run the
:ref:`structure-core-script` environment
setup script to define the OpenEmbedded build environment on your
- build host.
- ::
+ build host::
$ source oe-init-build-env
@@ -138,16 +138,7 @@ must be writable for whichever users need to use the SDK.
The following command shows how to run the installer given a toolchain
tarball for a 64-bit x86 development host system and a 64-bit x86 target
architecture. The example assumes the SDK installer is located in
-``~/Downloads/`` and has execution rights.
-
-.. note::
-
- If you do not have write permissions for the directory into which you
- are installing the SDK, the installer notifies you and exits. For
- that case, set up the proper permissions in the directory and run the
- installer again.
-
-::
+``~/Downloads/`` and has execution rights::
$ ./Downloads/poky-glibc-x86_64-core-image-minimal-core2-64-toolchain-ext-2.5.sh
Poky (Yocto Project Reference Distro) Extensible SDK installer version 2.5
@@ -168,6 +159,13 @@ architecture. The example assumes the SDK installer is located in
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
$ . /home/scottrif/poky_sdk/environment-setup-core2-64-poky-linux
+.. note::
+
+ If you do not have write permissions for the directory into which you
+ are installing the SDK, the installer notifies you and exits. For
+ that case, set up the proper permissions in the directory and run the
+ installer again.
+
Running the Extensible SDK Environment Setup Script
===================================================
@@ -406,8 +404,7 @@ command:
creates any patches corresponding to commits in the local Git
repository, moves the new recipe to a more permanent layer, and then
resets the recipe so that the recipe is built normally rather than
- from the workspace.
- ::
+ from the workspace::
$ devtool finish recipe layer
@@ -605,8 +602,7 @@ command:
repository, updates the recipe to point to them (or creates a
``.bbappend`` file to do so, depending on the specified destination
layer), and then resets the recipe so that the recipe is built
- normally rather than from the workspace.
- ::
+ normally rather than from the workspace::
$ devtool finish recipe layer
@@ -780,8 +776,7 @@ The following diagram shows the common development flow used with the
If you specify a destination layer that is the same as the original
source, then the old version of the recipe and associated files are
- removed prior to adding the new version.
- ::
+ removed prior to adding the new version::
$ devtool finish recipe layer
@@ -52,8 +52,7 @@ libraries appropriate for developing against the corresponding image.
The names of the tarball installer scripts are such that a string
representing the host system appears first in the filename and then is
-immediately followed by a string representing the target architecture.
-::
+immediately followed by a string representing the target architecture::
poky-glibc-host_system-image_type-arch-toolchain-release_version.sh
@@ -97,16 +96,7 @@ must be writable for whichever users need to use the SDK.
The following command shows how to run the installer given a toolchain
tarball for a 64-bit x86 development host system and a 64-bit x86 target
architecture. The example assumes the SDK installer is located in
-``~/Downloads/`` and has execution rights.
-
-.. note::
-
- If you do not have write permissions for the directory into which you
- are installing the SDK, the installer notifies you and exits. For
- that case, set up the proper permissions in the directory and run the
- installer again.
-
-::
+``~/Downloads/`` and has execution rights::
$ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
Poky (Yocto Project Reference Distro) SDK installer version &DISTRO;
@@ -119,6 +109,13 @@ architecture. The example assumes the SDK installer is located in
Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
$ . /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+.. note::
+
+ If you do not have write permissions for the directory into which you
+ are installing the SDK, the installer notifies you and exits. For
+ that case, set up the proper permissions in the directory and run the
+ installer again.
+
Again, reference the
":ref:`sdk-manual/appendix-obtain:installed standard sdk directory structure`"
section for more details on the resulting directory structure of the installed
@@ -33,8 +33,7 @@ project:
1. *Create a Working Directory and Populate It:* Create a clean
directory for your project and then make that directory your working
- location.
- ::
+ location::
$ mkdir $HOME/helloworld
$ cd $HOME/helloworld
@@ -146,8 +145,7 @@ project:
This next command is a simple way to verify the installation of your
project. Running the command prints the architecture on which the
binary file can run. This architecture should be the same
- architecture that the installed cross-toolchain supports.
- ::
+ architecture that the installed cross-toolchain supports::
$ file ./tmp/usr/local/bin/hello
@@ -210,8 +208,7 @@ demonstrates these variable behaviors.
In a new shell environment variables are not established for the SDK
until you run the setup script. For example, the following commands show
a null value for the compiler variable (i.e.
-:term:`CC`).
-::
+:term:`CC`)::
$ echo ${CC}
@@ -232,8 +229,7 @@ example:
1. *Create a Working Directory and Populate It:* Create a clean
directory for your project and then make that directory your working
- location.
- ::
+ location::
$ mkdir $HOME/helloworld
$ cd $HOME/helloworld
@@ -322,8 +318,7 @@ example:
You can override the :term:`CC` environment variable with the same
variable as set from the Makefile by uncommenting the line in the
- Makefile and running ``make`` again.
- ::
+ Makefile and running ``make`` again::
$ make clean
rm -rf *.o