From: Jurko Gospodnetic (jurko_for_boost_at_[hidden])
Date: 2004-10-27 03:17:41
>> Actually, don't both those features 'send their values' to the tool
>> and it's actually the tool's duty to interpret them? So the difference is
>> in how they are used by a tool and not in the features themselves.
> This is correct. Only the tool (specifically toolset module) decides how
> handle the feature. Can you suggest how to make this more clear?
Hmm... okie... I gave it a shot and here's the first result...
--- 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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk