Imported Upstream version 2.0.0upstream/2.0.0

4 files changed, 11 insertions, 11 deletions

diff --git a/doc/design/engine.xml b/doc/design/engine.xml
index 1a1e335..afe9877 100644
--- a/doc/design/engine.xml
+++ b/doc/design/engine.xml
@@ -85,7 +85,7 @@
 
 
 <section id="sect-envs">
- <title>&ConsEnvs</title>
+ <title>&ConsEnvs;</title>
 
  <para>
 
@@ -129,7 +129,7 @@
    <footnote>
     <para>
      It would be nice if we could avoid re-inventing the wheel here by
-     using some other Python-based tool &Autoconf replacement--like what
+     using some other Python-based tool &Autoconf; replacement--like what
      was supposed to come out of the Software Carpentry configuration
      tool contest.  It will probably be most efficient to roll our own
      logic initially and convert if something better does come along.
@@ -283,7 +283,7 @@
 	MyBuilder = Builder(command = "$XX $XXFLAGS -c $_INPUTS -o $target")
 
 	env.Command(targets = 'bar.out', sources = 'bar.in',
-	            command = "sed '1d' < $source > $target")
+	            command = "sed '1d' &lt; $source > $target")
 	</programlisting>
 
   <para>
@@ -317,7 +317,7 @@
 	<programlisting>
 	env = Environment(FUNC = myfunc)
 	env.Command(target = 'foo.out', source = 'foo.in',
-	            command = "${FUNC($<)}")
+	            command = "${FUNC($&lt;)}")
 	</programlisting>
 
   <para>
@@ -1678,8 +1678,8 @@ I dunno, maybe this is fine as it is...
      <literal>target</literal> (that is, one passed to the
      &Build; or &Clean; method).  Objects which a top-level
      <literal>target</literal> is directly dependent upon have a
-     <literal>level</literal> of <1>, their direct dependencies have a
-     <literal>level</literal> of <2>, etc.  Typically used to indent
+     <literal>level</literal> of &lt;1>, their direct dependencies have a
+     <literal>level</literal> of &lt;2>, etc.  Typically used to indent
      output to reflect the recursive levels.
 
     </para>
diff --git a/doc/design/goals.xml b/doc/design/goals.xml
index 2a7b69b..f2e6b7c 100644
--- a/doc/design/goals.xml
+++ b/doc/design/goals.xml
@@ -26,7 +26,7 @@
  <para>
 
    As a next-generation build tool,
-   &SCons should fundamentally
+   &SCons; should fundamentally
    improve on its predecessors.
    Rather than simply being driven by trying to
    <emphasis>not</emphasis> be like previous tools,
diff --git a/doc/design/native.xml b/doc/design/native.xml
index 8cdd867..c665e0c 100644
--- a/doc/design/native.xml
+++ b/doc/design/native.xml
@@ -52,7 +52,7 @@
  <para>
 
   By default, the &SCons; utility searches for a file named
-  &SConstruct;, &Sconstruct; or &sconstruct (in that order) in the
+  &SConstruct;, &Sconstruct; or &sconstruct; (in that order) in the
   current directory, and reads its configuration from the first file
   found.  A <option>-f</option> command-line option exists to read a
   different file name.
@@ -175,7 +175,7 @@
 
   Any variables (not just &SCons; objects) that are to be shared between configuration files must be
   explicitly passed in the &SConscript; call
-  using the &Export method:
+  using the &Export; method:
 
  </para>
 
@@ -261,7 +261,7 @@ Equivalent to the above example:
 
  <para>
 
-  &SCons; will allow users to share &consenvs, as well as other &SCons;
+  &SCons; will allow users to share &consenvs;, as well as other &SCons;
   objects and Python variables, by importing them from a central, shared
   repository using normal Python syntax:
 
diff --git a/doc/design/overview.xml b/doc/design/overview.xml
index 38e4258..266c9e8 100644
--- a/doc/design/overview.xml
+++ b/doc/design/overview.xml
@@ -409,7 +409,7 @@ This is where it will go, anyway...
   <para>
 
    An alternate &SCons; interface would provide backwards
-   compatibility with the classic &Make utility.
+   compatibility with the classic &Make; utility.
    This would be done by embedding the &SCons; Build Engine
    in a Python script that can translate existing
    &Makefile;s into the underlying calls to the