Re: [jamboost] [BBv2] [msvc] scoping interest for other extensions

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 
<warning-disable>copy-ctor-cannot-be-generated

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

unicode/char
unicode/wchar_t
unicode/char-mbcs
ansi/char
ansi/wchar_t
ansi/char-mbcs

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.

Andrey