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) for the
lass of toolsets they are designed to work with, i.e. such that
the user does not have to adjust their values based on which
exact toolset is 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 it
causes to be passed on through to the compiler's command
line.
Besides such portable features there exist be special 'raw'
features allowing the user to precisely determine the exact
command line parameters for certain toolsets 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 the 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 freedom from the user.
---
Might need some rework but seems like a good stating
point. Maybe it's a bit too long but atm 'I lack the time to
make it shorter' :-). Also I guess there should be a link to
this information from the toolset docs as it is also relevant
to toolset design.
Hope this helps.
Best regard,
Jurko Gospodnetic