From d780dd7fc6fdcbe812a7ef7a2ad8ecbb2ee9b340 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jurko=20Gospodneti=C4=87?= Date: Sat, 5 Jan 2008 15:19:53 +0000 Subject: [PATCH] Typo corrections. Minor stylistic changes. [SVN r42478] --- v2/hacking.txt | 78 +++++++++++++++++++++++++------------------------- 1 file changed, 39 insertions(+), 39 deletions(-) diff --git a/v2/hacking.txt b/v2/hacking.txt index a65adce0b..2acc25337 100644 --- a/v2/hacking.txt +++ b/v2/hacking.txt @@ -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. +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. +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 @@ Additional resources include - The issue tracker http://zigzag.cs.msu.su/boost.build - - commits mailing list: + - commits mailing list: boost-build@lists.sourceforge.net http://sourceforge.net/mailarchive/forum.php?forum_id=9097 @@ -37,8 +37,8 @@ Both bugs and patches can be send to our mailing list. 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 @@ When submitting a patch, please: - 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 @@ CODING CONVENTIONS. 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 @@ HTML DOCUMENTATION. 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