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