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