Re: [Boost-build] Splitting libboost_regex.so into ASCII and ICUsubmodules while preserving binary compatibility - need bjam help

From: John Maddock (john_at_[hidden])
Date: 2006-08-21 05:49:46

Zack Weinberg wrote:
> Thread support can be turned off at build time, but there is no
> upstream support for installing thread-safe and non-thread-safe
> variants of the library (unlike in Boost) so I doubt packagers will
> want to mess with that.  It doesn't use threads internally, so I
> _might_ be able to do the same trickery that is done in the C++
> runtime to stub out thread support at runtime when it's not needed,
> but I'd prefer the solution in Boost as this removes more overhead
> (the ICU libs wouldn't be loaded at all when they're not used).

Let me try and get this clear in my head, 'cos I'm still confused :-)

Boost.Regex is being built single threaded, but it's being linked to ICU 
which then pulls in pthreads?

Just so you know: when Boost.Regex is built with BOOST_HAS_THREADS then it 
pulls in pthreads as well, and for recent versions of gcc, BOOST_HAS_THREADS 
is pretty much always defined (unless you take expicit steps to turn it off 
with BOOST_DISABLE_THREADS).  The "single-threaded" bjam builds aren't 
really single threaded at all: they're more like "give me whatever the 
compiler does by default".

What would happen if in addition to an all-in-one libboost_regex there were 
separate mini-libs for the various parts, and the user could choose which 
path they wanted to go down (figure out which bits they require and link to 
them, or just grab the lot).

I'm not saying this extra build option could be implemented really fast: the 
Win32 linking dll import/export would need to be split up, and it's not a 
completely trivial task :-(

And finally, can you statically link to Boost.Regex?  That would be a 
simple-ish workaround that would only pull in what you actually use?

HTH, John.