Fix many MarkDown issues in {NOTES*,README*,HACKING,LICENSE}.md files

Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/12109)

2 files changed, 178 insertions, 180 deletions

diff --git a/Configurations/README-design.md b/Configurations/README-design.md
index b79d0b2e49..ef21a3ae28 100644
--- a/Configurations/README-design.md
+++ b/Configurations/README-design.md
@@ -4,17 +4,17 @@ Design document for the unified scheme data
 How are things connected?
 -------------------------
 
-The unified scheme takes all its data from the build.info files seen
+The unified scheme takes all its data from the `build.info` files seen
 throughout the source tree.  These files hold the minimum information
 needed to build end product files from diverse sources.  See the
-section on build.info files below.
+section on `build.info` files below.
 
-From the information in build.info files, Configure builds up an
-information database as a hash table called %unified_info, which is
+From the information in `build.info` files, `Configure` builds up an
+information database as a hash table called `%unified_info`, which is
 stored in configdata.pm, found at the top of the build tree (which may
 or may not be the same as the source tree).
 
-Configurations/common.tmpl uses the data from %unified_info to
+[`Configurations/common.tmpl`](common.tmpl) uses the data from `%unified_info` to
 generate the rules for building end product files as well as
 intermediary files with the help of a few functions found in the
 build-file templates.  See the section on build-file templates further
@@ -23,36 +23,35 @@ down for more information.
 build.info files
 ----------------
 
-As mentioned earlier, build.info files are meant to hold the minimum
+As mentioned earlier, `build.info` files are meant to hold the minimum
 information needed to build output files, and therefore only (with a
 few possible exceptions [1]) have information about end products (such
 as scripts, library files and programs) and source files (such as C
 files, C header files, assembler files, etc).  Intermediate files such
-as object files are rarely directly referred to in build.info files (and
-when they are, it's always with the file name extension .o), they are
-inferred by Configure.  By the same rule of minimalism, end product
-file name extensions (such as .so, .a, .exe, etc) are never mentioned
-in build.info.  Their file name extensions will be inferred by the
+as object files are rarely directly referred to in `build.info` files (and
+when they are, it's always with the file name extension `.o`), they are
+inferred by `Configure`.  By the same rule of minimalism, end product
+file name extensions (such as `.so`, `.a`, `.exe`, etc) are never mentioned
+in `build.info`.  Their file name extensions will be inferred by the
 build-file templates, adapted for the platform they are meant for (see
-sections on %unified_info and build-file templates further down).
+sections on `%unified_info` and build-file templates further down).
 
-The variables PROGRAMS, LIBS, MODULES and SCRIPTS are used to declare
-end products.  There are variants for them with '_NO_INST' as suffix
-(PROGRAM_NO_INST etc) to specify end products that shouldn't get
-installed.
+The variables `PROGRAMS`, `LIBS`, `MODULES` and `SCRIPTS` are used to declare
+end products.  There are variants for them with `_NO_INST` as suffix
+(`PROGRAM_NO_INST` etc) to specify end products that shouldn't get installed.
 
-The variables SOURCE, DEPEND, INCLUDE and DEFINE are indexed by a
+The variables `SOURCE`, `DEPEND`, `INCLUDE` and `DEFINE` are indexed by a
 produced file, and their values are the source used to produce that
 particular produced file, extra dependencies, include directories
 needed, or C macros to be defined.
 
-All their values in all the build.info throughout the source tree are
+All their values in all the `build.info` throughout the source tree are
 collected together and form a set of programs, libraries, modules and
 scripts to be produced, source files, dependencies, etc etc etc.
 
 Let's have a pretend example, a very limited contraption of OpenSSL,
-composed of the program 'apps/openssl', the libraries 'libssl' and
-'libcrypto', an module 'engines/ossltest' and their sources and
+composed of the program `apps/openssl`, the libraries `libssl` and
+`libcrypto`, an module `engines/ossltest` and their sources and
 dependencies.
 
     # build.info
@@ -61,11 +60,11 @@ dependencies.
     INCLUDE[libssl]=include
     DEPEND[libssl]=libcrypto
 
-This is the top directory build.info file, and it tells us that two
-libraries are to be built, the include directory 'include/' shall be
+This is the top directory `build.info` file, and it tells us that two
+libraries are to be built, the include directory `include/` shall be
 used throughout when building anything that will end up in each
-library, and that the library 'libssl' depend on the library
-'libcrypto' to function properly.
+library, and that the library `libssl` depend on the library
+`libcrypto` to function properly.
 
     # apps/build.info
     PROGRAMS=openssl
@@ -73,15 +72,15 @@ library, and that the library 'libssl' depend on the library
     INCLUDE[openssl]=.. ../include
     DEPEND[openssl]=../libssl
 
-This is the build.info file in 'apps/', one may notice that all file
-paths mentioned are relative to the directory the build.info file is
+This is the `build.info` file in `apps/`, one may notice that all file
+paths mentioned are relative to the directory the `build.info` file is
 located in.  This one tells us that there's a program to be built
-called 'apps/openssl' (the file name extension will depend on the
-platform and is therefore not mentioned in the build.info file).  It's
-built from one source file, 'apps/openssl.c', and building it requires
-the use of '.' and 'include' include directories (both are declared
-from the point of view of the 'apps/' directory), and that the program
-depends on the library 'libssl' to function properly.
+called `apps/openss` (the file name extension will depend on the
+platform and is therefore not mentioned in the `build.info` file).  It's
+built from one source file, `apps/openssl.c`, and building it requires
+the use of `.` and `include/` include directories (both are declared
+from the point of view of the `apps/` directory), and that the program
+depends on the library `libssl` to function properly.
 
     # crypto/build.info
     LIBS=../libcrypto
@@ -92,32 +91,32 @@ depends on the library 'libssl' to function properly.
     DEPEND[buildinf.h]=../Makefile
     DEPEND[../util/mkbuildinf.pl]=../util/Foo.pm
 
-This is the build.info file in 'crypto', and it tells us a little more
-about what's needed to produce 'libcrypto'.  LIBS is used again to
-declare that 'libcrypto' is to be produced.  This declaration is
-really unnecessary as it's already mentioned in the top build.info
+This is the `build.info` file in `crypto/`, and it tells us a little more
+about what's needed to produce `libcrypto`.  LIBS is used again to
+declare that `libcrypto` is to be produced.  This declaration is
+really unnecessary as it's already mentioned in the top `build.info`
 file, but can make the info file easier to understand.  This is to
 show that duplicate information isn't an issue.
 
-This build.info file informs us that 'libcrypto' is built from a few
-source files, 'crypto/aes.c', 'crypto/evp.c' and 'crypto/cversion.c'.
+This `build.info` file informs us that `libcrypto` is built from a few
+source files, `crypto/aes.c`, `crypto/evp.c` and `crypto/cversion.c`.
 It also shows us that building the object file inferred from
-'crypto/cversion.c' depends on 'crypto/buildinf.h'.  Finally, it
+`crypto/cversion.c` depends on `crypto/buildinf.h`.  Finally, it
 also shows the possibility to declare how some files are generated
 using some script, in this case a perl script, and how such scripts
 can be declared to depend on other files, in this case a perl module.
 
 Two things are worth an extra note:
 
-'DEPEND[cversion.o]' mentions an object file.  DEPEND indexes is the
+`DEPEND[cversion.o]` mentions an object file.  DEPEND indexes is the
 only location where it's valid to mention them
 
     # ssl/build.info
     LIBS=../libssl
     SOURCE[../libssl]=tls.c
 
-This is the build.info file in 'ssl/', and it tells us that the
-library 'libssl' is built from the source file 'ssl/tls.c'.
+This is the build.info file in `ssl/`, and it tells us that the
+library `libssl` is built from the source file `ssl/tls.c`.
 
     # engines/build.info
     MODULES=dasync
@@ -130,17 +129,17 @@ library 'libssl' is built from the source file 'ssl/tls.c'.
     DEPEND[ossltest]=../libcrypto.a
     INCLUDE[ossltest]=../include
 
-This is the build.info file in 'engines/', telling us that two modules
-called 'engines/dasync' and 'engines/ossltest' shall be built, that
-dasync's source is 'engines/e_dasync.c' and ossltest's source is
-'engines/e_ossltest.c' and that the include directory 'include/' may
+This is the `build.info` file in `engines/`, telling us that two modules
+called `engines/dasync` and `engines/ossltest` shall be built, that
+`dasync`'s source is `engines/e_dasync.c` and `ossltest`'s source is
+`engines/e_ossltest.c` and that the include directory `include/` may
 be used when building anything that will be part of these modules.
-Also, both modules depend on the library 'libcrypto' to function
-properly.  ossltest is explicitly linked with the static variant of
-the library 'libcrypto'.  Finally, only dasync is being installed, as
-ossltest is only for internal testing.
+Also, both modules depend on the library `libcrypto` to function
+properly.  `ossltest` is explicitly linked with the static variant of
+the library `libcrypto`.  Finally, only `dasync` is being installed, as
+`ossltest` is only for internal testing.
 
-When Configure digests these build.info files, the accumulated
+When `Configure` digests these `build.info` files, the accumulated
 information comes down to this:
 
     LIBS=libcrypto libssl
@@ -170,83 +169,81 @@ information comes down to this:
     DEPEND[crypto/buildinf.h]=Makefile
     DEPEND[util/mkbuildinf.pl]=util/Foo.pm
 
-
 A few notes worth mentioning:
 
-LIBS may be used to declare routine libraries only.
+`LIBS` may be used to declare routine libraries only.
 
-PROGRAMS may be used to declare programs only.
+`PROGRAMS` may be used to declare programs only.
 
-MODULES may be used to declare modules only.
+`MODULES` may be used to declare modules only.
 
-The indexes for SOURCE must only be end product files, such as
-libraries, programs or modules.  The values of SOURCE variables must
+The indexes for `SOURCE` must only be end product files, such as
+libraries, programs or modules.  The values of `SOURCE` variables must
 only be source files (possibly generated).
 
-INCLUDE and DEPEND shows a relationship between different files
+`INCLUDE` and `DEPEND` shows a relationship between different files
 (usually produced files) or between files and directories, such as a
 program depending on a library, or between an object file and some
 extra source file.
 
-When Configure processes the build.info files, it will take it as
+When `Configure` processes the `build.info` files, it will take it as
 truth without question, and will therefore perform very few checks.
 If the build tree is separate from the source tree, it will assume
 that all built files and up in the build directory and that all source
 files are to be found in the source tree, if they can be found there.
-Configure will assume that source files that can't be found in the
-source tree (such as 'crypto/bildinf.h' in the example above) are
+`Configure` will assume that source files that can't be found in the
+source tree (such as `crypto/bildinf.h` in the example above) are
 generated and will be found in the build tree.
 
+The `%unified_info` database
+----------------------------
 
-The %unified_info database
---------------------------
-
-The information in all the build.info get digested by Configure and
-collected into the %unified_info database, divided into the following
+The information in all the `build.info` get digested by `Configure` and
+collected into the `%unified_info` database, divided into the following
 indexes:
 
-  depends   => a hash table containing 'file' => [ 'dependency' ... ]
-               pairs.  These are directly inferred from the DEPEND
-               variables in build.info files.
+    depends   => a hash table containing 'file' => [ 'dependency' ... ]
+                 pairs.  These are directly inferred from the DEPEND
+                 variables in build.info files.
 
-  modules   => a list of modules.  These are directly inferred from
-               the MODULES variable in build.info files.
+    modules   => a list of modules.  These are directly inferred from
+                 the MODULES variable in build.info files.
 
-  generate  => a hash table containing 'file' => [ 'generator' ... ]
-               pairs.  These are directly inferred from the GENERATE
-               variables in build.info files.
+    generate  => a hash table containing 'file' => [ 'generator' ... ]
+                 pairs.  These are directly inferred from the GENERATE
+                 variables in build.info files.
 
-  includes  => a hash table containing 'file' => [ 'include' ... ]
-               pairs.  These are directly inferred from the INCLUDE
-               variables in build.info files.
+    includes  => a hash table containing 'file' => [ 'include' ... ]
+                 pairs.  These are directly inferred from the INCLUDE
+                 variables in build.info files.
 
-  install   => a hash table containing 'type' => [ 'file' ... ] pairs.
-               The types are 'programs', 'libraries', 'modules' and
-               'scripts', and the array of files list the files of
-               that type that should be installed.
+    install   => a hash table containing 'type' => [ 'file' ... ] pairs.
+                 The types are 'programs', 'libraries', 'modules' and
+                 'scripts', and the array of files list the files of
+                 that type that should be installed.
 
-  libraries => a list of libraries.  These are directly inferred from
-               the LIBS variable in build.info files.
+    libraries => a list of libraries.  These are directly inferred from
+                 the LIBS variable in build.info files.
 
-  programs  => a list of programs.  These are directly inferred from
-               the PROGRAMS variable in build.info files.
+    programs  => a list of programs.  These are directly inferred from
+                 the PROGRAMS variable in build.info files.
 
-  scripts   => a list of scripts.  There are directly inferred from
-               the SCRIPTS variable in build.info files.
+    scripts   => a list of scripts.  There are directly inferred from
+                 the SCRIPTS variable in build.info files.
 
-  sources   => a hash table containing 'file' => [ 'sourcefile' ... ]
-               pairs.  These are indirectly inferred from the SOURCE
-               variables in build.info files.  Object files are
-               mentioned in this hash table, with source files from
-               SOURCE variables, and AS source files for programs and
-               libraries.
+    sources   => a hash table containing 'file' => [ 'sourcefile' ... ]
+                 pairs.  These are indirectly inferred from the SOURCE
+                 variables in build.info files.  Object files are
+                 mentioned in this hash table, with source files from
+                 SOURCE variables, and AS source files for programs and
+                 libraries.
 
-  shared_sources =>
-               a hash table just like 'sources', but only as source
-               files (object files) for building shared libraries.
+    shared_sources =>
+                 a hash table just like 'sources', but only as source
+                 files (object files) for building shared libraries.
 
-As an example, here is how the build.info files example from the
-section above would be digested into a %unified_info table:
+As an example, here is how the `build.info` files example from the
+section above would be digested into a `%unified_info` table:
 
     our %unified_info = (
         "depends" =>
@@ -399,20 +396,19 @@ section above would be digested into a %unified_info table:
             },
     );
 
-As can be seen, everything in %unified_info is fairly simple suggest
+As can be seen, everything in `%unified_info` is fairly simple suggest
 of information.  Still, it tells us that to build all programs, we
-must build 'apps/openssl', and to build the latter, we will need to
-build all its sources ('apps/openssl.o' in this case) and all the
-other things it depends on (such as 'libssl').  All those dependencies
-need to be built as well, using the same logic, so to build 'libssl',
-we need to build 'ssl/tls.o' as well as 'libcrypto', and to build the
+must build `apps/openssl`, and to build the latter, we will need to
+build all its sources (`apps/openssl.o` in this case) and all the
+other things it depends on (such as `libssl`).  All those dependencies
+need to be built as well, using the same logic, so to build `libssl`,
+we need to build `ssl/tls.o` as well as `libcrypto`, and to build the
 latter...
 
-
 Build-file templates
 --------------------
 
-Build-file templates are essentially build-files (such as Makefile on
+Build-file templates are essentially build-files (such as `Makefile` on
 Unix) with perl code fragments mixed in.  Those perl code fragment
 will generate all the configuration dependent data, including all the
 rules needed to build end product files and intermediary files alike.
@@ -461,7 +457,7 @@ etc.
                                 incs => [ "INCL/PATH", ... ]
                                 intent => one of "lib", "dso", "bin" );
 
-                  'obj' has the intended object file with '.o'
+                  'obj' has the intended object file with `.o`
                   extension, src2obj() is expected to change it to
                   something more suitable for the platform.
                   'srcs' has the list of source files to build the
@@ -557,13 +553,13 @@ etc.
                   resulting script from.
 
 Along with the build-file templates is the driving template
-Configurations/common.tmpl, which looks through all the information in
-%unified_info and generates all the rulesets to build libraries,
+[`Configurations/common.tmpl`](common.tmpl), which looks through all the
+information in `%unified_info` and generates all the rulesets to build libraries,
 programs and all intermediate files, using the rule generating
 functions defined in the build-file template.
 
-As an example with the smaller build.info set we've seen as an
-example, producing the rules to build 'libcrypto' would result in the
+As an example with the smaller `build.info` set we've seen as an
+example, producing the rules to build `libcrypto` would result in the
 following calls:
 
     # Note: obj2shlib will only be called if shared libraries are
diff --git a/Configurations/README.md b/Configurations/README.md
index a0618ca2d3..3fa80a3fab 100644
--- a/Configurations/README.md
+++ b/Configurations/README.md
@@ -14,7 +14,6 @@ configuration in diverse ways:
                 script.  See 'Configure helper scripts for more
                 information.
 
-
 Configurations of OpenSSL target platforms
 ==========================================
 
@@ -54,12 +53,12 @@ In each table entry, the following keys are significant:
                            usually good enough.
         cppflags        => Default C preprocessor flags [4].
         defines         => As an alternative, macro definitions may be
-                           given here instead of in `cppflags' [4].
+                           given here instead of in 'cppflags' [4].
                            If given here, they MUST be as an array of
                            the string such as "MACRO=value", or just
                            "MACRO" for definitions without value.
         includes        => As an alternative, inclusion directories
-                           may be given here instead of in `cppflags'
+                           may be given here instead of in 'cppflags'
                            [4].  If given here, the MUST be an array
                            of strings, one directory specification
                            each.
@@ -99,9 +98,9 @@ In each table entry, the following keys are significant:
         module_cppflags
         module_cflags
         module_ldflags  => Has the same function as the corresponding
-                           `shared_' attributes, but for building DSOs.
+                           'shared_' attributes, but for building DSOs.
                            When unset, they get the same values as the
-                           corresponding `shared_' attributes.
+                           corresponding 'shared_' attributes.
 
         ar              => The library archive command, the default is
                            "ar".
@@ -237,31 +236,30 @@ In each table entry, the following keys are significant:
                            RC4_INT              RC4 key schedule is made
                                                 up of 'unsigned int's;
 
-
 [1] as part of the target configuration, one can have a key called
-    'inherit_from' that indicate what other configurations to inherit
-    data from.  These are resolved recursively.
+  `inherit_from` that indicates what other configurations to inherit
+  data from.  These are resolved recursively.
 
-    Inheritance works as a set of default values that can be overridden
-    by corresponding key values in the inheriting configuration.
+  Inheritance works as a set of default values that can be overridden
+  by corresponding key values in the inheriting configuration.
 
-    Note 1: any configuration table can be used as a template.
-    Note 2: pure templates have the attribute 'template => 1' and
-            cannot be used as build targets.
+  Note 1: any configuration table can be used as a template.
+  Note 2: pure templates have the attribute `template => 1` and
+          cannot be used as build targets.
 
-    If several configurations are given in the 'inherit_from' array,
-    the values of same attribute are concatenated with space
-    separation.  With this, it's possible to have several smaller
-    templates for different configuration aspects that can be combined
-    into a complete configuration.
+  If several configurations are given in the `inherit_from` array,
+  the values of same attribute are concatenated with space
+  separation.  With this, it's possible to have several smaller
+  templates for different configuration aspects that can be combined
+  into a complete configuration.
 
-    instead of a scalar value or an array, a value can be a code block
-    of the form 'sub { /* your code here */ }'.  This code block will
-    be called with the list of inherited values for that key as
-    arguments.  In fact, the concatenation of strings is really done
-    by using 'sub { join(" ",@_) }' on the list of inherited values.
+  Instead of a scalar value or an array, a value can be a code block
+  of the form `sub { /* your code here */ }`.  This code block will
+  be called with the list of inherited values for that key as
+  arguments.  In fact, the concatenation of strings is really done
+  by using `sub { join(" ",@_) }` on the list of inherited values.
 
-    An example:
+  An example:
 
         "foo" => {
                 template => 1,
@@ -291,21 +289,21 @@ In each table entry, the following keys are significant:
         }
 
 [2] OpenSSL is built with threading capabilities unless the user
-    specifies 'no-threads'.  The value of the key 'thread_scheme' may
-    be "(unknown)", in which case the user MUST give some compilation
-    flags to Configure.
+  specifies `no-threads`.  The value of the key `thread_scheme` may
+  be `(unknown)`, in which case the user MUST give some compilation
+  flags to `Configure`.
 
 [3] OpenSSL has three types of things to link from object files or
-    static libraries:
+  static libraries:
 
-    - shared libraries; that would be libcrypto and libssl.
-    - shared objects (sometimes called dynamic libraries);  that would
-      be the modules.
-    - applications; those are apps/openssl and all the test apps.
+  - shared libraries; that would be libcrypto and libssl.
+  - shared objects (sometimes called dynamic libraries);  that would
+    be the modules.
+  - applications; those are apps/openssl and all the test apps.
 
-    Very roughly speaking, linking is done like this (words in braces
-    represent the configuration settings documented at the beginning
-    of this file):
+  Very roughly speaking, linking is done like this (words in braces
+  represent the configuration settings documented at the beginning
+  of this file):
 
     shared libraries:
         {ld} $(CFLAGS) {lflags} {shared_ldflag} -o libfoo.so \
@@ -319,38 +317,43 @@ In each table entry, the following keys are significant:
         {ld} $(CFLAGS) {lflags} -o app \
             app1.o utils.o -lssl -lcrypto {ex_libs}
 
-[4] There are variants of these attribute, prefixed with `lib_',
-    `dso_' or `bin_'.  Those variants replace the unprefixed attribute
-    when building library, DSO or program modules specifically.
+[4] There are variants of these attribute, prefixed with `lib_`,
+  `dso_` or `bin_`.  Those variants replace the unprefixed attribute
+  when building library, DSO or program modules specifically.
 
 Historically, the target configurations came in form of a string with
 values separated by colons.  This use is deprecated.  The string form
 looked like this:
 
-   "target" => "{cc}:{cflags}:{unistd}:{thread_cflag}:{sys_id}:{lflags}:{bn_ops}:{cpuid_obj}:{bn_obj}:{ec_obj}:{des_obj}:{aes_obj}:{bf_obj}:{md5_obj}:{sha1_obj}:{cast_obj}:{rc4_obj}:{rmd160_obj}:{rc5_obj}:{wp_obj}:{cmll_obj}:{modes_obj}:{padlock_obj}:{perlasm_scheme}:{dso_scheme}:{shared_target}:{shared_cflag}:{shared_ldflag}:{shared_extension}:{ranlib}:{arflags}:{multilib}"
-
+    "target" => "{cc}:{cflags}:{unistd}:{thread_cflag}:{sys_id}:{lflags}:
+                 {bn_ops}:{cpuid_obj}:{bn_obj}:{ec_obj}:{des_obj}:{aes_obj}:
+                 {bf_obj}:{md5_obj}:{sha1_obj}:{cast_obj}:{rc4_obj}:
+                 {rmd160_obj}:{rc5_obj}:{wp_obj}:{cmll_obj}:{modes_obj}:
+                 {padlock_obj}:{perlasm_scheme}:{dso_scheme}:{shared_target}:
+                 {shared_cflag}:{shared_ldflag}:{shared_extension}:{ranlib}:
+                 {arflags}:{multilib}"
 
 Build info files
 ================
 
-The build.info files that are spread over the source tree contain the
+The `build.info` files that are spread over the source tree contain the
 minimum information needed to build and distribute OpenSSL.  It uses a
 simple and yet fairly powerful language to determine what needs to be
 built, from what sources, and other relationships between files.
 
-For every build.info file, all file references are relative to the
-directory of the build.info file for source files, and the
+For every `build.info` file, all file references are relative to the
+directory of the `build.info` file for source files, and the
 corresponding build directory for built files if the build tree
 differs from the source tree.
 
 When processed, every line is processed with the perl module
-Text::Template, using the delimiters "{-" and "-}".  The hashes
-%config and %target are passed to the perl fragments, along with
+Text::Template, using the delimiters `{-` and `-}`.  The hashes
+`%config` and `%target` are passed to the perl fragments, along with
 $sourcedir and $builddir, which are the locations of the source
-directory for the current build.info file and the corresponding build
+directory for the current `build.info` file and the corresponding build
 directory, all relative to the top of the build tree.
 
-'Configure' only knows inherently about the top build.info file.  For
+`Configure` only knows inherently about the top `build.info` file.  For
 any other directory that has one, further directories to look into
 must be indicated like this:
 
@@ -393,7 +396,7 @@ This should be rarely used, and care should be taken to make sure it's
 only used when supported.  For example, native Windows build doesn't
 support building static libraries and DLLs at the same time, so using
 static libraries on Windows can only be done when configured
-'no-shared'.
+`no-shared`.
 
 In some cases, it's desirable to include some source files in the
 shared form of a library only:
@@ -435,7 +438,7 @@ be used in that case:
 
 NOTE: GENERATE lines are limited to one command only per GENERATE.
 
-Finally, you can have some simple conditional use of the build.info
+Finally, you can have some simple conditional use of the `build.info`
 information, looking like this:
 
     IF[1]
@@ -461,37 +464,37 @@ conditions based on something in the passed variables, for example:
       SOURCE[libfoo]=...
     ENDIF
 
-
 Build-file programming with the "unified" build system
 ======================================================
 
-"Build files" are called "Makefile" on Unix-like operating systems,
-"descrip.mms" for MMS on VMS, "makefile" for nmake on Windows, etc.
+"Build files" are called `Makefile` on Unix-like operating systems,
+`descrip.mms` for MMS on VMS, `makefile` for `nmake` on Windows, etc.
 
 To use the "unified" build system, the target configuration needs to
-set the three items 'build_scheme', 'build_file' and 'build_command'.
-In the rest of this section, we will assume that 'build_scheme' is set
+set the three items `build_scheme`, `build_file` and `build_command`.
+In the rest of this section, we will assume that `build_scheme` is set
 to "unified" (see the configurations documentation above for the
 details).
 
-For any name given by 'build_file', the "unified" system expects a
-template file in Configurations/ named like the build file, with
-".tmpl" appended, or in case of possible ambiguity, a combination of
-the second 'build_scheme' list item and the 'build_file' name.  For
-example, if 'build_file' is set to "Makefile", the template could be
-Configurations/Makefile.tmpl or Configurations/unix-Makefile.tmpl.
-In case both Configurations/unix-Makefile.tmpl and
-Configurations/Makefile.tmpl are present, the former takes
+For any name given by `build_file`, the "unified" system expects a
+template file in `Configurations/` named like the build file, with
+`.tmpl` appended, or in case of possible ambiguity, a combination of
+the second `build_scheme` list item and the `build_file` name.  For
+example, if `build_file` is set to `Makefile`, the template could be
+[`Configurations/Makefile.tmpl`](Makefile.tmpl) or
+[`Configurations/unix-Makefile.tmpl`](unix-Makefile.tmpl).
+In case both [`Configurations/unix-Makefile.tmpl`](Makefile.tmpl) and
+[`Configurations/Makefile.tmpl`](Makefile.tmpl) are present, the former takes
 precedence.
 
 The build-file template is processed with the perl module
-Text::Template, using "{-" and "-}" as delimiters that enclose the
+Text::Template, using `{-` and `-}` as delimiters that enclose the
 perl code fragments that generate configuration-dependent content.
 Those perl fragments have access to all the hash variables from
 configdata.pem.
 
 The build-file template is expected to define at least the following
-perl functions in a perl code fragment enclosed with "{-" and "-}".
+perl functions in a perl code fragment enclosed with `{-` and `-}`.
 They are all expected to return a string with the lines they produce.
 
     generatesrc - function that produces build file lines to generate
@@ -640,7 +643,6 @@ else, end it like this:
       "";       # Make sure no lingering values end up in the Makefile
     -}
 
-
 Configure helper scripts
 ========================
 
@@ -651,10 +653,10 @@ Checker scripts
 
 These scripts are per platform family, to check the integrity of the
 tools used for configuration and building.  The checker script used is
-either {build_platform}-{build_file}-checker.pm or
-{build_platform}-checker.pm, where {build_platform} is the second
-'build_scheme' list element from the configuration target data, and
-{build_file} is 'build_file' from the same target data.
+either `{build_platform}-{build_file}-checker.pm` or
+`{build_platform}-checker.pm`, where `{build_platform}` is the second
+`build_scheme` list element from the configuration target data, and
+`{build_file}` is `build_file` from the same target data.
 
 If the check succeeds, the script is expected to end with a non-zero
 expression.  If the check fails, the script can end with a zero, or