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

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2005-10-17 09:45:07

John Maddock wrote:
>>After reading up on past discussions about what people want from a set
>>of standard macros for compiler identification, I put together a wiki
>>page with past information on the subject and my ideas as to what the
>>consensus is. And basic proposal based on the ideas:
>>
>>http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig
>>
>>Discussion, contributions, funny anecdotes are welcome :-)
> 
>>(1) BOOST_VERSION_NUMBER macro
> 
> Overall, I like it, as someone else suggested you may need to reserve a few 
> more digits here and there, as long as we don't end up overflowing a 32-bit 
> int of course.

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 ;-)

>>For each compiler 'boost/config/select_compiler_config.hpp' would define a 
>>macro as '0' by default
> 
> That won't work: users can short circuit that header so that it doesn't get 
> included as documented here: 
> http://www.boost.org/libs/config/config.htm#advanced_config
> 
> We could define any macro that's not already been defined in suffix.hpp 
> though.

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

> I like your choice of names for the macros BTW.

Thanks :-)

>>For some compiler toolsets it's possible that multiple macros are defined. 
>>For instance this would be the case for EDG based compilers >where one 
>>would want to know both the EDG version and the specific vnedor compiler 
>>version. ANother being compilers that are >frontends to other system 
>>compilers, like the Intel compiler. For those reasons it would be better 
>>to create new headers which contain the >above definitions per compiler. 
>>This would allow them to be defined once and included where appropriate. 
>>Hence we would need to add >the following headers:
> 
> I don't understand the logic there, why the extra headers?
> 
> 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.

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

> Looks like you need to cull some more std lib information to get the version 
> numbers :-)

Yep, and I'll need some help as I don't have access to most platforms 
and the current headers don't have enough for me to figure out the 
version info, if any.

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