From: David Abrahams (dave_at_[hidden])
Date: 2005-12-05 14:45:46
"Reece Dunn" <msclrhd_at_[hidden]> writes:
> David Abrahams wrote:
>>"Reece Dunn" <msclrhd_at_[hidden]> writes:
>> > It may be useful to have 3 levels of support:
>> > * officially supported (e.g. CodeWarrior 9.x, gcc, VC8) - compilers
>> > Boost is expected to work with;
>> > * not officially supported (e.g. VC6, BCB) - some libraries may work,
>> > there is no requirement to support these compilers;
>>Sounds good, but I'd like to know, as a practical matter, what the
>>difference between these two is. Less pressure on developers to
>>support the 2nd category?
> The first would mean that Boost guarantees support for the specified
What does that mean? Every developer is obligated to make his library
work on that compiler? That would be unprecedented (though not out of
> The second (possibly with a better name) would mean that there is limited
> support. That is:
> * less pressure (or none for VC6 ;)) on developers to support it (as you
> * no requirement to fix regressions for that toolset (although it might be
> useful for the users to see the regression results for these compilers so
> they know what libraries will work).
>> > * not supported (e.g. OpenWatcom) - these haven't been tested for and
>> > not have any Boost.Config/workaround magic to support them.
>> > It may also be useful to make Boost.Config issue a warning that
>> > like BCB and VC6 are not officially supported if they are removed from
>> > supported list.
>><shiver> Wouldn't people hate us for adding diagnostics?
> I don't know. Don't Boost.Python and Boost.Serialize produce
> warnings/notifications if they aren't configured properly?
Boost.Python produces one during the boost install/build process if it
isn't going to be built. No diagnostics are intentionally issued from
-- Dave Abrahams Boost Consulting www.boost-consulting.com