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

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-15 02:50:50

Andrey Melnikov wrote:
> Reece Dunn wrote:
> 
>>Hi All,
>>
>>[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 am not sure, as there could potentially be hundreds of named warnings, 
some of which would be added/removed from version to version of a 
compiler. This would complicate the option mapping and maintenance of 
the feature. I agree, it would be nice in some circumstances.

I designed the warnings to be as generic as possible, without 
compromising too much on control. I haven't used warning levels wither 
as I was unsure how generic this would be.

feature warnings # the options in () are for msvc
:
default # use the compilers default warning settings (-W1)
on # turn warnings on (-W3)
off # turn warnings off (-W0)
all # enable all warnings (-W4 -Wp64)
strict # same as all, but be stricter about warnings
# (-W4 -Wp64 -WX)
: propagated ;

>>[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 ;

I like this, but have a few minor points:
* ansi should come before unicode in win32-charset, to use it as the 
default option;
* stdlib-tchar should really be stdlib-charset to be consistent;
* I would prefer to use the names "narrow wide mbcs" in the 
stdlib-tchar feature.

Thus, we now have:

feature win32-charset : ansi unicode : composite link-incompatible ;
feature stdlib-charset : narrow wide mbcs : composite
link-incompatible ;

feature.compose <win32-charset>unicode : <define>UNICODE ;
feature.compose <stdlib-charset>mbcs : <define>_MBCS ;
feature.compose <stdlib-charset>wide : <define>_UNICODE ;

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

My bad :).

> This defines 6 possible configurations:
> I think they are all valid.

Agreed. However, you would usually define compatible character types. 
What happens if you have:

<win32-charset>unicode <stdlib-charset>narrow

and:

TCHAR * ch = _T("To _T, or not to _T...");

?

>>[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.

I totally agree. It's just that a PSDK feature doesn't exist yet, so I 
put it in builtin.jam. I have a few questions:

[1] What if you don't specify a PSDK in user-config.jam, but want to 
specify <windows>xp for a project? Or even:

tlb myidl : myidl.idl : <windows>2k ;

[2] What if you are building with a non-msvc compiler (e.g. Borland or 
Metrowerks CodeWarrior), or evevn the default PSDK shipped with the 
specified compiler?

>>[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?

MC++ is the C++ way to target to .NET (i.e. the CLR). I think (but would 
have to check) that VC8 has pure/safe CLR options for its C#/VB/*.NET 
languages.

VC7.x defines a style of managed C++ where you have things like:

__gc class managed ...;

VC8 allows this (as -clr:oldSyntax), but uses the new syntax by default. 
The new (C++/CLI) syntax allows you to write:

enum class values ...;

I chose the name "managed" for the "old" syntax because <clr>old and 
<clr>new are confusing and meaningless w.r.t. VC7.x.

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

Great :)

- Reece