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:
 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.
 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?
 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.
--------------020009010702020400050202 Content-Type: text/plain;
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.
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk