[Boost-build] More patches...

From: Jurko Gospodnetiæ (jurko.gospodnetic_at_[hidden])
Date: 2007-12-27 07:11:24

   Hi.

   See the attached patch files for comments on what they contain but 
mostly stylistic changes (typo corrections, removed extra imports, 
wrapped lines to 80 characters, error message updates...).

   Best regards,
     Jurko Gospodnetiæ

Stylistic comment changes & typo corrections in several files. Corrected an
incorrect error message in boost-build/build/project.jam displayed when a
--build-dir command-line option and a non top-level project build-dir attribute
are specified.

Left base folder: X:\Boost_Build\20071225_nightly_build\Original
Right base folder: X:\Boost_Build\20071225_nightly_build\Modified
--- boost-build\build\project.jam	2007-12-25 15:33:36.000000000 +-0100
+++ boost-build\build\project.jam	2007-12-27 12:46:13.000000000 +-0100
@@ -9,34 +9,34 @@
 #   - a module where all the Jamfile content live. 
 #   - an instance of 'project-attributes' class.
 #     (given module name, can be obtained by 'attributes' rule)
 #   - an instance of 'project-target' class (from targets.jam)
 #     (given a module name, can be obtained by 'target' rule)
 #
-#  Typically, projects are created as result of loading Jamfile, which is
-#  do by rules 'load' and 'initialize', below. First, module for Jamfile
-#  is loaded and new project-attributes instance is created. Some rules
-#  necessary for project are added to the module (see 'project-rules' module)
-#  at the bottom of this file.
-#  Default project attributes are set (inheriting attributes of parent project, if
-#  it exists). After that, Jamfile is read. It can declare its own attributes,
-#  via 'project' rule, which will be combined with already set attributes.
-#
+#  Typically, projects are created as result of loading a Jamfile, which is done
+#  by rules 'load' and 'initialize', below. First, module for Jamfile is loaded
+#  and new project-attributes instance is created. Some rules necessary for
+#  project are added to the module (see 'project-rules' module) at the bottom of
+#  this file. Default project attributes are set (inheriting attributes of
+#  parent project, if it exists). After that, Jamfile is read. It can declare
+#  its own attributes, via 'project' rule, which will be combined with already
+#  set attributes.
 #
 #  The 'project' rule can also declare project id, which will be associated with 
 #  the project module.
 #
-#  There can also be 'standalone' projects. They are created by calling 'initialize'
-#  on arbitrary module, and not specifying location. After the call, the module can
-#  call 'project' rule, declare main target and behave as regular projects. However,
-#  since it's not associated with any location, it's better declare only prebuilt 
-#  targets.
+#  There can also be 'standalone' projects. They are created by calling
+#  'initialize' on arbitrary module, and not specifying location. After the
+#  call, the module can call 'project' rule, declare main target and behave as
+#  regular projects. However, since it's not associated with any location, it's
+#  better declare only prebuilt targets.
 #
-#  The list of all loaded Jamfile is stored in variable .project-locations. It's possible
-#  to obtain module name for a location using 'module-name' rule. The standalone projects
-#  are not recorded, the only way to use them is by project id.
+#  The list of all loaded Jamfile is stored in variable .project-locations. It's
+#  possible to obtain module name for a location using 'module-name' rule. The
+#  standalone projects are not recorded, the only way to use them is by project
+#  id.
 
 
 import modules : peek poke ;
 import numbers ;
 import path ;
 import sequence ;
@@ -64,21 +64,21 @@
     local module-name = [ module-name $(jamfile-location) ] ;            
     # If Jamfile is already loaded, don't try again.
     if ! $(module-name) in $(.jamfile-modules)
     {      
         load-jamfile $(jamfile-location) ;
                 
-        # We want to make sure that child project are loaded only
-        # after parent projects. In particular, because parent projects
-        # define attributes whch are inherited by children, and we don't
-        # want children to be loaded before parents has defined everything.
+        # We want to make sure that child project are loaded only after parent
+        # projects. In particular, because parent projects define attributes
+        # which are inherited by children, and we don't want children to be
+        # loaded before parents has defined everything.
         #
-        # While "build-project" and "use-project" can potentially refer
-        # to child projects from parent projects, we don't immediately
-        # loading child projects when seing those attributes. Instead,
-        # we record the minimal information that will be used only later.
+        # While "build-project" and "use-project" can potentially refer to child
+        # projects from parent projects, we don't immediately loading child
+        # projects when seing those attributes. Instead, we record the minimal
+        # information that will be used only later.
         load-used-projects $(module-name) ;
     }                
     return $(module-name) ;        
 }
 
 rule load-used-projects ( module-name )
@@ -908,22 +908,20 @@
                 }                
             }                
             else 
             {
                 # Not Jamroot
                 if $(explicit-build-dir)
-                {                    
-                    errors.user-error "When --build-dir is specified, the 'build-project'"
-                      : "attribute is allowed only for top-level 'project' invocations" ;                      
-                }                
-            }                
+                {
+                    errors.user-error "When --build-dir is specified, the 'build-dir' project"
+                      : "attribute is allowed only for top-level 'project' invocations" ;
+                }
+            }
         }
-        
-
     }
-    
+
     # Declare and set a project global constant. Project global constants are
     # normal variables but should not be changed. They are applied to every
     # child Jamfile.
     #
     rule constant (
         name # Variable name of the constant.
--- boost-build\doc\src\architecture.xml	2007-12-25 15:33:36.000000000 +-0100
+++ boost-build\doc\src\architecture.xml	2007-12-27 12:34:11.000000000 +-0100
@@ -331,13 +331,13 @@
     <listitem>
       <simpara>
       Since almost always Boost.Build generates targets to a
     "bin" directory, it should be supported as well. I.e. in the
     scanario above, Jamfile in "dir" might create a main target,
     which generates "a.h". The file will be generated to "dir/bin"
-    directory, but we still have to recornize the dependency.
+    directory, but we still have to recognize the dependency.
       </simpara>
     </listitem>
   </orderedlist>
 
   <para>The first requirement means that when determining what "a.h"
   means, when found in "a.cpp", we have to iterate over all
--- boost-build\doc\src\tutorial.xml	2007-12-25 15:33:36.000000000 +-0100
+++ boost-build\doc\src\tutorial.xml	2007-12-27 12:39:14.000000000 +-0100
@@ -602,19 +602,18 @@
 <programlisting>
 lib demangler : dummy_demangler.cpp ;                      # alternative 1
 lib demangler : demangler_gcc.cpp : &lt;toolset&gt;gcc ;   # alternative 2
 lib demangler : demangler_msvc.cpp : &lt;toolset&gt;msvc ; # alternative 3
 </programlisting>
       When building <filename>demangler</filename>, Boost.Build will compare
-      requirements for each alternative with build properties to find the best match.
-      For example, when building with with <code>&lt;toolset&gt;gcc</code> 
-      alternative 2, will be selected, and when building with 
-      <code>&lt;toolset&gt;msvc</code> alternative 3 will be selected. In all other
-      cases, the most generic alternative 1 will be built.
+      requirements for each alternative with build properties to find the best
+      match. For example, when building with <code>&lt;toolset&gt;gcc</code> 
+      alternative 2, will be selected, and when building with
+      <code>&lt;toolset&gt;msvc</code> alternative 3 will be selected. In all
+      other cases, the most generic alternative 1 will be built.
     </para>
-    
   </section>
 
   <section id="bbv2.tutorial.prebuilt">
     <title>Prebuilt targets</title>
 
     <para>
--- boost-build\test\library_property.py	2007-12-25 15:33:36.000000000 +-0100
+++ boost-build\test\library_property.py	2007-12-27 12:39:22.000000000 +-0100
@@ -8,13 +8,13 @@
 #  Previously, it affected all targets, so
 #
 #     project : requirements <library>foo ;
 #     exe a : a.cpp helper ;
 #     obj helper : helper.cpp : <optimization>off ;
 #
-#  caused 'foo' to be built with with and without optimization.
+#  caused 'foo' to be built with and without optimization.
 from BoostBuild import Tester, List
 
 # Create a temporary working directory
 t = Tester()
 
 t.write("Jamfile", """ 
--- boost-build\tools\gettext.jam	2007-12-25 15:33:36.000000000 +-0100
+++ boost-build\tools\gettext.jam	2007-12-27 12:36:08.000000000 +-0100
@@ -205,17 +205,16 @@
     gettext.update-po $(<) : $(>) ;
     _ on $(<) = " " ;    
     ok on $(<) = "" ;
     EXISTING_PO on $(<) = $(>[1]) ;
 }
 
-# Due to fancy interaction of existing and updated, this rule
-# can be called with with one source, in which case we copy
-# the lonely source into EXISTING_PO, or with two sources,
-# in which case the action body expands to nothing.
-# I'd really like to have "missing" action modifier.
+# Due to fancy interaction of existing and updated, this rule can be called with
+# one source, in which case we copy the lonely source into EXISTING_PO, or with
+# two sources, in which case the action body expands to nothing. I'd really like
+# to have "missing" action modifier.
 actions quietly existing updated create-po bind EXISTING_PO
 {
     cp$(_)"$(>[1])"$(_)"$(EXISTING_PO)"$($(>[2]:E=ok))    
 }
 
 actions updated update-po bind EXISTING_PO

Stylistic comment changes & typo corrections.

Left base folder: C:\Documents and Settings\Jurko\Desktop\Boost_Build\20071225_nightly_build\Modified2
Right base folder: C:\Documents and Settings\Jurko\Desktop\Boost_Build\20071225_nightly_build\Modified3
--- boost-build\build\property.jam	2007-12-25 15:33:36.000000000 +-0100
+++ boost-build\build\property.jam	2007-12-27 13:03:21.000000000 +-0100
@@ -84,15 +84,15 @@
     else
     {
         return [ unique $(result) $(requirements) ] ;
     }
 }
 
-# Removes all conditional properties which conditions are not met
-# For those with met conditions, removes the condition. Properies
-# in conditions are looked up in 'context'
+# Removes all conditional properties which conditions are not met. For those
+# with met conditions, removes the condition. Properties in conditions are
+# looked up in 'context'.
 rule evaluate-conditionals-in-context ( properties * : context * )
 {
     local base ;
     local conditionals ;
     for local p in $(properties)
     {
--- boost-build\doc\src\reference.xml	2007-12-25 15:33:36.000000000 +-0100
+++ boost-build\doc\src\reference.xml	2007-12-27 13:00:30.000000000 +-0100
@@ -1433,16 +1433,16 @@
       <para>When there are several alternatives, one of them must be
         selected. The process is as follows:</para>
       
       <orderedlist>
         <listitem>
           <simpara>
-            For each alternative <emphasis>condition</emphasis> is defined
-            as the set of base properies in requirements. [Note: it might be
-            better to specify the condition explicitly, as in
-            conditional requirements].
+            For each alternative <emphasis>condition</emphasis> is defined as
+            the set of base properties in requirements. [Note: it might be
+            better to specify the condition explicitly, as in conditional
+            requirements].
           </simpara>
         </listitem>
         
         <listitem>
           <simpara>
             An alternative is viable only if all properties in condition
--- boost-build\util\doc.jam	2007-12-25 15:33:36.000000000 +-0100
+++ boost-build\util\doc.jam	2007-12-27 13:05:20.000000000 +-0100
@@ -844,16 +844,16 @@
     if $(class-parts[1]) = "class" || $(class-parts[1]) = "class.class"
     {
         set-class-doc $(class-parts[2]) $(module-name) : $(class-parts[3]) ;
     }
 }
 
-# Scan a module file for documentation comments. This also
-# invokes any actions assigned to the module. The actions
-# are the rules that do the actual output of the documentation.
-# This rue is invoked as the header scan rule for the module file.
+# Scan a module file for documentation comments. This also invokes any actions
+# assigned to the module. The actions are the rules that do the actual output of
+# the documentation. This rule is invoked as the header scan rule for the module
+# file.
 #
 rule scan-module (
     target # The module file.
     : text * # The text in the file, one item per line.
     : action * # Rule to call to output docs for the module.
     )

Cleaned up some import rule calls.

--- X:\Boost_Build\20071225_nightly_build\Original\boost-build\build\project.jam	2007-12-27 12:46:13.000000000 +-0100
+++ X:\Boost_Build\20071225_nightly_build\Modified\boost-build\build\project.jam	2007-12-27 12:55:46.000000000 +-0100
@@ -32,24 +32,19 @@
 #
 #  The list of all loaded Jamfile is stored in variable .project-locations. It's
 #  possible to obtain module name for a location using 'module-name' rule. The
 #  standalone projects are not recorded, the only way to use them is by project
 #  id.
 
-
-import modules : peek poke ;
-import numbers ;
+import "class" : new ;
+import errors ;
+import modules ;
 import path ;
-import sequence ;
-import errors : error ;
-
 import print ;
-import "class" : new ;
-import errors ;
-import assert ;
 import property-set ;
+import sequence ;
 
 #
 #   Loads jamfile at the given location. After loading, project global
 #   file and jamfile needed by the loaded one will be loaded recursively.
 #   If the jamfile at that location is loaded already, does nothing.
 #   Returns the project module for the Jamfile.
@@ -98,13 +93,13 @@
 }
 
 
 # Note the use of character groups, as opposed to listing
 # 'Jamroot' and 'jamroot'. With the latter, we'd get duplicate
 # matches on windows and would have to eliminate duplicates.
-JAMROOT ?= [ peek : JAMROOT ] ;
+JAMROOT ?= [ modules.peek : JAMROOT ] ;
 JAMROOT ?= project-root.jam [Jj]amroot [Jj]amroot.jam ;
 
 # Loads parent of Jamfile at 'location'. Issues an error if nothing is found.
 rule load-parent ( location )
 {
     local found = [ path.glob-in-parents $(location) :