aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--doc/manual.cli22
1 files changed, 11 insertions, 11 deletions
diff --git a/doc/manual.cli b/doc/manual.cli
index 8821771..ca57199 100644
--- a/doc/manual.cli
+++ b/doc/manual.cli
@@ -4385,7 +4385,7 @@ Configuration Report} where we extract the GCC plugin directory while dealing
with the possibility of it Bunin configured without plugin support.|
Before we delve into the technical details, let's discuss the overall need for
-project configurability. While it may seem that making ones project more
+project configurability. While it may seem that making one's project more
user-configurable is always a good idea, there are costs: by having a choice
we increase the complexity and open the door for potential incompatibility.
Specifically, we may end up with two projects in the same build needing a
@@ -4480,7 +4480,7 @@ variable names in order to avoid clashes.
The build system core reserves \c{build} and \c{import} as the second
component in configuration variables as well as \c{configured} as the third
-and further components.|
+and subsequent components.|
\h#proj-config-directive|\c{config} Directive|
@@ -4496,7 +4496,7 @@ config [string] config.libhello.greeting ?= 'Hello'
\
\N|The irony does not escape us: these configuration variables are exactly of
-the kind that we advocate against. However, finding reasonable example of
+the kind that we advocate against. However, finding a reasonable example of
build-time configurability in a \i{\"Hello, World!\"} library is not easy. In
fact, it probably shouldn't have any. So, for this chapter, do as we say, not
as we do.|
@@ -4522,9 +4522,9 @@ After the attribute list we have the variable name. The \c{config} directive
will validate that it matches the \c{config[.**].<project>.**} pattern (with
one exception discussed in \l{#proj-config-report Configuration Report}).
-Finally, after the variable name comes optional default value. Note that
-unlike normal variables, default value assignment (\c{?=}) is the only valid
-form of assignment in the \c{config} directive.
+Finally, after the variable name comes the optional default value. Note that
+unlike normal variables, the default value assignment (\c{?=}) is the only
+valid form of assignment in the \c{config} directive.
The semantics of the \c{config} directive is as follows: First an overridable
variable is entered with the specified name, type (if any), and global
@@ -4539,7 +4539,7 @@ Note also that if the configuration value is not specified by the user and you
haven't provided the default, the variable will be undefined, not \c{null},
and, as a result, omitted from the persistent configuration
(\c{build/config.build} file). However, \c{null} is a valid default value. It
-is is traditionally used for \i{optional} configuration values. For example:
+is traditionally used for \i{optional} configuration values. For example:
\
config [string] config.libhello.fallback_name ?= [null]
@@ -4598,8 +4598,8 @@ if ($config.libhello.database == [null])
\
If computing the default value is expensive or requires elaborate logic, then
-handling of a configuration variable can be broken down into two steps along
-these lines:
+the handling of a configuration variable can be broken down into two steps
+along these lines:
\
config [string] config.libhello.greeting
@@ -4709,7 +4709,7 @@ this topic is discussed further in
One of the effects of the \c{config} directive is to mark a defined
configuration variable for reporting. The project configuration report is
-printed automatically at the sufficiently high verbosity level along with the
+printed automatically at a sufficiently high verbosity level along with the
build system module configuration. For example (some of the \c{cxx} module
configuration is omitted for brevity):
@@ -4994,7 +4994,7 @@ void say_hello (ostream& o, const string& n)
\N|Note that with \c{if\ constexpr} the branch not taken must still be valid,
parsable code. This is both one of the main benefits of using it instead of
\c{#if} (the code we are not using is still guaranteed to be syntactically
-correct) as well as its main drawbacks (it cannot be used, for example, for
+correct) as well as its main drawback (it cannot be used, for example, for
platform-specific code without extra efforts, such as providing shims for
missing declarations, etc).|