From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-10-17 11:42:40
John Maddock wrote:
>>>Taking Intel on Linux as an example, it includes common_edg.hpp
>>>which would define BOOST_CXX_EDG, then intel.hpp would define
>>>BOOST_CXX_INTEL, I'm not sure whether BOOST_CXX_GCC should be
>>>defined as well, but intel.hpp could define it if required.
>>Yes, EDG is a special case since it already has a common header where
>>the version macro could be defined. But it seems more forward thinking
>>to generalize the structure so that we don't have to go adding more
>>special cases in the future. And the one thing we *really* want to
>>avoid is duplication of the code to define the version macros, by for
>>example defining BOOST_CXX_GCC in both intel.hpp and gcc.hpp, as that
>>will surely lead to errors.
> However do we really want to define macros for more than one compiler at
> once? The whole reason for introducing BOOST_MSVC was because other
> compilers were pretending to be msvc.
I'll take your word for it :-) I didn't find a mention of that in the
list searches I did. But it seems logical that is the reason we would
have that macro. And it does make sense in the Intel case that we would
want to treat it as just one compiler. I suspect that for compilers like
Intel, which are front ends to others, we will want some other define to
say what the target compiler is. But that can be up to the individual
compilers. And since we would have the BOOST_VERSION_NUMBER macro those
defines would at least be consistent :-)
OK, so I'll remove the various *_version.hpp files from the proposal.
> Again, I don't think we should ever have more than one platform macro set,
> otherwise any code that's testing for that won't know what to do.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk