Build+Install+/Zc:wchar_t in Visual studio builds
Guys, Rene's new Install code is working very well for me now, but I have a question about how we're building with Visual Studio .NET. Currently the vc7 and vc7.1 toolsets turn on /Zc:wchar_t unconditionally when building, however this is not the default option in current versions of the IDE, and of course the two options produce binary-incompatible libraries (at least as far as regex is concerned). How should we handle this? At the very least I would like to see a bjam option to turn off /Zc:wchar_t, but how should we be building the libraries by default: turning native wchar_t support on is the standards conforming way, but not currently the default Visual Studio way, or the way many third party libraries (like ICU for example) are built. Does anyone know how this option interacts with MFC/ATL/VisualForms etc? We could of course create a new build variant to handle this, but with 8 regex lib/dll variants already I'm not keen to add another 8 (apart from anything else testing already takes too long). I'm cross posting this to the Boost.users group as well, since whatever resolution we take will affect them the most :-) Thanks, John.
John Maddock wrote:
Guys,
We could of course create a new build variant to handle this, but with 8 regex lib/dll variants already I'm not keen to add another 8 (apart from anything else testing already takes too long).
I think you have to do this John if you want to support both the C++ wchar_t and the MS wchar_t in Boost libraries. Although there are VC++ predefined macros, _WCHAR_T_DEFINED and _NATIVE_WCHAR_T_DEFINED, which are defined when /Zc:wchar_t is used, they are also stupidly defined, according to the documentation, when typedef unsigned short wchar_t is used ( talk about idiotic MS decisions ). So Boost needs to use a macro which the end-programmer must define which tells whether or not /Zc:wchar_t is being used or not, and create another set of libraries accordingly. The other choice of picking one, either /Zc:wchar_t or not, and then telling developers that they will have to rebuild the library and maybe change its name for their opposite use, will be disappointing to end-users. I brought all this up a long time ago vis-a-vis VC++ 7+, but Boost implementors of wide character code seem to want to go along and ignore this problem until it bites them <g>. I am glad at least you realize its ramifications.
We could of course create a new build variant to handle this, but with 8 regex lib/dll variants already I'm not keen to add another 8 (apart from anything else testing already takes too long).
I think you have to do this John if you want to support both the C++ wchar_t and the MS wchar_t in Boost libraries. Although there are VC++ predefined macros, _WCHAR_T_DEFINED and _NATIVE_WCHAR_T_DEFINED, which are defined when /Zc:wchar_t is used, they are also stupidly defined, according to the documentation, when typedef unsigned short wchar_t is used ( talk about idiotic MS decisions ). So Boost needs to use a macro which the end-programmer must define which tells whether or not /Zc:wchar_t is being used or not, and create another set of libraries accordingly.
The other choice of picking one, either /Zc:wchar_t or not, and then telling developers that they will have to rebuild the library and maybe change its name for their opposite use, will be disappointing to end-users.
I brought all this up a long time ago vis-a-vis VC++ 7+, but Boost implementors of wide character code seem to want to go along and ignore
Testing for _NATIVE_WCHAR_T_DEFINED works perfectly well - it is set by the compiler only and not the headers. As for moving to 16 (!) build variants, remember that this issue only effects boost.regex at present: so the variants aren't needed for other libraries (which makes a generic build and install system hard). Remember also how long it takes to test this - I don't think I've done anything with my spare time this week, except test the new Boost.Install system with regex, and I'm still only half way though building and running all the test variants (takes about 2 hours per compiler toolset provided nothing nasty shows up). this
problem until it bites them <g>.
'Cos, it's a complete pain in the you know where... <g> John.
John Maddock wrote:
We could of course create a new build variant to handle this, but with 8 regex lib/dll variants already I'm not keen to add another 8 (apart from anything else testing already takes too long).
I think you have to do this John if you want to support both the C++ wchar_t and the MS wchar_t in Boost libraries. Although there are VC++ predefined macros, _WCHAR_T_DEFINED and _NATIVE_WCHAR_T_DEFINED, which are defined when /Zc:wchar_t is used, they are also stupidly defined, according to the documentation, when typedef unsigned short wchar_t is used ( talk about idiotic MS decisions ). So Boost needs to use a macro which the end-programmer must define which tells whether or not /Zc:wchar_t is being used or not, and create another set of libraries accordingly.
Testing for _NATIVE_WCHAR_T_DEFINED works perfectly well - it is set by the compiler only and not the headers.
Then it is a documentation bug. I should know not to trust documentation, even by MS, by now.
As for moving to 16 (!) build variants, remember that this issue only effects boost.regex at present: so the variants aren't needed for other libraries (which makes a generic build and install system hard). Remember also how long it takes to test this - I don't think I've done anything with my spare time this week, except test the new Boost.Install system with regex, and I'm still only half way though building and running all the test variants (takes about 2 hours per compiler toolset provided nothing nasty shows up).
I hear you. Perhaps regression tests can do some of this for you.
The other choice of picking one, either /Zc:wchar_t or not, and then telling developers that they will have to rebuild the library and maybe change its name for their opposite use, will be disappointing to end-users.
I brought all this up a long time ago vis-a-vis VC++ 7+, but Boost implementors of wide character code seem to want to go along and ignore this problem until it bites them <g>.
'Cos, it's a complete pain in the you know where... <g>
Agreed. And one caused by MS's unwilling to embrace wchar_t a long while back. But there are many VC7+ programmers in the world so that any Boost library implementation, like regex++, which uses wide characters needs to deal with it. My suggestion is to create a separate set of regex++ libraries for wide character usage. Not only will this mean that those not using wide character search and/or replace with regular expressions will have smaller libraries distributed to them, but also you will have testing to do regarding VC++ and wchar_t only on the wide character versions. Actually I have been meaning to suggest for awhile that the regex++ libraries be broken into smaller library pieces to aid in distribution. The POSIX functionality also can be put in a separate library. Breaking regex++ into smaller libraries means a smaller distribution of code if one never uses some of the less standard features such as wide character and POSIX.
"John Maddock"
Guys,
Rene's new Install code is working very well for me now, but I have a question about how we're building with Visual Studio .NET.
Currently the vc7 and vc7.1 toolsets turn on /Zc:wchar_t unconditionally when building, however this is not the default option in current versions of the IDE, and of course the two options produce binary-incompatible libraries (at least as far as regex is concerned).
How should we handle this?
I dunno; we're setting the option because there was a policy decision to use compilers in their most conforming modes as long as it doesn't turn off features needed by the libraries.
At the very least I would like to see a bjam option to turn off /Zc:wchar_t,
I think that might be reasonable.
but how should we be building the libraries by default: turning native wchar_t support on is the standards conforming way, but not currently the default Visual Studio way, or the way many third party libraries (like ICU for example) are built. Does anyone know how this option interacts with MFC/ATL/VisualForms etc?
Not a clue over here. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (3)
-
David Abrahams -
Edward Diener -
John Maddock