aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBoris Kolpackov <boris@codesynthesis.com>2016-09-06 18:20:19 +0200
committerBoris Kolpackov <boris@codesynthesis.com>2016-09-06 18:20:19 +0200
commitb3d37fa417cd3af2be3aaf33b3f3caf2919096c7 (patch)
tree6ad9abcacfdb593a600023da1e410b465b2b4cbc
parent5804ed4e970e5d15b854faeddf41fe43d4db6084 (diff)
Proofreading fixes to intro
-rw-r--r--doc/intro.cli48
1 files changed, 24 insertions, 24 deletions
diff --git a/doc/intro.cli b/doc/intro.cli
index a9e877f..87fd23b 100644
--- a/doc/intro.cli
+++ b/doc/intro.cli
@@ -105,13 +105,13 @@ toolchain can do so that you can decide if you are interested and want to learn
more. Further documentation is referenced at the end of this introduction.
The \c{build2} toolchain is self-hosted and self-packaged (and, yes, it is on
-\l{https://cppget.org/ cppget.org}). It could have then served as its own
-example. However, before the toolchain can build itself, we have to bootstrap
-it (that chicken and egg problem again). And this step wouldn't serve our goal
-of quickly learning what \c{build2} is about. So, instead, we will start with
-a customary \i{\"Hello, World!\"} example which you won't yet be able to try
+\l{https://cppget.org/ cppget.org}). It could have served as its own example,
+however, before the toolchain can build itself, we have to bootstrap it (that
+chicken and egg problem again). And this step wouldn't serve our goal of
+quickly learning what \c{build2} is about. So, instead, we will start with a
+customary \i{\"Hello, World!\"} example which you won't yet be able to try
yourself (but don't worry, complete terminal output will be shown). If at the
-end you find \c{build2} appealing, you can jump right to the
+end you find \c{build2} appealing, you can jump right to
\l{build2-toolchain-install.xhtml The \c{build2} Toolchain Installation and
Upgrade} (and, yes, there you get to run that coveted \c{bpkg build bpkg}).
Once the \c{build2} installation is complete, you can come back to the
@@ -119,10 +119,10 @@ Once the \c{build2} installation is complete, you can come back to the
This introduction explores the \i{consumer} side of \i{\"Hello, World!\"}.
That is, we assume that someone was kind enough to create and package the
-\c{libhello} library and the \c{hello} program and we will learn how to obtain
-and build them as well as keep up with their updates. At the end we will
-also see how to write our own, \c{hello2}, program that depends on \c{libhello}.
-And so, without further ado, let's begin.
+\c{libhello} library as well as the \c{hello} program and we will learn how to
+obtain and build them as well as keep up with their updates. At the end we
+will also see how to write our own, \c{hello2}, program that depends on
+\c{libhello}. And so, without further ado, let's begin.
The first step in using \c{bpkg} is to create a \i{configuration}. A
configuration is a directory where packages that require similar compile
@@ -178,7 +178,7 @@ module with \c{coptions} standing for \i{compile options} (there are also
\c{libs} for extra libraries to link).
There is also the \c{c} module for the C compilation. So if we were planning
-to build both C and C++ projects, then we could have ran:
+to build both C and C++ projects, then we could have run:
\
$ bpkg create c cxx ...
@@ -282,7 +282,7 @@ Let's see what's going on here. We ran \l{bpkg-pkg-build(1) \c{bpkg build}} to
build the \c{hello} program which happens to depend on the \c{libhello}
library. So \c{bpkg} presents us with a \i{plan of action}, that is, the steps
it will have to perform in order to build us \c{hello} and then asks us to
-confirm that's what we want to do (you can add \c{--yes|-y} to skip the
+confirm if that's what we want to do (you can add \c{--yes|-y} to skip the
confirmation). In the real-world usage the plan will be more complex, with
upgrades/downgrades, reconfigurations, etc.
@@ -328,7 +328,7 @@ purged libhello
\
Ok, ready for some \c{-v} details? Feel free to skip the following listing
-if not interested.
+if you are not interested.
\
$ bpkg build -v -y hello
@@ -389,9 +389,9 @@ unknown
\
Let's say we got wind of a new development: the \c{libhello} author released a
-new version of the library. It is such an advance in the state of the
-\i{\"Hello, World!\"} art, it's only currently available from \c{testing}. Of
-course, we must check it out.
+new version of the library. It is such an advance in the art of \i{\"Hello,
+World!\"}, it's only currently available from \c{testing}. Of course, we must
+check it out.
Now, what exactly is \c{testing}? You must have noticed that the repository
location that we've been using so far ended with \c{/stable}. Quite often it is
@@ -438,10 +438,10 @@ info: dir{hello-1.0.0/} is up to date
updated hello/1.0.0
\
-Why nothing happenned..? That's because \c{bpkg} will only upgrade (or
-downgrade) to a new version if we explicitly ask it to. As things stand, all
-dependencies for \c{hello} are satisfied and \c{bpkg} is happy to twiddle its
-thumbs. Let's tell \c{bpkg} to build us \c{libhello} instead:
+Why did nothing happenned? Because \c{bpkg} will only upgrade (or downgrade)
+to a new version if we explicitly ask it to. As things stand, all dependencies
+for \c{hello} are satisfied and \c{bpkg} is happy to twiddle its thumbs. Let's
+tell \c{bpkg} to build us \c{libhello} instead:
\
$ bpkg build libhello
@@ -640,7 +640,7 @@ Hello, World!
\
The important point here is this: the \c{bpkg} configuration is not some black
-box that you should never look inside. On the contrary, it is a normal and
+box that you should never look inside of. On the contrary, it is a normal and
predictable concept of the build system and as long as you understand what you
are doing, feel free to muck around.
@@ -708,8 +708,8 @@ executable; for once things are working better on Windows.
The problem is with our installation location: the runtime linker won't look
for \c{libhello-1.0.so} in \c{/opt/hello/lib} unless we somehow tell it to
-(for example, using \c{LD_LIBRARY_PATH} or equivalent). There are several way
-we can resolve this. We could give up on shared libraries and link our
+(for example, using \c{LD_LIBRARY_PATH} or equivalent). There are several
+ways we can resolve this. We could give up on shared libraries and link our
prerequisite libraries statically (\c{config.bin.exe.lib=static}). Or we could
use the \i{rpath} mechanism:
@@ -1112,7 +1112,7 @@ updated libhello/1.0.0
updated hello2/1.0.0
\
-Are you still here? Ok, one last example. Let's see how hard it is to
+Are you still there? Ok, one last example. Let's see how hard it is to
cross-compile.
\