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

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-12-05 04:24:42

David Abrahams wrote:
> I'm trying to come up with instructions for compiler vendors who want
> to use Boost to test their compilers. What preprocessor symbols do
> they need to define? So far, it looks like:
> 
>      - BOOST_NO_COMPILER_CONFIG
>      - BOOST_NO_STDLIB_CONFIG   - if they want to check the library
>      - BOOST_STRICT_CONFIG      - to disable some checks in 
> source code
>      - macros for any known-not-implemented features,
>        e.g. BOOST_NO_TEMPLATE_TEMPLATES.
> 
> Right?

As far as I understand, defining BOOST_STRICT_CONFIG only should be
sufficient (for compiler tests) - given that the compiler being tested has a
bumped up version number.

> 
>     2. What about all the places we make compiler-specific checks in
>        Boost code? Could we define some macros which make it easier
>        and less error-prone to write these, and which can be globally
>        turned off when needed?
> 
>     # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, <= 0x540)
>       ...
>     #else
>       ...
>     #endif
> 

The checks for the past versions of the compiler, e.g.

    #if defined(BOOST_MSVC) && BOOST_MSVC <= 1300
    #   define BOOST_MPL_MSVC_ETI_BUG
    #endif

are harmless for the beta-testing of the new one. 

As for checks for current bugs, I think it's our current convention that
they should be guarded by BOOST_STRICT_CONFIG, like this:

    #if defined(__BORLANDC__) \
        && (__BORLANDC__ <= 0x570 || !defined(BOOST_STRICT_CONFIG))
    #   define BOOST_MPL_BROKEN_OVERLOAD_RESOLUTION
    #endif

so defining BOOST_STRICT_CONFIG would disable them. I am afraid it's not
thoroughly enforced, though. If we come up with a way to simplify the above,
personally I would be more than happy.

Aleksey