diff options
author | Boris Kolpackov <boris@codesynthesis.com> | 2020-07-02 10:08:03 +0200 |
---|---|---|
committer | Boris Kolpackov <boris@codesynthesis.com> | 2020-07-02 10:08:03 +0200 |
commit | b4968c4104c7f36fd6620af9e8b1262d8f694c9f (patch) | |
tree | abf6ee20fb6d3fa9495f83d2d04c7e89ff0965af | |
parent | 7d715bb43457fc760ec57ab757f3fd37e1655fae (diff) |
Use consistent style when referencing modules in manual
-rw-r--r-- | doc/manual.cli | 25 |
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| |