"Beman Dawes" wrote in message news:4.3.2.7.2.20021231164805.01aa20c0@mailhost.esva.net...

At 03:07 AM 12/31/2002, Black Ice wrote:

...

The last version of boost has got by CVS. set BOOST_ROOT=d:\boost\boost set VC7_ROOT=D:\Program Files\Microsoft Visual Studio .NET 2003\Vc7 bjam "-sTOOLS=vc7"

Command line error D2016 : '/Za' and '/Ze' command-line options are incompatible

Sounds like something in your setup is bonkers. The vc7 toolset has been problem free for a long time.

For the .NET 2003 (aka 7.1) testing of the Boost libraries I did in September, I added switches /Op -Zc:wchar_t. IIRC, someone from Microsoft suggested them for the Boost libraries.

If you use the switch you mentioned, be aware that you are compiling with C++ native wchar_t support, which is probably what you want, but that if someone else tries to use the library and does not use this switch, which means the previous VC++ typedef compatibility for wchar_t, they will fail during the link phase if you are exporting any functions which pass or return wchar_t in any way in your library. I think Boost should promote native C++ wchar_t support, but of course this will break user modules which take the default. Presently Regex++ uses the default and not the switch above. A possible solution, but one that entails more work, is to support both for VC++ with slightly different library names, one with C++ native wchar_t support and the other without. This involves more builds and more libraries distributed for VC++ but will not leave the end user in the lurch who does not match the option chosen when the library is built.

"Beman Dawes" wrote in message news:4.3.2.7.2.20030101090516.0224d558@mailhost.esva.net...

At 09:19 PM 12/31/2002, Edward Diener wrote: On one hand, it is a always nice if Boost libraries work with default compiler switches. OTOH, we really want to push in the direction of increased standards compliance, and that may mean requiring switches.

FWIW, some people within Microsoft are pushing for the increased compliance switches like -Zc:wchar_t to become the default in the release after 7.1.

...

A possible solution, but one that entails more work, is to support both for VC++ with slightly different library names, one with C++ native wchar_t support and the other without. This involves more builds and more libraries distributed for VC++ but will not leave the end user in the lurch who does not match the option chosen when the library is built.

I'll leave that decision to John Maddock and the others most directly affected.

Perhaps the decision should be made consistent throughout any Boost library exporting wchar_t functionality. A new Boost macro might be able to enforce it for VC++ 7.0 and higher throughout Boost. I am sure it would be disconcerting to end users to find that Boost implementation X, which uses wchar_t for VC++, uses it one way while Boost implementation Y, which uses wchar_t for VC++, uses it the opposite way. I too agree that the native C++ wchar_t in VC++ 7 and higher should be the default for further Boost releases. It is important that end-users are told of this change, where applicable, if it is made.

Looking at your failed command line, it is apparent that neither the /Ze nor the /Za options are set. Further looking down your command line logs, it looks to me as though you are trying to build using the vc7 toolset, but with the vc6 compiler (hint: your environment is only ever set up for vc6, run your vc7 version of vcvars32.bat before invoking jam). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm