sdk-manual: fix incorrect highlight language for console code-blocks

When unspecified in conf.py via the highlight_language variable (and
highlight variable for code-blocks), the lexer used for literal blocks
is "default" which tries to highlight the block as Python code.

These blocks aren't Python but simple command lines prefixed by a
prompt so let's use the "console" lexer to properly highlight.

(From yocto-docs rev: cb27e3264bcfdeec20d590dfff5cba99051d825e)

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit c6039ce11d638a0b64844480e51d126fcda304b4)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/sdk-manual/appendix-customizing.rst

@@ -189,7 +189,9 @@ the installed SDKs to update the installed SDKs by using the
 #. Build the extensible SDK normally (i.e., use the
    ``bitbake -c populate_sdk_ext`` imagename command).
 
-#. Publish the SDK using the following command::
+#. Publish the SDK using the following command:
+
+   .. code-block:: console
 
       $ oe-publish-sdk some_path/sdk-installer.sh path_to_shared_http_directory
 

documentation/sdk-manual/appendix-obtain.rst

@@ -69,7 +69,9 @@ Follow these steps to locate and hand-install the toolchain:
 
 #. *Run the Installer:* Be sure you have execution privileges and run
    the installer. Here is an example from the ``Downloads``
-   directory::
+   directory:
+
+   .. code-block:: console
 
       $ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-qemux86-64-toolchain-&DISTRO;.sh
 
@@ -106,7 +108,9 @@ 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:
+
+   .. code-block:: console
 
       $ source oe-init-build-env
 
@@ -145,11 +149,15 @@ build the SDK installer. Follow these steps:
 
 #. *Build the SDK Installer:* To build the SDK installer for a standard
    SDK and populate the SDK image, use the following command form. Be
-   sure to replace ``image`` with an image (e.g. "core-image-sato")::
+   sure to replace ``image`` with an image (e.g. "core-image-sato"):
+
+   .. code-block:: console
 
       $ bitbake image -c populate_sdk
 
-   You can do the same for the extensible SDK using this command form::
+   You can do the same for the extensible SDK using this command form:
+
+   .. code-block:: console
 
       $ bitbake image -c populate_sdk_ext
 
@@ -174,7 +182,9 @@ build the SDK installer. Follow these steps:
          libc-staticdev"
 
 #. *Run the Installer:* You can now run the SDK installer from
-   ``tmp/deploy/sdk`` in the :term:`Build Directory`. Here is an example::
+   ``tmp/deploy/sdk`` in the :term:`Build Directory`. Here is an example:
+
+   .. code-block:: console
 
       $ cd poky/build/tmp/deploy/sdk
       $ ./poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
@@ -242,7 +252,9 @@ Follow these steps to extract the root filesystem:
    installed the toolchain (e.g. ``poky_sdk``).
 
    Here is an example based on the toolchain installed in the
-   ":ref:`sdk-manual/appendix-obtain:locating pre-built sdk installers`" section::
+   ":ref:`sdk-manual/appendix-obtain:locating pre-built sdk installers`" section:
+
+   .. code-block:: console
 
       $ source poky_sdk/environment-setup-core2-64-poky-linux
 
@@ -253,7 +265,9 @@ Follow these steps to extract the root filesystem:
    from a previously built root filesystem image that was downloaded
    from the :yocto_dl:`Index of Releases </releases/yocto/&DISTRO_REL_LATEST_TAG;/machines/>`.
    This command extracts the root filesystem into the ``core2-64-sato``
-   directory::
+   directory:
+
+   .. code-block:: console
 
       $ runqemu-extract-sdk ~/Downloads/core-image-sato-sdk-beaglebone-yocto.tar.bz2 ~/beaglebone-sato
 

documentation/sdk-manual/extensible.rst

@@ -71,7 +71,9 @@ Setting up the Extensible SDK environment directly in a Yocto build
 #. Set up all the needed layers and a Yocto :term:`Build Directory`, e.g. a regular Yocto
    build where ``bitbake`` can be executed.
 
-#. Run::
+#. Run:
+
+.. code-block:: console
 
       $ bitbake meta-ide-support
       $ bitbake -c populate_sysroot gtk+3
@@ -144,7 +146,9 @@ 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::
+``~/Downloads/`` and has execution rights:
+
+.. code-block:: console
 
    $ ./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
@@ -194,7 +198,9 @@ begin with the string "``environment-setup``" and include as part of
 their name the tuned target architecture. As an example, the following
 commands set the working directory to where the SDK was installed and
 then source the environment setup script. In this example, the setup
-script is for an IA-based target machine using i586 tuning::
+script is for an IA-based target machine using i586 tuning:
+
+.. code-block:: console
 
    $ cd /home/scottrif/poky_sdk
    $ source environment-setup-core2-64-poky-linux
@@ -202,7 +208,9 @@ script is for an IA-based target machine using i586 tuning::
    Run devtool --help for further details.
 
 When using the environment script directly in a Yocto build, it can
-be run similarly::
+be run similarly:
+
+.. code-block:: console
 
    $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux
 
@@ -1587,7 +1595,9 @@ populated on-demand. Sometimes you must explicitly install extra items
 into the SDK. If you need these extra items, you can first search for
 the items using the ``devtool search`` command. For example, suppose you
 need to link to libGL but you are not sure which recipe provides libGL.
-You can use the following command to find out::
+You can use the following command to find out:
+
+.. code-block:: console
 
    $ devtool search libGL mesa
    A free implementation of the OpenGL API
@@ -1600,7 +1610,9 @@ When using the extensible SDK directly in a Yocto build
 
 In this scenario, the Yocto build tooling, e.g. ``bitbake``
 is directly accessible to build additional items, and it
-can simply be executed directly::
+can simply be executed directly:
+
+.. code-block:: console
 
    $ bitbake curl-native
    # Add newly built native items to native sysroot
@@ -1612,14 +1624,16 @@ can simply be executed directly::
 When using a standalone installer for the Extensible SDK
 --------------------------------------------------------
 
-::
+.. code-block:: console
 
    $ devtool sdk-install mesa
 
 By default, the ``devtool sdk-install`` command assumes
 the item is available in pre-built form from your SDK provider. If the
 item is not available and it is acceptable to build the item from
-source, you can add the "-s" option as follows::
+source, you can add the "-s" option as follows:
+
+.. code-block:: console
 
    $ devtool sdk-install -s mesa
 
@@ -1635,7 +1649,9 @@ If you are working with an installed extensible SDK that gets
 occasionally updated (e.g. a third-party SDK), then you will need to
 manually "pull down" the updates into the installed SDK.
 
-To update your installed SDK, use ``devtool`` as follows::
+To update your installed SDK, use ``devtool`` as follows:
+
+.. code-block:: console
 
    $ devtool sdk-update
 
@@ -1643,7 +1659,9 @@ The previous command assumes your SDK provider has set the default update URL
 for you through the :term:`SDK_UPDATE_URL` variable as described in the
 ":ref:`sdk-manual/appendix-customizing:Providing Updates to the Extensible SDK After Installation`"
 section. If the SDK provider has not set that default URL, you need to
-specify it yourself in the command as follows::
+specify it yourself in the command as follows:
+
+.. code-block:: console
 
    $ devtool sdk-update path_to_update_directory
 

documentation/sdk-manual/using.rst

@@ -100,7 +100,9 @@ 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::
+``~/Downloads/`` and has execution rights:
+
+.. code-block:: console
 
    $ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
    Poky (Yocto Project Reference Distro) SDK installer version &DISTRO;
@@ -140,7 +142,9 @@ begin with the string "``environment-setup``" and include as part of
 their name the tuned target architecture. As an example, the following
 commands set the working directory to where the SDK was installed and
 then source the environment setup script. In this example, the setup
-script is for an IA-based target machine using i586 tuning::
+script is for an IA-based target machine using i586 tuning:
+
+.. code-block:: console
 
    $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 

documentation/sdk-manual/working-projects.rst

@@ -33,7 +33,9 @@ project:
 
 #. *Create a Working Directory and Populate It:* Create a clean
    directory for your project and then make that directory your working
-   location::
+   location:
+
+   .. code-block:: console
 
       $ mkdir $HOME/helloworld
       $ cd $HOME/helloworld
@@ -45,7 +47,9 @@ project:
    respectively.
 
    Use the following command to create an empty README file, which is
-   required by GNU Coding Standards::
+   required by GNU Coding Standards:
+
+   .. code-block:: console
 
       $ touch README
 
@@ -84,17 +88,23 @@ project:
    which is followed by the string "poky-linux". For this example, the
    command sources a script from the default SDK installation directory
    that uses the 32-bit Intel x86 Architecture and the &DISTRO; Yocto
-   Project release::
+   Project release:
+
+   .. code-block:: console
 
       $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 
    Another example is sourcing the environment setup directly in a Yocto
-   build::
+   build:
+
+   .. code-block:: console
 
       $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux
 
 #. *Create the configure Script:* Use the ``autoreconf`` command to
-   generate the ``configure`` script::
+   generate the ``configure`` script:
+
+   .. code-block:: console
 
       $ autoreconf
 
@@ -113,7 +123,9 @@ project:
    the cross-compiler. The
    :term:`CONFIGURE_FLAGS`
    environment variable provides the minimal arguments for GNU
-   configure::
+   configure:
+
+   .. code-block:: console
 
       $ ./configure ${CONFIGURE_FLAGS}
 
@@ -126,12 +138,16 @@ project:
    ``armv5te-poky-linux-gnueabi``. You will notice that the name of the
    script is ``environment-setup-armv5te-poky-linux-gnueabi``. Thus, the
    following command works to update your project and rebuild it using
-   the appropriate cross-toolchain tools::
+   the appropriate cross-toolchain tools:
+
+   .. code-block:: console
 
      $ ./configure --host=armv5te-poky-linux-gnueabi --with-libtool-sysroot=sysroot_dir
 
 #. *Make and Install the Project:* These two commands generate and
-   install the project into the destination directory::
+   install the project into the destination directory:
+
+   .. code-block:: console
 
       $ make
       $ make install DESTDIR=./tmp
@@ -146,13 +162,17 @@ 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:
+
+   .. code-block:: console
 
       $ file ./tmp/usr/local/bin/hello
 
 #. *Execute Your Project:* To execute the project, you would need to run
    it on your target hardware. If your target hardware happens to be
-   your build host, you could run the project as follows::
+   your build host, you could run the project as follows:
+
+   .. code-block:: console
 
       $ ./tmp/usr/local/bin/hello
 
@@ -198,7 +218,9 @@ regarding variable behavior:
 .. note::
 
    Regardless of how you set your variables, if you use the "-e" option
-   with ``make``, the variables from the SDK setup script take precedence::
+   with ``make``, the variables from the SDK setup script take precedence:
+
+   .. code-block:: console
 
       $ make -e target
 
@@ -209,7 +231,9 @@ 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`):
+
+.. code-block:: console
 
    $ echo ${CC}
 
@@ -219,7 +243,9 @@ Running the
 SDK setup script for a 64-bit build host and an i586-tuned target
 architecture for a ``core-image-sato`` image using the current &DISTRO;
 Yocto Project release and then echoing that variable shows the value
-established through the script::
+established through the script:
+
+.. code-block:: console
 
    $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
    $ echo ${CC}
@@ -230,7 +256,9 @@ example:
 
 #. *Create a Working Directory and Populate It:* Create a clean
    directory for your project and then make that directory your working
-   location::
+   location:
+
+   .. code-block:: console
 
       $ mkdir $HOME/helloworld
       $ cd $HOME/helloworld
@@ -276,12 +304,16 @@ example:
    which is followed by the string "poky-linux". For this example, the
    command sources a script from the default SDK installation directory
    that uses the 32-bit Intel x86 Architecture and the &DISTRO_NAME; Yocto
-   Project release::
+   Project release:
+
+   .. code-block:: console
 
       $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
 
    Another example is sourcing the environment setup directly in a Yocto
-   build::
+   build:
+
+   .. code-block:: console
 
       $ source tmp/deploy/images/qemux86-64/environment-setup-core2-64-poky-linux
 
@@ -306,7 +338,9 @@ example:
 #. *Make the Project:* Use the ``make`` command to create the binary
    output file. Because variables are commented out in the Makefile, the
    value used for :term:`CC` is the value set when the SDK environment setup
-   file was run::
+   file was run:
+
+   .. code-block:: console
 
       $ make
       i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c
@@ -319,7 +353,9 @@ 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:
+
+   .. code-block:: console
 
       $ make clean
       rm -rf *.o
@@ -340,7 +376,9 @@ example:
    variable as part of the command line. Go into the Makefile and
    re-insert the comment character so that running ``make`` uses the
    established SDK compiler. However, when you run ``make``, use a
-   command-line argument to set :term:`CC` to "gcc"::
+   command-line argument to set :term:`CC` to "gcc":
+
+   .. code-block:: console
 
       $ make clean
       rm -rf *.o
@@ -364,7 +402,9 @@ example:
    environment variable.
 
    In this last case, edit Makefile again to use the "gcc" compiler but
-   then use the "-e" option on the ``make`` command line::
+   then use the "-e" option on the ``make`` command line:
+
+   .. code-block:: console
 
       $ make clean
       rm -rf *.o
@@ -389,7 +429,9 @@ example:
    Makefile.
 
 #. *Execute Your Project:* To execute the project (i.e. ``target_bin``),
-   use the following command::
+   use the following command:
+
+   .. code-block:: console
 
       $ ./target_bin
       Hello World!