aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2020-07-10 12:03:09 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2020-07-10 12:03:09 +0200
commit8352dcb89d65f2abac0f39aaeeae59b89c19126c (patch)
treefed03aa7a00360460d14df9b16250b2912ef5afd /doc
parent002858e1eb952baf7f539a10db332498d86105c4 (diff)
Minor tweaks to introduction
Diffstat (limited to 'doc')
-rw-r--r--doc/intro.cli23
1 files changed, 12 insertions, 11 deletions
diff --git a/doc/intro.cli b/doc/intro.cli
index 10548a5..cac0030 100644
--- a/doc/intro.cli
+++ b/doc/intro.cli
@@ -2286,20 +2286,21 @@ and tools, scale to complex, real-world requirements, and, last but not least,
are pleasant to work with.
The canonical structure is primarily meant for a package \- a single library
-or program (or, sometimes, a collection of related programs) with a specific
-and well-defined function. While it may be less suitable for more elaborate,
-multi-library/program \i{end-products} that are not meant to be packaged, most
-of the recommendations discussed below would still apply. Oftentimes, you
-would start with a canonical project and expand from there. Note also that
-while the discussion below focuses on C++, most of it applies equally to C
-projects.
+or program (or, sometimes, a collection of related libraries or programs)
+with a specific and well-defined function. While it may be less suitable for
+more elaborate, multi-library/program \i{end-products} that are not meant to
+be packaged, most of the recommendations discussed below would still
+apply. Oftentimes, you would start with a canonical project and expand from
+there. Note also that while the discussion below focuses on C++, most of it
+applies equally to C projects.
\N|We often find ourselves factoring common functionality out of such
end-products and into separate packages, for example, in order to be reused in
another end-product). In this light, it can be helpful to organize a new
end-product project as a composition of individual packages or source
subdirectories that follow the canonical structure. The \l{bdep-new(1)}
-\c{--package} and \c{--subdirectory} modes can used to automate this process.|
+\c{--package} and \c{--subdirectory} modes can be used to automate this
+process.|
Projects created by the \l{bdep-new(1)} command have the canonical structure.
The overall layouts for executable (\c{-t\ exe}) and library (\c{-t\ lib})
@@ -2517,9 +2518,9 @@ why take the chance when there are no benefits. So let's imagine the \c{\"\"}
style inclusion does not exist and we will all have a much better time.|
If you have to disregard every rule and recommendation in this section but
-one, for example, because you are working on an existing library, then insist
-on this: \b{public header inclusions must use the library name as a directory
-prefix}.
+one, for example, because you are working on an existing library, then at
+minimum insist on this: \b{public header inclusions must use the library name
+as a directory prefix}.
The project's source subdirectory can have subdirectories of its own, for
example, to organize the code into components. Naturally, header inclusions