Boost-Build :

jurko_for_boost_at_[hidden]

---
Although ultimately the decision on how to interpret feature
data rests entirely on the toolsets that receive it, Boost.Build
suggests the following coding standard for designing features
and toolsets.
Most features should be portable (toolset neutral) across the
class of toolsets they are designed to work with, i.e. such that
the user does not have to adjust their values based on the
exact toolset used. An example of such a feature would be
<optimization>speed - a portable feature for C++ compiler
toolsets that has the same meaning for all such toolsets
without the user having to worry about which exact options
this causes to be passed on through to the compiler's
command line.
Besides such portable features there exist special 'raw'
features allowing the user to precisely determine the exact
command line parameters for a particular toolset, if so
desired. An example of such a raw feature would be
<cxxflags> designed to allow the user to directly specify
command line options passed to a C++ compiler. Of course
one should always strive to use the portable features but
these should still be provided as a backdoor just to make
sure Boost.Build does not take away any control from
the user.
---
Also here are some additional V2 manual corrections:
http://boost.org/boost-build2/doc/html/bbv2.reference.buildprocess.html
- 'include a expandable' should read 'include an expandable'
- 'equvivalent' should be spelled 'equivalent'
- 'If requirements include conditional property' should read
'If requirements include a conditional property'
- I guess 'value if common properties' should read 'value in
common properties'
- 'rulse' should be spelled 'rules'
- I guess 'For example, for following' should read 'For example,
the following'
Best regards,
Jurko