aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2020-07-02 10:08:03 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2020-07-02 10:08:03 +0200
commitb4968c4104c7f36fd6620af9e8b1262d8f694c9f (patch)
treeabf6ee20fb6d3fa9495f83d2d04c7e89ff0965af /doc
parent7d715bb43457fc760ec57ab757f3fd37e1655fae (diff)
Use consistent style when referencing modules in manual
Diffstat (limited to 'doc')
-rw-r--r--doc/manual.cli25
1 files changed, 13 insertions, 12 deletions
diff --git a/doc/manual.cli b/doc/manual.cli
index 4a3a3c4..cf2ec3a 100644
--- a/doc/manual.cli
+++ b/doc/manual.cli
@@ -75,7 +75,7 @@ maintaining build infrastructure for your projects a pleasant task.
Also note that \c{build2} is not specific to C/C++ or even to compiled
languages; its build model is general enough to handle any DAG-based
-operations. See the \l{#module-bash \c{bash} Module} for a good example.
+operations. See the \l{#module-bash \c{bash}} module for a good example.
While the build system is part of a larger, well-integrated build toolchain
that includes the package and project dependency managers, it does not depend
@@ -2394,8 +2394,8 @@ obtain its version. This header is generated by the \c{version} module from
the \c{version.hxx.in} template. In essence, the \c{version} module takes the
version value from our \c{manifest}, splits it into various components (major,
minor, patch, etc) and then preprocesses the \c{in{\}} file substituting these
-values (see \l{#module-version \c{version} Module} for details). The end
-result is an automatically maintained version header.
+values (see the \l{#module-version \c{version}} module documentation for
+details). The end result is an automatically maintained version header.
One problem with auto-generated headers is that if one does not yet exist,
then the compiler may still find it somewhere else. For example, we may have
@@ -2817,7 +2817,7 @@ link executable to static libraries we can run:
$ b config.bin.lib=both config.bin.exe.lib=static
\
-See \l{#module-bin \c{bin} Module} for more information.|
+See the \l{#module-bin \c{bin}} module documentation for more information.|
Note also that we don't need to change anything in the above \c{buildfile} if
our library is header-only. In \c{build2} this is handled dynamically and
@@ -2863,8 +2863,9 @@ platform-specific versions in a native format.
The library version is specified with the \c{bin.lib.version} target-specific
variable. Its value should be a sequence of \c{@}-pairs with the left hand
side (key) being the platform name and the right hand side (value) being the
-version. An empty key signifies the platform-independent version (see
-\l{#module-bin \c{bin} Module} for the exact semantics). For example:
+version. An empty key signifies the platform-independent version (see the
+\l{#module-bin \c{bin}} module documentation for the exact semantics). For
+example:
\
lib{hello}: bin.lib.version = @-1.2 linux@3
@@ -2901,8 +2902,8 @@ make sure it cannot be used in place of another pre-release or the final
version.
\N|The \c{version.project_id} variable contains the project's (as opposed to
-package's), shortest \"version id\". See the \l{#module-version \c{version}
-Module} for details.|
+package's), shortest \"version id\". See the \l{#module-version \c{version}}
+module documentation for details.|
\h#intro-subproj|Subprojects and Amalgamations|
@@ -4933,8 +4934,8 @@ The \c{libhello/config.hxx.in} file is new:
\
As you can see, we can reference our configuration variables directly in the
-\c{config.hxx.in} substitutions (see \l{#module-in \c{in} Module} for details
-on how this works).
+\c{config.hxx.in} substitutions (see the \l{#module-in \c{in}} module
+documentation for details on how this works).
\N|With this setup, the way to export configuration information to our
library's users is to make the configuration header public and install it,
@@ -6182,7 +6183,7 @@ by passing one of the \c{cl} \c{/M*} options, for example:
This chapter describes the \c{c} build system module which provides the C
compilation and linking support. Most of its functionality, however, is
-provided by the \l{#module-cc \c{cc} module}, a common implementation for the
+provided by the \l{#module-cc \c{cc}} module, a common implementation for the
C-family languages.
\h#c-config|C Configuration Variables|
@@ -6243,7 +6244,7 @@ config.c.libs
This chapter describes the \c{cxx} build system module which provides the C++
compilation and linking support. Most of its functionality, however, is
-provided by the \l{#module-cc \c{cc} module}, a common implementation for the
+provided by the \l{#module-cc \c{cc}} module, a common implementation for the
C-family languages.
\h#cxx-config|C++ Configuration Variables|