Boost logo

Boost-Build :

From: Andrey Melnikov (melnikov_at_[hidden])
Date: 2005-09-14 18:57:40

Reece Dunn wrote:
> Hi All,
> I am interested in the changes/development going on with respect to the
> msvc.jam toolset and related functionality. I have been experimenting
> with some things myself. These are:
> [1] warnings support (designed for genericity, only supported in msvc
> for now).
> # builtin.jam
> feature warnings : default on off all strict : propagated ;

I wonder if there's a reason to have unified warning names?

E.g. <warning-disable>dtor-not-virtual or

> I can look at extending support for this on Borland, GCC, CodeWarrior
> and possibly others.
> [2] support for specifying the character set.
> # builtin.jam
> feature charset : narrow unicode mbcs : composite link-incompatible ;
> feature.compose <charset>unicode : <define>UNICODE <define>_UNICODE ;
> feature.compose <charset>mbcs : <define>MBCS <define>_MBCS ;
> This is targeted for the Windows platform. I am not sure about how this
> would work with *nix or MacOS.

These defines are used the following two purposes:
1. To select ANSI or Unicode versions of Win32 API functions
2. To support tchar.h and Microsoft-specific "Generic-text mappings"
functions (to enable switching between char-based to wchar_t-based
standard functions.

feature win32-charset : unicode ansi : composite link-incompatible ;
feature stdlib-tchar : char wchar_t char-mbcs : composite
link-incompatible ;

feature.compose <win32-charset>unicode : <define>UNICODE ;
feature.compose <stdlib-tchar>char : <define>_MBCS ;
feature.compose <stdlib-tchar>wchar_t : <define>_UNICODE ;

It looks like MBCS without the initial underscore isn't used at all.

This defines 6 possible configurations:


I think they are all valid.

> [3] support for targetting versions of windows:
> # builtin.jam
> feature windows : default 95 98 me nt 2k xp 2k3 vista : composite ;

This is purely an MS PSDK feature. So it's better to put it into the
separate Platform SDK module if we decide to implement PSDK support
using an external module.

> [4] support for managed (CLR) and Java bytecode
> # builtin.jam
> feature bytecode :
> native # Use the native assembler instruction set
> clr # Use the CLR (Common Language Runtime) instruction set
> java # Use the Java bytecode
> : propagated link-incompatible ;

This fits into the current <cpu-arch> feature.

> feature clr :
> cppcli # Use the new C++/CLI (VC8-style) style CLR
> managed # Use old-style (VC7.x-style) managed code syntax
> pure # Use C++/CLI (VC8-style) pure CLR
> safe # Use C++/CLI (VC8-style) safe (validated) CLR
> : propagated ;

Is this a MC++-specific, a CLR-specific feature? It looks like it's a
MC++-specific feature. Does it affect code generation, compile-time
checks, C++ language extensions or both?

> The clr feature should really be moved to msvc.jam as it is MS specific.
> Also, the Java bytecode isn't supported as there are currently no Java
> toolsets.
> I will need to separate these out and generate patches for them. Also,
> should there be any coordination effort with the patches that Andrey is
> providing?
I'll try to review your patches too.



Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at