Re: [Boost-build] Build issues with boost/regex and ICU_PATH

Subject: Re: [Boost-build] Build issues with boost/regex and ICU_PATH
From: John Maddock (john_at_[hidden])
Date: 2008-10-24 04:43:15

Alexander Sack wrote:
>> In the Jamfile.v2 of 1.36.0 boost/regex library I see:
>>
>> 169 if [ check-icu-config ]
>> 170 {
>> 171    BOOST_REGEX_ICU_OPTS = "<define>BOOST_HAS_ICU=1" ;
>> 172
>> 173    if $(ICU_PATH)
>> 174    {
>> 175       if $(ICU_PATH) != "/usr" && $(ICU_PATH) != "/usr/local"
>> 176       {
>> 177          BOOST_REGEX_ICU_OPTS += "<include>$(ICU_PATH)/include" ;
>> 178          ICU_SEARCH_OPTS = <search>/$(ICU_PATH)/lib ;
>> 179       }
>> 180    }
>>
>> On my build machine (a FreeBSD box), ICU is located in "/usr/local"
>> PATH (as are most standard FreeBSD ports).  Why does the above check
>> exists?  Other than "/usr" what's the harm of adding <include>
>> directive to the BOOST_REGEX_ICU_OPTS?
>>
>> The issue is the standard boost build creates a makefile from a
>> pseudo
>> configure script (to make it more GNU friendly) that generates the
>> following command line option:
>>
>> configure --with-icu=/usr/local
>>
>> creates in a Makefile
>>
>> BJAM_CONFIG= -sWITH-ICU=/usr/local
>>
>> If the above is not honored, then <include> never occurs and the
>> build
>> fails.  I believe this is just a bug (I don't see why this should be
>> conditional for FreeBSD either).

No it's deliberate: adding /usr/include to the list of include paths breaks 
most *nix systems, well gcc on Linux anyway.  So any patch has to be BSD 
specific.

Sorry, John.