[PATCH 04/10] doc: Quote all long form options using double ticks in tools/buildman/buildman.rst

[Adriano Carvalho]

Otherwise, the two dashes are rendered as just one.

Signed-off-by: Adriano Carvalho <adrianocarvalho.pt at gmail.com>
---
 tools/buildman/buildman.rst | 50 ++++++++++++++++++-------------------
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/tools/buildman/buildman.rst b/tools/buildman/buildman.rst
index a9d5543a1a4..48938044520 100644
--- a/tools/buildman/buildman.rst
+++ b/tools/buildman/buildman.rst
@@ -100,8 +100,8 @@ threads do not affect the state of your git repository. Any checkouts done
 by the thread affect only the working directory for that thread.
 
 Buildman automatically selects the correct tool chain for each board. You
-must supply suitable tool chains (see --fetch-arch), but buildman takes care
-of selecting the right one.
+must supply suitable tool chains (see ``--fetch-arch``), but buildman takes
+care of selecting the right one.
 
 Buildman generally builds a branch (with the -b flag), and in this case
 builds the upstream commit as well, for comparison. So even if you have one
@@ -153,9 +153,9 @@ You can also use -x to specifically exclude some boards. For example:
 means to build all arm boards except nvidia, freescale and anything ending
 with 'ball'.
 
-For building specific boards you can use the --boards (or --bo) option, which
-takes a comma-separated list of board target names and can be used multiple times
-on the command line:
+For building specific boards you can use the ``--boards`` (or ``--bo``) option,
+which takes a comma-separated list of board target names and can be used
+multiple times on the command line:
 
 .. code-block:: bash
 
@@ -492,7 +492,7 @@ branch with a valid upstream):
    ./tools/buildman/buildman -b <branch> -n
 
 If it can't detect the upstream branch, try checking out the branch, and
-doing something like 'git branch --set-upstream-to upstream/master'
+doing something like ``git branch --set-upstream-to upstream/master``
 or something similar. Buildman will try to guess a suitable upstream branch
 if it can't find one (you will see a message like "Guessing upstream as ...").
 You can also use the -c option to manually specify the number of commits to
@@ -731,17 +731,17 @@ Note that the 'text' region and 'rodata' are split out. You should add the
 two together to get the total read-only size (reported as the first column
 in the output from binutil's 'size' utility).
 
-A useful option is --step which lets you skip some commits. For example
---step 2 will show the image sizes for only every 2nd commit (so it will
+A useful option is ``--step`` which lets you skip some commits. For example
+``--step 2`` will show the image sizes for only every 2nd commit (so it will
 compare the image sizes of the 1st, 3rd, 5th... commits). You can also use
---step 0 which will compare only the first and last commits. This is useful
+``--step 0`` which will compare only the first and last commits. This is useful
 for an overview of how your entire series affects code size. It will build
 only the upstream commit and your final branch commit.
 
 You can also use -d to see a detailed size breakdown for each board. This
 list is sorted in order from largest growth to largest reduction.
 
-It is even possible to go a little further with the -B option (--bloat). This
+It is even possible to go a little further with the -B option (``--bloat``). This
 shows where U-Boot has bloated, breaking the size change down to the function
 level. Example output is below::
 
@@ -924,7 +924,7 @@ a set of (tag, value) pairs.
     This lists the available toolchains. The tag here doesn't matter, but
     make sure it is unique. The value is the path to the toolchain. Buildman
     will look in that path for a file ending in 'gcc'. It will then execute
-    it to check that it is a C compiler, passing only the --version flag to
+    it to check that it is a C compiler, passing only the ``--version`` flag to
     it. If the return code is 0, buildman assumes that it is a valid C
     compiler. It uses the first part of the name as the architecture and
     strips off the last part when setting the CROSS_COMPILE environment
@@ -1005,7 +1005,7 @@ By default, buildman doesn't execute 'make mrproper' prior to building the
 first commit for each board. This reduces the amount of work 'make' does, and
 hence speeds up the build. To force use of 'make mrproper', use -the -m flag.
 This flag will slow down any buildman invocation, since it increases the amount
-of work done on any build. An alternative is to use the --fallback-mrproper
+of work done on any build. An alternative is to use the ``--fallback-mrproper``
 flag, which retries the build with 'make mrproper' only after a build failure.
 
 One possible application of buildman is as part of a continual edit, build,
@@ -1040,7 +1040,7 @@ of the source tree, thus allowing rapid tested evolution of the code::
 
     ./tools/buildman/buildman -Pr tegra
 
-Note also the `--dtc-skip` option which uses the system device-tree compiler to
+Note also the ``--dtc-skip`` option which uses the system device-tree compiler to
 avoid needing to build it for each board. This can save 10-20% of build time.
 An alternative is to set DTC=/path/to/dtc when running buildman.
 
@@ -1076,7 +1076,7 @@ same as 'am335x_evm_usbspl'.
 
 The -K option uses the u-boot.cfg, spl/u-boot-spl.cfg and tpl/u-boot-tpl.cfg
 files which are produced by a build. If all you want is to check the
-configuration you can in fact avoid doing a full build, using --config-only.
+configuration you can in fact avoid doing a full build, using ``--config-only``.
 This tells buildman to configure U-Boot and create the .cfg files, but not
 actually build the source. This is 5-10 times faster than doing a full build.
 
@@ -1090,7 +1090,7 @@ equivalent::
 The former would appear in a header filer and the latter in a defconfig
 file. To achieve this, buildman considers 'y' to be '1' in configuration
 variables. This avoids lots of useless output when converting a CONFIG
-option to Kconfig. To disable this behaviour, use --squash-config-y.
+option to Kconfig. To disable this behaviour, use ``--squash-config-y``.
 
 
 Checking the environment
@@ -1165,7 +1165,7 @@ Link-time optimisation (LTO) is designed to reduce code size by globally
 optimising the U-Boot build. Unfortunately this can dramatically slow down
 builds. This is particularly noticeable when running a lot of builds.
 
-Use the -L (--no-lto) flag to disable LTO.
+Use the -L (``--no-lto``) flag to disable LTO.
 
 .. code-block:: bash
 
@@ -1195,7 +1195,7 @@ each error line. Also, buildman prints information about what it is about to do,
 along with a summary at the end.
 
 When using buildman from an IDE, it is helpful to drop this behaviour. Use the
--I/--ide option for that. You might find -W helpful also so that warnings do
+``-I/--ide`` option for that. You might also find -W helpful so that warnings do
 not cause the build to fail:
 
 .. code-block:: bash
@@ -1287,7 +1287,7 @@ You can use -f to work around that.
 Other options
 -------------
 
-Buildman has various other command-line options. Try --help to see them.
+Buildman has various other command-line options. Try ``--help`` to see them.
 
 To find out what toolchain prefix buildman will use for a build, use the -A
 option.
@@ -1325,11 +1325,11 @@ figure out the root cause of the build failure.
 
 For situations where buildman is invoked from multiple running processes, it is
 sometimes useful to have buildman wait until the others have finished. Use the
---process-limit option for this: --process-limit 1 will allow only one buildman
-to process jobs at a time.
+``--process-limit`` option for this: ``--process-limit 1`` will allow only one
+buildman to process jobs at a time.
 
 To build a particular target, rather than the default U-Boot target, use the
-`--target` option. This is unlikely to be useful unless you are building a
+``--target`` option. This is unlikely to be useful unless you are building a
 single board.
 
 Buildman normally builds out-of-tree, meaning that the source directory is not
@@ -1358,7 +1358,7 @@ Using boards.cfg
 
 This file is no-longer needed by buildman but it is still generated in the
 working directory. This helps avoid a delay on every build, since scanning all
-the Kconfig files takes a few seconds. Use the `-R <filename>` flag to force
+the Kconfig files takes a few seconds. Use the ``-R <filename>`` flag to force
 regeneration of the file - in that case buildman exits after writing the file
 with exit code 2 if there was an error in the maintainer files. To use the
 default filename, use a hyphen, i.e. `-R -`.
@@ -1371,7 +1371,7 @@ Checking maintainers
 --------------------
 
 Sometimes a board is added without a corresponding entry in a MAINTAINERS file.
-Use the `--maintainer-check` option to check this::
+Use the ``--maintainer-check`` option to check this::
 
    $ buildman --maintainer-check
    WARNING: board/mikrotik/crs3xx-98dx3236/MAINTAINERS: missing defconfig ending at line 7
@@ -1379,8 +1379,8 @@ Use the `--maintainer-check` option to check this::
 
 Buildman returns with an exit code of 2 if there are any warnings.
 
-An experimental `--full-check option` also checks for boards which don't have a
-CONFIG_TARGET_xxx where xxx corresponds to their defconfig filename. This is
+An experimental ``--full-check option`` also checks for boards which don't have
+a CONFIG_TARGET_xxx where xxx corresponds to their defconfig filename. This is
 not strictly necessary, but may be useful information.
 
 
-- 
2.48.1