openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tyler Kavanaugh <>
Subject Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Date Wed, 08 Jan 2014 15:10:24 GMT

On 1/8/2014 4:32 AM, Herbert Duerr wrote:
> On 08.01.2014 01:09, Kay Schenk wrote:
>> [...]
>> Given your recent commits as patches to (now suppiled) boost_1.55, AND
>> some
>> interesting definitions in /main/stlport/systemstl/slist
>> #else // fall back to boost/tr1 (forward_list or plain list)
>>      #include <boost/config.hpp>
>> (who knows if the suppiled config.hpp jives with my own)
> The config.hpp provided by boost must match with the rest of the
> library. At least that's what this header is intended for.
>> I ditched using my local boost_1.54, and things are going much much
>> better.
>> Not quite there yet but close. :}
> Yay!
>> At this point, given the customized work you've done, we might think of
>> warning folks against using their local boost versions -- at least put
>> some
>> notes in Just a thought.
> We should add such a warning to about every system library that is not
> regularly enabled for building and testing. The release builds prefer
> the defaults, but for many libraries AOO's configure script allows the
> use of system provided alternatives:
> apache-commons, apr, apr-util, beanshell, boost, cairo, coinmp, cppunit,
> curl, db, dicts, expat, graphite, hsqldb, hunspell, hyphen, icu, jpeg,
> libtextcat, libtextcat-data, libwpd, libxml, libxslt, lucene, mdds,
> mysql, mysql-cppconn, mythes, nss, odbc-headers, openssl, poppler,
> python, redland, sane-header, saxon, serf, vigra, xrender-headers and zlib.
> Assuming that each of the above mentioned libraries have 4 to 12
> different versions out in the wild this means that between 4^40 and
> 12^40 different configurations are possible, of which we build and test
> only very few (<=4?) regularly.
> The configuration space is increased even more when we consider that
> there are many different kinds of compilers in different versions, also
> linkers etc.
> What would be the simplest approach to address this? Just adding a "use
> the --with-system-X options only if you know that this works or if you
> enjoy debugging"? Or should we hide them behind an
> "--enable-expert-options" configure switch which would be similar to the
> broad "--enable-category-b" option?
For my part, I'd suggest we hide them behind a "--enable-expert-options" 
switch. Given the massive number of configurations, doing such a thing 
could alleviate many headaches, especially given that it could be 
extremely difficult for some of us to reproduce and track down problems 
related to very specific library, compiler, and linker versions.
> Herbert
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message