Now all you need to do is invoke bjam command:
./bjam --with-locale stage
Or on Windows
.\bjam --with-locale stage
If you are using custom ICU build or you are using Microsoft Windows you need to provide a path to location of ICU library using
/opt/icu46such that the files are placed like
./bjam --with-locale -sICU_PATH=/opt/icu46 stage
c:\icu46such that the files are placed like
.\bjam --with-locale -sICU_PATH=c:\icu46 stage
Boost.Locale supports following options with values
boost.locale.icu=offdisable build of ICU backend even if ICU library exists
boost.locale.iconv=onenable or disable use of iconv library. It is off by default on Windows and Solaris
boost.locale.winapi=off- disable winapi backend, it is on by default on Windows and Cygwin
boost.locale.winapi=onDisable or enable std backends.
stdbackend is disabled by default when using Sun Studio.
boost.locale.posix=offEnable or disable support of POSIX backend, it is on by default on Linux and Mac OS X
Also Boost.Locale supports following options
-sICU_PATH=/path/to/location/of/icu- the location of custom ICU library
-sICONV_PATH=/path/to/location/of/iconv- the location of custom iconv library
.\bjam boost.locale.winapi=off boost.locale.std=off -sICU_PATH=c:\icu46 --with-locale stage
.\bjam boost.locale.posix=off boost.locale.icu=off --with-locale stage
You can run unit tests by invoking
libs/locale/test project parameter
Boost.Locale is built with binary compatibility in mind. Switching localization back ends on or off, or using iconv or not, does not affect binary compatibility. So if a dynamic library was built with all possible backends, other dynamic libraries compiled with, for example, only the
winapi backends would still be binary-compatible with it.
However this definitely has an effect on some features. For example, if you try to use boundary analysis or a calendar facet when the library does not support the icu backend you would get an exception.