[Boost-commit] svn:boost r42478 - trunk/tools/build/v2

From: jurko_at_[hidden]
Date: 2008-01-05 10:19:53

Author: jurko
Date: 2008-01-05 10:19:53 EST (Sat, 05 Jan 2008)
New Revision: 42478
URL: http://svn.boost.org/trac/boost/changeset/42478

Log:
Typo corrections. Minor stylistic changes.
Text files modified: 
   trunk/tools/build/v2/hacking.txt |    80 ++++++++++++++++++++--------------------
   1 files changed, 40 insertions(+), 40 deletions(-)

Modified: trunk/tools/build/v2/hacking.txt
==============================================================================
--- trunk/tools/build/v2/hacking.txt	(original)
+++ trunk/tools/build/v2/hacking.txt	2008-01-05 10:19:53 EST (Sat, 05 Jan 2008)
@@ -1,20 +1,20 @@
-Copyright 2003, 2006 Vladimir Prus 
-Distributed under the Boost Software License, Version 1.0. 
-(See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt) 
+Copyright 2003, 2006 Vladimir Prus
+Distributed under the Boost Software License, Version 1.0.
+(See accompanying file LICENSE_1_0.txt or http://www.boost.org/LICENSE_1_0.txt)
 
 
              ----------------------------------
              Boost.Build contributor guidelines
              ----------------------------------
 
-Boost.Build is an open-source project. This means that we welcome and
-appreciate all contributions --- be it ideas, bug reports, or patches.
-This document contains guidelines which helps to assure that development
-goes on smoothly, and changes are made quickly. 
-
-The guidelines are not mandatory, and you can decide for yourself which one 
-to follow. But note, that 10 mins that you spare writing a comment, for
-example, might lead to significally longer delay for everyone.
+Boost.Build is an open-source project. This means that we welcome and appreciate
+all contributions --- be it ideas, bug reports, or patches. This document
+contains guidelines which helps to assure that development goes on smoothly, and
+changes are made quickly.
+
+The guidelines are not mandatory, and you can decide for yourself which one to
+follow. But note, that 10 mins that you spare writing a comment, for example,
+might lead to significally longer delay for everyone.
 
 Before contributing, make sure you are subscribed to our mailing list
 
@@ -25,7 +25,7 @@
    - The issue tracker
      http://zigzag.cs.msu.su/boost.build
 
-   - commits mailing list: 
+   - commits mailing list:
      boost-build_at_[hidden]
      http://sourceforge.net/mailarchive/forum.php?forum_id=9097
 
@@ -37,8 +37,8 @@
 When reporting a bug, please try to provide the following information.
 
    - What you did. A minimal reproducible testcase is very much appreciated.
-     Shell script with some annotations is much better than verbose description of
-     the problem. A regression test is the best (see test/test_system.html).
+     Shell script with some annotations is much better than verbose description
+     of the problem. A regression test is the best (see test/test_system.html).
    - What you got.
    - What you expected.
    - What version of Boost.Build and Boost.Jam did you use. If possible,
@@ -53,48 +53,48 @@
   - provide a log message together with the patch
   - put the patch and the log message as attachment to your email.
 
-The purpose of log message serves to communicate what was changed, and
-*why*. Without a good log message, you might spend a lot of time later,
-wondering where a strange piece of code came from and why it was necessary.
+The purpose of log message serves to communicate what was changed, and *why*.
+Without a good log message, you might spend a lot of time later, wondering where
+a strange piece of code came from and why it was necessary.
 
 The good log message mentions each changed file and each rule/method, saying
 what happend to it, and why. Consider, the following log message
 
     Better direct request handling.
-     
+
      * new/build-request.jam
        (directly-requested-properties-adjuster): Redo.
-       
+
      * new/targets.jam
        (main-target.generate-really): Adjust properties here.
-     
+
      * new/virtual-target.jam
        (register-actual-name): New rule.
        (virtual-target.actualize-no-scanner): Call the above, to detected bugs,
        where two virtual target correspond to one Jam target name.
- 
-The log messages for the last two files are good. They tell what was
-changed. The change to the first file is clearly undercommented.
 
-It's OK to use terse log messages for uninteresting changes, like
-ones induces by interface changes elsewhere. 
+The log messages for the last two files are good. They tell what was changed.
+The change to the first file is clearly undercommented.
+
+It's OK to use terse log messages for uninteresting changes, like ones induced
+by interface changes elsewhere.
 
 
 POLICIES.
 
 1. Testing.
 
-All serious changes must be tested. New rules must be tested by the module
-where they are declared. Test system (test/test_system.html) should be used
-to verify user-observable behaviour.
+All serious changes must be tested. New rules must be tested by the module where
+they are declared. Test system (test/test_system.html) should be used to verify
+user-observable behaviour.
 
 2. Documentation.
 
-It turns out that it's hard to have too much comments, but it's easy to have
-too little. Please prepend each rule with a comment saying what the rule does
-and what arguments mean. Stop for a minute and consider if the comment makes
-sense for anybody else, and completely describes what the rules does. Generic
-phrases like "adjusts properties" are really not enough.
+It turns out that it's hard to have too much comments, but it's easy to have too
+little. Please prepend each rule with a comment saying what the rule does and
+what arguments mean. Stop for a minute and consider if the comment makes sense
+for anybody else, and completely describes what the rules does. Generic phrases
+like "adjusts properties" are really not enough.
 
 When applicable, make changes to the user documentation as well.
 
@@ -106,8 +106,8 @@
 
         rule call-me-ishmael ( ) ...
 
-    2. Names with dots in them are "intended globals". Ordinary globals use
-    a dot prefix:
+    2. Names with dots in them are "intended globals". Ordinary globals use a
+    dot prefix:
 
         .foobar
         $(.foobar)
@@ -142,12 +142,12 @@
     Please pass HTML files though HTML Tidy (http://tidy.sf.net) before
     comitting. This has to important purposes:
     - detecting bad HTML
-    - converting files to uniform indentation style, which inverses effect
-      of different editors and makes differences between revisions much
-      smaller and easy for review.
+    - converting files to uniform indentation style, which inverses effect of
+      different editors and makes differences between revisions much smaller and
+      easy for review.
 
-    Alas, the way Tidy indents HTML differs between version. Please use
-    the version awailable at
+    Alas, the way Tidy indents HTML differs between version. Please use the
+    version available at
 
        http://tidy.sourceforge.net/src/old/tidy_src_020411.tgz