On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr <h...@apache.org> 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 configure.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: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
