[boost] Preliminary:building with VC++ 8.0 Express beta

From: Tony Juricic (tonygeek_at_[hidden])
Date: 2004-09-06 11:22:02

I downloaded and installed MS VC++ 8.0 Express beta. The advantage of
Express over full Visual Studio 2005 is in a smaller disk footprint and you
need 'only' MS Passport (not MSDN subscription) to download it.

Note that Express does not come with Windows headers and libraries so you
need to download Platform SDK or use existing, older installation. For
example, before invoking bjam, you may say:

set INCLUDE="C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\PlatformSDK\Include";%INCLUDE%
set LIB="C:\Program Files\Microsoft Visual Studio .NET
2003\Vc7\PlatformSDK\lib";%LIB%

Here are the problems encountered when building boost:

1) flags for DLL and single-threaded static library have changed. You would
need the following flags
in msvc-tools.jam:

# VC8.0
flags msvc CFLAGS <runtime-build>release/<runtime-link>dynamic : /LD ;
flags msvc CFLAGS <runtime-build>debug/<runtime-link>dynamic : /LDd ;

flags msvc CFLAGS
<runtime-build>release/<runtime-link>static/<threading>single : /MD ;
flags msvc CFLAGS
<runtime-build>debug/<runtime-link>static/<threading>single : /MDd

2) Og and Gs compiler flags will be deprecated and cause warning.

3) many string functions ( sprintf, strcat, wsccpy, etc. ) cause deprecated
warning.

4) compilation errors, all involving wchar_t like:
C:\Program Files\Microsoft Visual Studio 8\VC\include\xutility(207) : error
C2664: 'bool
boost::spirit::utility::impl::range_char_compare<CharT>::operator ()(const
boost::spirit::utility::impl::range<CharT> &,const CharT) const' : cannot
convert parameter 1 from 'wchar_t' to 'const
boost::spirit::utility::impl::range<CharT> &'
        with
        [
            CharT=wchar_t
        ]
        Reason: cannot convert from 'wchar_t' to 'const
boost::spirit::utility::impl::range<CharT>'
        with
        [
            CharT=wchar_t
        ]
        No constructor could take the source type, or constructor overload
resolution was ambiguous

Problem #1 can be solved by commenting out older flags and substituting them
with the new ones in msvc-tools.jam. I am sure this is not the most elegant
solution, ignorant of bjam as I am.

Re. problem #2, I could not find an explicit suggestion on what new options
should be used. However, the sheer number of problems with /Og option listed
in MS Knowledge Base make me believe that it would be best to remove it.
Whidbey (but not Express) is to offer more advanced profile-based
optimizations. As for /Gs I would assume that /GS (also /RTC1) should
substitute it, following the article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vctchcompilersecuritychecksindepth.asp

As for #3, even barring security concerns, I tend to agree that using string
functions with source and destination buffer size parameters is desirable.
However, I wouldn't know which portable changes would avoid these warnings;
presumably MS-specific extensions would be required.

Still unfamilar with boost++ modules that caused errors under #4, I haven't
looked into it.

While more detailed info about these issues may be possible to find on MSDN,
searching for any phrase, unfortunately, results in a huge number of .NET
related articles.

Tony