Spell-check Boost.Build .adoc files [ci skip] (bfgroup#319)

doc/src/abstract-target.adoc

@@ -52,7 +52,7 @@ Returns a user-readable name for this target.
 +
 Generates virtual targets for this abstract target using the specified
 properties, unless a different value of some feature is required by the
-target. This is an abstract method which must be overriden by derived
+target. This is an abstract method which must be overridden by derived
 classes.
 +
 On success, returns:

doc/src/architecture.adoc

@@ -52,7 +52,7 @@ to the `generators.construct` function.
 `run` method is called. The method returns a list of virtual targets.
 4.  The virtual targets are returned to the top level code, and for each
 instance, the `actualize` method is called to setup nodes and updating
-actions in the depenendency graph kepts inside Boost.Build engine. This
+actions in the dependency graph kept inside Boost.Build engine. This
 dependency graph is then updated, which runs necessary commands.
 
 [[bbv2.arch.build.metatargets]]

doc/src/basic-target.adoc

@@ -46,5 +46,5 @@ On success, returns:
 +
 Constructs virtual targets for this abstract target. Returns a
 usage-requirements property-set and a list of virtual targets. Should be
-overriden in derived classes.
+overridden in derived classes.
 --

doc/src/extending.adoc

@@ -4,9 +4,9 @@
 [[bbv2.extender.intro]]
 == Introduction
 
-This section explains how to extend Boost.Build to accomodate your local
+This section explains how to extend Boost.Build to accommodate your local
 requirements -- primarily to add support for non-standard tools you
-have. Before we start, be sure you have read and understoon the concept
+have. Before we start, be sure you have read and understood the concept
 of metatarget, <<bbv2.overview.concepts>>, which is critical to
 understanding the remaining material.
 
@@ -370,7 +370,7 @@ created. That object has specific types of targets that it accepts and
 produces. Using that information, Boost.Build is able to automatically
 invoke the generator. For example, if you declare a generator that takes
 a target of the type `D` and produces a target of the type `OBJ`, when
-placing a file with extention `.d` in a list of sources will cause
+placing a file with extension `.d` in a list of sources will cause
 Boost.Build to invoke your generator, and then to link the resulting
 object file into an application. (Of course, this requires that you
 specify that the `.d` extension corresponds to the `D` type.)
@@ -421,7 +421,7 @@ linker.
 
 You should also know about two specific functions for registering
 generators: `generators.register-c-compiler` and
-`generators.register-linker`. The first sets up header dependecy
+`generators.register-linker`. The first sets up header dependency
 scanning for C files, and the seconds handles various complexities like
 searched libraries. For that reason, you should always use those
 functions when adding support for compilers and linkers.
@@ -497,7 +497,7 @@ all targets the executable depends on, and we further find files that
 are not produced from anything. The found targets are added to the
 sources.
 
-The `run` method can be overriden to completely customize the way the
+The `run` method can be overridden to completely customize the way the
 generator works. In particular, the conversion of sources to the desired
 types can be completely customized. Here's another real example. Tests
 for the Boost Python library usually consist of two parts: a Python
@@ -580,7 +580,7 @@ actions inline-file
 ----
 
 We first define a new feature. Then, the `flags` invocation says that
-whenever verbatin.inline-file action is run, the value of the
+whenever verbatim.inline-file action is run, the value of the
 `verbatim-options` feature will be added to the `OPTIONS` variable, and
 can be used inside the action body. You'd need to consult online help
 (--help) to find all the features of the `toolset.flags` rule.
@@ -619,14 +619,14 @@ options.
 command-line flags in your Jamfile, and it will be more likely to work
 with other tools.
 
-*Steps for adding a feauture*
+*Steps for adding a feature*
 
 Adding a feature requires three steps:
 
 1.  Declaring a feature. For that, the "feature.feature" rule is used.
 You have to decide on the set of
 link:#bbv2.reference.features.attributes[feature attributes]:
-* if you want a feature value set for one target to automaticaly
+* if you want a feature value set for one target to automatically
 propagate to its dependant targets then make it “propagated”.
 * if a feature does not have a fixed list of values, it must be “free.”
 For example, the `include` feature is a free feature.
@@ -685,7 +685,7 @@ internal target name in `DEF_FILE` to a corresponding filename in the
 `link` action. Without it the expansion of `$(DEF_FILE)` would be a
 strange symbol that is not likely to make sense for the linker.
 +
-We are almost done, except for adding the follwing code to `msvc.jam`:
+We are almost done, except for adding the following code to `msvc.jam`:
 +
 ----
 rule link
@@ -837,7 +837,7 @@ module several times. You need to check for this and decide what to do.
 Typically, unless you support several versions of a tool, duplicate
 initialization is a user error. If the tool's version can be specified
 during initialization, make sure the version is either always specified,
-or never specified (in which case the tool is initialied only once). For
+or never specified (in which case the tool is initialized only once). For
 example, if you allow:
 +
 ----

doc/src/faq.adoc

@@ -114,7 +114,7 @@ intention in such cases.
 Many users would like to use environment variables in Jamfiles, for
 example, to control the location of external libraries. In many cases it
 is better to declare those external libraries in the site-config.jam
-file, as documented in the link:#bbv2.recipies.site-config[recipes
+file, as documented in the link:#bbv2.recipes.site-config[recipes
 section]. However, if the users already have the environment variables
 set up, it may not be convenient for them to set up their
 site-config.jam files as well and using the environment variables might
@@ -314,7 +314,7 @@ systems differ in this respect. For example, the Debian GNU guidelines
 prohibit any additional search paths while Solaris guidelines suggest
 that they should always be used.
 
-[[bbv2.recipies.site-config]]
+[[bbv2.recipes.site-config]]
 == Targets in site-config.jam
 
 It is desirable to declare standard libraries available on a given

doc/src/overview.adoc

@@ -137,7 +137,7 @@ into modules—there is one global module and a number of named modules.
 Besides that, a link:#bbv2.jam[Boost.Jam] program contains classes and
 class instances.
 
-Syntantically, a link:#bbv2.jam[Boost.Jam] program consists of two kinds
+Syntactically, a link:#bbv2.jam[Boost.Jam] program consists of two kinds
 of elements—keywords (which have a special meaning to
 link:#bbv2.jam[Boost.Jam]) and literals. Consider this code:
 
@@ -707,7 +707,7 @@ either `SYMBOL` or `SYMBOL=VALUE`
 
 |runtime-link
 |shared,static
-|Determines if shared or static version of C and C++ runtimes should be used.
+|Determines if shared or static version of C and C++ runtime should be used.
 |===
 
 If you have more than one version of a given C++ toolset (e.g.
@@ -817,7 +817,7 @@ obtained from main target name by appending system-dependent suffixes
 and prefixes.
 
 The name of a main target can contain alphanumeric characters, dashes,
-undescores and dots. The entire name is significant when resolving
+underscores and dots. The entire name is significant when resolving
 references from other targets. For determining filenames, only the part
 before the first dot is taken. For example:
 

doc/src/property-set.adoc

@@ -28,7 +28,7 @@ Returns a Jam list of the stored properties.
 
 2. `rule str ( )`
 +
-Returns the string repesentation of the stored properties.
+Returns the string representation of the stored properties.
 
 3. `rule propagated ( )`
 +

doc/src/recipes.adoc

@@ -1,3 +1,3 @@
-[[bbv2.recipies]]
+[[bbv2.recipes]]
 Boost.Build System V2 recipes
 -----------------------------

doc/src/reference.adoc

@@ -507,7 +507,7 @@ will not affect target paths, and will not cause conflicts.
 ** It is relevant for any dependency created by the same main target
 ** It is used in the condition of a conditional property and the corresponding
   value is relevant
-** It is explicitly named as relevent
+** It is explicitly named as relevant
 +
 * Relevant features cannot be automatically deduced in the following cases:
 +

doc/src/tasks.adoc

@@ -118,7 +118,7 @@ lib aux : : <name>aux ;
 When a library references another library you should put that other
 library in its list of sources. This will do the right thing in all
 cases. For portability, you should specify library dependencies even for
-searched and prebuilt libraries, othewise, static linking on Unix will
+searched and prebuilt libraries, otherwise, static linking on Unix will
 not work. For example:
 
 [source]
@@ -411,7 +411,7 @@ boost-test(test-type) path : sources
 ----
 
 It is possible to process the list of tests, Boost.Build output and the
-presense/absense of the `*.test` files created when test passes into
+presence/absence of the `*.test` files created when test passes into
 human-readable status table of tests. Such processing utilities are not
 included in Boost.Build.
 
@@ -434,7 +434,7 @@ unit-test helpers_test
 
 Specifies a file to be passed to the executable on the command line
 after the arguments. All files must be specified in alphabetical order
-due to constrainsts in the current implementation.
+due to constraints in the current implementation.
 
 `testing.launcher`::
 
@@ -476,7 +476,7 @@ commands to run explicitly.
 Three main target rules can be used for that. The `make` rule allows you to
 construct a single file from any number of source file, by running a command
 you specify. The `notfile` rule allows you to run an arbitrary command,
-without creating any files. And finaly, the `generate` rule allows you to
+without creating any files. And finally, the `generate` rule allows you to
 describe a transformation using Boost.Build's virtual targets. This is
 higher-level than the file names that the `make` rule operates with and
 allows you to create more than one target, create differently named targets
@@ -712,7 +712,7 @@ use-packages "packages.jam" ;
 **`--use-package-manager` command line option:**
 
 The `--use-package-manager=NAME` command line option allows one to
-non-instrusively specify per invocation which of the built-in package manager
+non-intrusively specify per invocation which of the built-in package manager
 types to use.
 
 **`PACKAGE_MANAGER_BUILD_INFO` variable:**

doc/src/tutorial.adoc

@@ -124,7 +124,7 @@ link:#bbv2.tutorial.hierarchy[the section called “Project Hierarchies”]).
 For example, the locations of `#include`d header files are normally not
 specified on the command-line, but described in Jamfiles as _target
 requirements_ and automatically combined with the build request for those
-targets. Multithread-enabled compilation is another example of a typical
+targets. Multi-threaded compilation is another example of a typical
 target requirement. The Jamfile fragment below illustrates how these
 requirements might be specified.
 
@@ -138,7 +138,7 @@ exe hello
 
 When `hello` is built, the two requirements specified above will always
 be present. If the build request given on the `b2` command-line
-explictly contradicts a target's requirements, the target requirements
+explicitly contradicts a target's requirements, the target requirements
 usually override (or, in the case of “free” features like
 `<include>`, footnote:[See
 link:#bbv2.reference.features.attributes[the section called “Feature Attributes”]]
@@ -549,5 +549,5 @@ lib pythonlib : : <name>python22_d <variant>debug ;
 ----
 
 A more advanced use of prebuilt targets is described in
-link:#bbv2.recipies.site-config[the section called “Targets in
+link:#bbv2.recipes.site-config[the section called “Targets in
 site-config.jam”].