[boost] [regex] Disabling ICU check when building with bjam, 1.44

Subject: [boost] [regex] Disabling ICU check when building with bjam, 1.44
From: Cliff Green (cliffg_at_[hidden])
Date: 2010-10-29 16:53:27

This is on Boost 1.44, g++ 4.1.2 on Linux (RHEL 5.x, can't remember the x at the moment), although it applies generally to building regex.

I can't find a way to easily "disable" the "ICU installed" check and resulting functionality / build. I chatted on IRC, and the only way some (experienced Boost) developers could come up with was to change:

alias icu_options : : : : [ check-target-builds has_icu : $(ICU_OPTS) : ] ;

to

alias icu_options : : : : ;

in Jamfile.v2.

My situation / use case:

Our build system has ICU installed. Our deployment system has exactly the same OS and runtime environment, except that the ICU package is not installed. I would like to build regex without the "check that ICU is installed to determine whether the enable ICU" logic in the jamfiles.

The regex documentation has an:

"-sHAVE_ICU=1"

example, but "-sHAVE_ICU=0" doesn't work, and tracing through the jamfiles / boost build I couldn't find where that option is honored / processed.

There's also a BOOST_HAS_ICU macro that is defined or undefined in various ways, but adding define=BOOST_HAS_ICU 0 to bjam also didn't appear to do anything (and I tried some other ways to undefine BOOST_HAS_ICU, including in the jamfile, but nothing seemed to work).

The docs also mention that the default is to not enable / build with ICU, but that doesn't seem to be the case (with 1.44). (From the first line of ICU build section: "A default build of this library does not enable Unicode support via ICU. There is no need to enable ... ".)

So I'm confused (as well as some other regulars on IRC), and either the documentation needs updating, jamfiles need updating, or my understanding needs updating.

For now, the workaround mentioned above works fine, and the resulting regex.so file does not have any ICU external library dependencies (which is what is desired for our deployment environment).

Thanks!

Cliff