openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Schenk <>
Subject Re: Using system boost 1.54 (was Re: EXTERNAL: Re: Building comphelper)
Date Wed, 08 Jan 2014 18:52:51 GMT
On Wed, Jan 8, 2014 at 2: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.

yes...but if a developer is using a local boost, might they inadvertently
include some config options that might not be compatible with OpenOffice's
build process? This was my concern when I saw this.

>  I ditched using my local boost_1.54, and things are going much much
>> better.
>> Not quite there yet but close. :}
> Yay!

yes, got a good build! YAY! Indeed!

>  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?

Your analysis above is well-taken. And, dealing with configure options,
which local configure options might be helpful, and which ones might be
more challenging, is an interesting question. These are topics that should
be discussed in a new thread, I think.

I know we all want developers to have a "good" experience and providing
more clarification on how the configure options effect the outcome will
certainly help.

Thanks again for all your help with my build problems...

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


"Cats do not have to be shown how to have a good time,
 for they are unfailing ingenious in that respect."
                                       -- James Mason

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message