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

Subject: Re: [Boost-build] Build issues with boost/regex and ICU_PATH
From: Alexander Sack (pisymbol_at_[hidden])
Date: 2008-10-24 08:51:25

On Fri, Oct 24, 2008 at 4:43 AM, John Maddock <john_at_[hidden]> wrote:
> 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.

Wait, /usr/local/include breaks gcc on Linux?  I realize /usr/include
might but /usr/local/include?

Thanks!

-aps