Adjust docs to mention Jamfile as root project.

Changed the doc language to make Jamfile a possible root project. And
a clarification for when that happens. Also made some spelling fixes and
HTML style improvements.

doc/src/b2.css

@@ -2,23 +2,39 @@
 	font-size: 2.5em;
 	text-shadow: 1px 1px 2px rgba(0, 0, 0, .5);
 }
-
 .caution .icon .title {
 	color: rgba(192, 51, 0, 1);
 }
-
 .important .icon .title {
 	color: rgba(192, 0, 0, 1);
 }
-
 .note .icon .title {
 	color: rgba(26, 64, 128, 1);
 }
-
 .tip .icon .title {
 	color: rgba(255, 192, 0, 1);
 }
-
 .warning .icon .title {
 	color: rgba(192, 102, 0, 1);
 }
+p,blockquote,dt,td.content,span.alt {
+    font-size: 1.1rem
+}
+h1, h2, h3, h4, h5, h6 {
+    font-weight: bold;
+}
+h1 {
+    font-size: 2.25em;
+}
+h2 {
+    font-size: 1.5em;
+}
+h3,#toctitle,.sidebarblock>.content>.title {
+    font-size: 1.3em;
+}
+h4, h5 {
+    font-size: 1.2em;
+}
+h6 {
+    font-size: 1.1em;
+}

doc/src/overview.adoc

@@ -41,7 +41,7 @@ Boost.Build has a few unique concepts that are introduced in this
 section. The best way to explain the concepts is by comparison with more
 classical build tools.
 
-When using any flavour of make, you directly specify _targets_ and
+When using any flavor of make, you directly specify _targets_ and
 commands that are used to create them from other target. The below
 example creates `a.o` from `a.c` using a hardcoded compiler invocation
 command.
@@ -71,8 +71,8 @@ immediately when the build description is parsed, which makes it
 impossible to perform multi-variant builds. Often, change in any build
 property requires a complete reconfiguration of the build tree.
 
-In order to support true multivariant builds, Boost.Build introduces the
-concept of a metatarget definition main target metataget
+In order to support true multi-variant builds, Boost.Build introduces the
+concept of a metatarget definition main target metatarget
 _metatarget_ -- an object that is created when the build description is
 parsed and can be called later with specific build properties to
 generate actual targets.
@@ -371,7 +371,7 @@ TIP: You can use the `--debug-configuration` option to find which
 configuration files are actually loaded.
 
 Usually, `user-config.jam` just defines the available compilers and
-other tools (see link:#bbv2.recipies.site-config[the section called “Targets
+other tools (see link:#bbv2.recipes.site-config[the section called “Targets
 in site-config.jam”] for more advanced usage). A tool is configured using
 the following syntax:
 
@@ -476,9 +476,9 @@ using gcc : 5 : : <cxxflags>"-std=c++14 -O2" ;
 using clang : 3.9 : : <cxxflags>-std=c++14 <cxxflags>-O2 ;
 ----
 
-Multiple varaiations of the same tool can be used for most tools. These
-are deliniated by the version passed in. Because the dash '-' cannot be
-used here, the convention has become to use the tilde '~' to deliniate
+Multiple variations of the same tool can be used for most tools. These
+are delineated by the version passed in. Because the dash '-' cannot be
+used here, the convention has become to use the tilde '~' to delineate
 variations.
 
 [source]
@@ -557,7 +557,7 @@ Boost.Build recognizes the following command line options.
   Invokes the online help system. This prints general information on how
   to use the help system with additional --help* options.
 `--clean`::
-  Cleans all targets in the current directory and in any subprojects.
+  Cleans all targets in the current directory and in any sub-projects.
   Note that unlike the `clean` target in make, you can use `--clean`
   together with target names to clean specific targets.
 `--clean-all`::
@@ -571,7 +571,6 @@ Boost.Build recognizes the following command line options.
   concatenating the value of the `--build-dir` option, the project name
   specified in Jamroot, and the build dir specified in Jamroot (or
   `bin`, if none is specified).
-  +
   The option is primarily useful when building from read-only media,
   when you can't modify Jamroot.
 `--abbreviate-paths`::
@@ -1081,7 +1080,7 @@ _Source location_ specifies the directory where sources for the project
 are located.
 
 _Project requirements_ are requirements that apply to all the targets in
-the projects as well as all subprojects.
+the projects as well as all sub-projects.
 
 _Default build_ is the build request that should be used when no build
 request is specified explicitly.
@@ -1119,13 +1118,14 @@ link:#bbv2.reference.rules[the section called “Builtin rules”].
 Each subproject inherits attributes, constants and rules from its parent
 project, which is defined by the nearest Jamfile in an ancestor
 directory above the subproject. The top-level project is declared in a
-file called `Jamroot` rather than `Jamfile`. When loading a project,
+file called `Jamroot`, or `Jamfile`. When loading a project,
 Boost.Build looks for either `Jamroot` or `Jamfile`. They are handled
 identically, except that if the file is called `Jamroot`, the search for
-a parent project is not performed.
+a parent project is not performed. A `Jamfile` without a parent project
+is also considered the top-level project.
 
 Even when building in a subproject directory, parent project files are
-always loaded before those of their subprojects, so that every
+always loaded before those of their sub-projects, so that every
 definition made in a parent project is always available to its children.
 The loading order of any other projects is unspecified. Even if one
 project refers to another via the `use-project` or a target reference,

doc/src/reference.adoc

@@ -544,7 +544,7 @@ The supported values have the following meaning:
 +
 By default compiler default visibility mode is used (no compiler flags are added).
 +
-NOTE: In Boost superproject Jamroot file this property is set to the default
+NOTE: In Boost super-project Jamroot file this property is set to the default
 value of `hidden`. This means that Boost libraries are built with hidden
 visibility by default, unless the user overrides it with a different `visibility`
 or a library sets a different `local-visibility` (see below).

doc/src/tutorial.adoc

@@ -10,7 +10,7 @@ use libraries, and finish with testing and installing features.
 
 The simplest project that Boost.Build can construct is stored in
 `example/hello/` directory. The project is described by a file called
-`Jamroot` that contains:
+`Jamfile` that contains:
 
 [source]
 ----
@@ -30,7 +30,7 @@ b2 release
 Note that the debug and release variants are created in different
 directories, so you can switch between variants or even build multiple
 variants at once, without any unnecessary recompilation. Let us extend
-the example by adding another line to our project's `Jamroot`:
+the example by adding another line to our project's `Jamfile`:
 
 [source]
 ----
@@ -118,7 +118,7 @@ request_—a description of the desired properties for building the
 requested targets (or, if no targets were explicitly requested, the
 project in the current directory). The _actual_ properties used for
 building targets are typically a combination of the build request and
-properties derived from the project's `Jamroot` (and its other Jamfiles,
+properties derived from the project's `Jamfile` (and its other Jamfiles,
 as described in
 link:#bbv2.tutorial.hierarchy[the section called “Project Hierarchies”]).
 For example, the locations of `#include`d header files are normally not
@@ -145,7 +145,7 @@ link:#bbv2.reference.features.attributes[the section called “Feature Attribute
 augment) the build request.
 
 TIP: The value of the `<include>` feature is relative to the location of
-`Jamroot` where it is used.
+`Jamfile` where it is used.
 
 [[bbv2.tutorial.properties.project_attributes]]
 === Project Attributes
@@ -173,18 +173,18 @@ The effect would be as if we specified the same requirement for both
 == Project Hierarchies
 
 So far we have only considered examples with one project, with one
-user-written Boost.Jam file, `Jamroot`. A typical large codebase would
+user-written `Jamfile` file. A typical large codebase would
 be composed of many projects organized into a tree. The top of the tree
 is called the _project root_. Every subproject is defined by a file called
 `Jamfile` in a descendant directory of the project root. The parent
-project of a subproject is defined by the nearest `Jamfile` or `Jamroot`
+project of a subproject is defined by the nearest Jamfile
 file in an ancestor directory. For example, in the following directory
 layout:
 
 ----
 top/
   |
-  +-- Jamroot
+  +-- Jamfile
   |
   +-- app/
   |    |
@@ -208,7 +208,7 @@ filename will be set as “`Jamfile`” or “`Jamroot`.”
 
 Projects inherit all attributes (such as requirements) from their
 parents. Inherited requirements are combined with any requirements
-specified by the subproject. For example, if `top/Jamroot` has
+specified by the subproject. For example, if `top/Jamfile` has
 
 [source]
 ----
@@ -226,7 +226,7 @@ Invoking `b2` without explicitly specifying any targets on the command
 line builds the project rooted in the current directory. Building a
 project does not automatically cause its sub-projects to be built unless
 the parent project's Jamfile explicitly requests it. In our example,
-`top/Jamroot` might contain:
+`top/Jamfile` might contain:
 
 [source]
 ----
@@ -308,7 +308,7 @@ can be used by many targets, and if they all use `Jamfile` location, a change
 in directory organization entails much work.
 The solution is to use project ids—symbolic names not tied to directory
 layout. First, we need to assign a project id by adding this code to
-`Jamroot`:
+`Jamfile`:
 
 [source]
 ----
@@ -324,8 +324,8 @@ exe app : app.cpp /library-example/foo//bar ;
 
 The `/library-example/foo//bar` syntax is used to refer to the target
 `bar` in the project with id `/library-example/foo`. We've achieved our
-goal—if the library is moved to a different directory, only `Jamroot` must be
-modified. Note that project ids are global—two Jamfiles
+goal—if the library is moved to a different directory, only `top/Jamfile`
+must be modified. Note that project ids are global—two Jamfiles
 are not allowed to assign the same project id to different directories.
 
 [TIP]