[Boost-users] [predef] [rfc] Mutually exclusive definitions?

Subject: [Boost-users] [predef] [rfc] Mutually exclusive definitions?
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2014-01-12 22:17:22

After going back and re-reading various commentaries for the review of
Boost.Predef and some after the review I'm questioning a design choice of
Boost.Predef.

Currently Boost.Predef will define multiple symbols when, for example, a
compiler "emulates" another compiler. The current common occurrence of this
is the GCC compiler which many other compilers emulate by defining the GCC
version macros. This is no longer the case for the OS definitions though.
The OS definitions are mutually exclusive. And hence in order to make for a
more consistent behavior I am considering changing the library to make not
just OS defs mutually exclusive. But also making compiler, library, and
architecture mutually exclusive. And I'm asking for some general feedback
as to what the most useful approach, from using Boost.Predef, is likely to
be. In particular I'm considering the following choices:

1. Simple mutual exclusion of BOOST_ARCH_*, BOOST_COMP_*, BOOST_LIB_C_*,
BOOST_LIB_STD_*, and of course BOOST_OS_* definitions.

2. Mutual exclusion of the base/real definitions with the addition of
*_EMULATED definitions when multiple defs detected. For example for GCC we
would have BOOST_COMP_GCC_EMULATED indicated the version of the GCC being
emulated.

3. No mutual exclusion of base definitions but with the addition of a
"flag" definition when multiple defs are detected. For example with GCC it
would have the usual BOOST_COMP_GCC but also have a "#define
BOOST_COMP_GCC_IS_EMULATED".

4. Do nothing and live with multiple definitions and the current
discrepancy in behavior for BOOST_OS definitions.

-- 
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
-- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail