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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost