Re: [boost] [Config] Testing instructions for compiler vendors

From: John Maddock (jm_at_[hidden])
Date: 2002-12-08 06:58:46

> >> I don't (yet). Why do we need yet another macro which means "turn off
> >> the workarounds?" Would BOOST_STRICT_CONFIG then be obsolete?
> >
> > I think that the idea is that BOOST_STRICT_CONFIG applies only to
unknown
> > compiler versions, and BOOST_DISABLE_WORKAROUNDS (do we need separate
> > compiler/library macros?) would be applied unconditionally, regardless
of
> > whether the compiler has known defects.
>
> What's the use of distinguishing those? Surely the person who's doing
> the testing doesn't care about whether we think we "know" that
> particular compiler version?

Would you believe that I've rewritten this mail three times with the
previous two having flaws (discovered just as I'm adding my sig!).

Hopefully this time this is logically correct, how about this:

If the config system detects a compiler version it knows about, and which it
knows will likely need compiler specific workarounds, then it undef's
BOOST_STRICT_CONFIG if it's set (in the compiler config files).

Then we just use BOOST_STRICT_CONFIG as to determine whether to enable
workarounds or not.

There are now three use cases if BOOST_STRICT_CONFIG is defined:

1) We recognise the compiler, and know that it needs workarounds: disable
BOOST_STRICT_CONFIG.
2) We don't recognise the compiler: assume that it is standard conforming
and disable all workarounds.
3) BOOST_NO_COMPILER_CONFIG is set: so irrespective of the compiler version
all workarounds will be turned off.

BTW I think your BOOST_WORKAROUND macro belongs in boost/config/suffix.hpp
if you want to move it there (so we all get it), and of course it needs docs
adding - probably to the helper macros table in the config docs.

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm