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

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 14:41:24

Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:

> 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.

That's a big assumption. Some vendors will want to check their current
release, and sometimes we begin to set up configuration for
pre-released compilers.

>> 
>>     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. 

I suppose. I can see it being useful to be able to demonstrate bugs in
any version of a compiler, though.

> 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'm not sure there's universal agreement about that, but now that Doug
has fixed the function headers, the code says otherwise. 

> 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.

I propose:

    #ifndef BOOST_STRICT_CONFIG
    # define BOOST_WORKAROUND(symbol, test) (defined(symbol) && symbol test)
    #else
    # define BOOST_WORKAROUND(symbol, test) 0
    #endif

Comments?

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution