diff options
Diffstat (limited to 'doc/manual.cli')
| -rw-r--r-- | doc/manual.cli | 20 |
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: |