mirror of
https://github.com/boostorg/build.git
synced 2026-02-15 00:52:16 +00:00
Typo corrections. Minor stylistic changes.
[SVN r42478]
This commit is contained in:
Jurko Gospodnetić
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user