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

From: David Abrahams (dave_at_[hidden])
Date: 2002-12-05 09:18:02

"John Maddock" <jm_at_[hidden]> writes:

>> 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?
>
> Not quite:
>
> BOOST_NO_CONFIG : turns off all checking for defects, 

Well, sure. But if they're just trying to check the core compiler and
NOT the library, I don't think they want BOOST_NO_CONFIG, do they? And
since that also turns of platform workarounds, it could get them into
trouble with platform bugs over which they have no control, couldn't
it?

> IMO compiler specific fixes should be turned off by this as well (in
> many cases this is all you need - certainly this is what I used for
> testing a certain recent alpha compiler release...)

Well, in my code I've been using BOOST_STRICT_CONFIG to turn off
version-specific fixes. So we have a problem.

> Then define: any macros that define features: BOOST_HAS_LONG_LONG
> etc.

Right, I guess that will tend to test more of the compiler.

> Then define any defect macros you want to temporarily enable until the
> compiler is fixed :-)

OK.

>> Questions:
>>
>>     1. Should we do something to make this easier for them?
>>
>>     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
>>
>> Thoughts?
>
> That's not a bad idea IMO.  

#1 or #2?

> Compiler vendors aren't necessarily typical boost users though :-)

No, it's true. In some ways they're dumber. It seems as though the
ability of compiler vendors to get the tests running properly if you
don't hold their hand every step of the way is pretty low.

That aside, I think if we don't use something like
BOOST_COMPILER_WORKAROUND, we're bound to continue to have problems
like deciding whether to check BOOST_STRICT_CONFIG or
BOOST_NO_CONFIG. Not to mention the fact that simply writing these
sorts of checks is error-prone and makes the code hard-to-read:

#if defined(__SUNPRO_CC) && __SUNPRO_CC <= 0x540 && !defined(BOOST_NO_CONFIG)
   // workaround here
#else
   ...
#endif

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