On 01/08/2014 07:52 PM, Kay Schenk wrote: > On Wed, Jan 8, 2014 at 2:32 AM, Herbert Duerr <h...@apache.org> wrote: >> [...] >> 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.
If the system boost version is new enough and its config.hpp matches to the rest of its headers then it should be possible to make AOO build with it. If there are platforms where the system boost's default configuration doesn't work for building AOO then AOO should be adapted for it. Patches for that situation should be integrated if they don't cause regressions for other platforms / the boost version AOO brings along. >> 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. +1 I have to admit that I'm not an expert on autoconf, so I don't know whether we can make options disappear for e.g. a non-expert mode. But at least a better grouping of these options should be possible. > 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. +1 again Even people who worked for many years with the OpenOffice code often don't really know the exact impact of each configure switch. Many use their "tried and working" configure scripts and almost never deviate from that. E.g. for each of --with-system-X switches it is very hard to answer how enabling it would impact the build and the result, especially when X is available in a couple of different versions and configurations. But this might be an interesting opportunity for volunteers? E.g. when trying to figure out the impact of the --with-system-hunspell switch one could install one hunspell version after the other on the different platforms, do a clean build with each of them and test the install set. The experience gained from these iterations could result in a much improved description of such a configuration switch, which would be very much appreciated by everyone. > Thanks again for all your help with my build problems... You're welcome! Herbert --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org