[BBv2] character set support

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-22 18:11:08

This patch defines the following features:

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

where <win32-charset> selects between the A/W versions of the Win32 API 
and <stdlib-charset> selects the str/wcs/mbs*** version of the string 
functions to use in the _tcs*** string functions in <tchar.h>.

There are a few questions/comments I have regarding this extension:

[1] These are link incompatible because you would want to keep the 
builds for different charater sets separate and composite because they 
map to <define>s. However, if someone provides a good argument for, say, 
having them as /incidental/, I'm willing to change it.

[2] Where should these reside? Ideally, they would go in 
msplatformsdk.jam, but that doesn't exist... yet! This is because the 
facilities are primarily a Windows feature. Do Linux or Mac have similar 
ansi/multibyte/unicode character type selection, if so, how do they 
select the character types?

[3] With this setup, there are two mechanisms for controling the 
character type being used. While they are controlling different things 
(Win32 API character sets and the _tcs character type), having them 
separate can lead to a few issues:

* There are two new directories added, instead of just one, which adds 
to the "where are my build files?" problems that can confuse new users 
and distract people from using BBv2.

* It is possible to specify incdompatible win32/stdlib combinations 
such as <win32-charset>ansi/<stdlib-charset>wide that can lead to 
problems using TCHAR, _T and other types/macros.

Given these issues, I would prefer to have a single <charset> feature:

feature charset : ansi multibyte unicode : composite link-incompatible ;

that selects the appropriate combinations without leading to potential 
conflicts. This also reflects what MSVC projects use, making it easier 
for people familiar with them to move to BBv2.

One goal of BBv2 is to simplify project specifications (just one 
<charset> featute) to reduce potential errors in getting the wrong 
settings (e.g. selecting the right runtime library version). Another 
goal is in giving the user greater control over project specifications 
(the two features).

I would like other peoples opinions as to whether this should be one or 
two features. Also, if it is possible to generalise this feature to 
other operating systems.

- Reece
 --------------020009010702020400050202 Content-Type: text/plain;
name="charset.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="charset.diff"

Index: builtin.jam
===================================================================
RCS file: /cvsroot/boost/boost/tools/build/v2/tools/builtin.jam,v
retrieving revision 1.180
diff -u -r1.180 builtin.jam
--- builtin.jam	22 Sep 2005 13:51:58 -0000	1.180
+++ builtin.jam	22 Sep 2005 22:31:15 -0000
@@ -61,6 +61,13 @@

feature.feature location-prefix : : free ;

+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>wide : <define>_UNICODE ;
+feature.compose <stdlib-charset>mbcs : <define>_MBCS ;
+

# The following features are incidental, since
# in themself they have no effect on build products.
 --------------020009010702020400050202--