On Wed, Jan 8, 2014 at 11:14 PM, Herbert Duerr <h...@apache.org> wrote:
> 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
>
coming soon...hopefully with more information pertaining to the your
comments here
>
> 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
>
>
--
-------------------------------------------------------------------------------------------------
MzK
"Cats do not have to be shown how to have a good time,
for they are unfailing ingenious in that respect."
-- James Mason
