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 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?
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: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
