Re: [boost] [config] Standard version macros proposal -- Reviving the compiler version macros.

From: John Maddock (john_at_[hidden])
Date: 2005-10-17 11:15:04

> I already changed the patch number from 3 to 5 digits. So it's now at
> 3 digits for major, 3 for minor, and 5 for patch. Which Hmm, which
> blows up the 32 bit barrier :-( That barrier realistically only
> allows for 3/3/3 at up to 1,000,000,000 (closest decimal round number
> lower than 2^32). So if we want more than 9 digits we'll have to
> figure out some other way. Ideas welcome ;-)

Yes, if you make the patch number 5 digits then you've only got one digit 
left for the major number, and we're already at version 9 for MWCW aren't 
we?

> OK, I'll adjust accordingly then. Is it OK to then define all the
> compiler, platform, and stdlib macros in suffix.hpp?

Seems the logical place, it always gets included, so it would have to be:

#ifndef BOOST_CXX_ACME
#define BOOST_CXX_ACME 0
#endif
// etc

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

>> Likewise with the platform headers: I don't see the need for the
>> extra headers, the only macro that can be defined in combination
>> with the other appears to be BOOST_PLATFORM_POSIX and presumably
>> that would be defined in the existing posix_features.hpp?
>
> Again I didn't want to assume it's going to be that way in the future.
> But sure if we think that POSIX is the only platform that will ever be
> defined in addition to all other platforms we can certainly put the
> version definitions into the specific platform headers.

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.

John.