Fix source directory/subdirectory terminology inconsistencies in manual

1 files changed, 10 insertions, 10 deletions

diff --git a/doc/manual.cli b/doc/manual.cli
index c7eef38..7731609 100644
--- a/doc/manual.cli
+++ b/doc/manual.cli
@@ -894,8 +894,8 @@ libhello/
 └── README.md
 \
 
-The overall layout (\c{build/}, \c{libhello/} source directory) as well as the
-contents of the root files (\c{bootstrap.build}, \c{root.build}, root
+The overall layout (\c{build/}, \c{libhello/} source subdirectory) as well as
+the contents of the root files (\c{bootstrap.build}, \c{root.build}, root
 \c{buildfile}) are exactly the same. There is, however, the new file
 \c{export.build} in \c{build/}, the new subdirectory \c{tests/}, and the
 contents of the project's source subdirectory \c{libhello/} look quite a bit
@@ -1366,7 +1366,7 @@ prerequisite-specific). These and other variable-related topics will be
 covered in subsequent sections.|
 
 One typical place to find \c{src/out_root} expansions is in the include search
-path options. For example, the source directory \c{buildfile} generated by
+path options. For example, the source subdirectory \c{buildfile} generated by
 \l{bdep-new(1)} for an executable project actually looks like this
 (\c{poptions} stands for \i{preprocessor options}):
 
@@ -1506,7 +1506,7 @@ In the few cases that we do, we use the following syntax:
 If the scope directory is relative, then it is assumed to be relative to the
 current scope. As an exercise for understanding, let's reimplement our
 \c{hello} project as a single \c{buildfile}. That is, we move the contents of
-the source directory \c{buildfile} into the root \c{buildfile}:
+the source subdirectory \c{buildfile} into the root \c{buildfile}:
 
 \
 $ tree hello/
@@ -1536,7 +1536,7 @@ which explicitly opens scopes to define the build over the upstream project's
 subdirectory structure.|
 
 Seeing this merged \c{buildfile} may make you wonder what exactly caused the
-loading of the source directory \c{buildfile} in our normal setup. In other
+loading of the source subdirectory \c{buildfile} in our normal setup. In other
 words, when we build our \c{hello} from the project root, who loads
 \c{hello/buildfile} and why?
 
@@ -2143,7 +2143,7 @@ libhello/
 \
 
 Specifically, there is no \c{testscript} in \c{libhello/}, the project's
-source directory. Instead, we have the \c{tests/} subdirectory which itself
+source subdirectory. Instead, we have the \c{tests/} subdirectory which itself
 looks like a project: it contains the \c{build/} subdirectory with all the
 familiar files, etc. In fact, \c{tests} is a \i{subproject} of our
 \c{libhello} project.
@@ -2351,7 +2351,7 @@ corresponding \c{config.install.*} variables (see the \l{#module-install
 \c{install}} module documentation for details on their meaning). In our
 \c{buildfiles}, in turn, we use the node names instead of actual
 directories. As an example, here is a \c{buildfile} fragment from the source
-directory of our \c{libhello} project:
+subdirectory of our \c{libhello} project:
 
 \
 hxx{*}:
@@ -2377,7 +2377,7 @@ root/include/libhello/
 In the above \c{buildfile} fragment we also see the use of the
 \c{install.subdirs} variable. Setting it to \c{true} instructs the \c{install}
 module to recreate subdirectories starting from this point in the project's
-directory hierarchy.  For example, if our \c{libhello/} source directory had
+directory hierarchy. For example, if our \c{libhello/} source subdirectory had
 the \c{details/} subdirectory with the \c{utility.hxx} header, then this
 header would have been installed as
 \c{.../include/libhello/details/utility.hxx}.
@@ -2491,7 +2491,7 @@ $ b dist
 
 Let's now take a look at an example of customizing what gets distributed.
 Most of the time you will be using this mechanism to include certain targets
-from out. Here is a fragment from the \c{libhello} source directory
+from out. Here is a fragment from the \c{libhello} source subdirectory
 \c{buildfile}:
 
 \
@@ -4454,7 +4454,7 @@ scopes. For that we use the \c{dump} directive.
 Without any arguments, \c{dump} prints (to \c{stderr}) the contents of the
 scope it was encountered in and at that point of processing the \c{buildfile}.
 Its output includes variables, targets and their prerequisites, as well as
-nested scopes, recursively. As an example, let's print the source directory
+nested scopes, recursively. As an example, let's print the source subdirectory
 scope of our \c{hello} executable project. Here is its \c{buildfile} with
 the \c{dump} directive at the end: