[mapguide-internals] Berkeley DBXML native libraries on Linux

[Jason Birch]

The dbxml download page seems to be fairly tight on what versions it
requires, and would need xerces-dev, etc with headers.

On 2010-05-20, Tom Fukushima <tom.fukushima at autodesk.com> wrote:
> I think that option 3 is the way to go as well.  I'm assuming that users can
> also do things like "yum install xerces" instead of having to build it from
> source; in which case, this seems pretty standard.
>
> Tom
>
> -----Original Message-----
> From: mapguide-internals-bounces at lists.osgeo.org
> [mailto:mapguide-internals-bounces at lists.osgeo.org] On Behalf Of Robert
> Bray
> Sent: Thursday, May 20, 2010 8:08 AM
> To: 'mapguide-internals at lists.osgeo.org'
> Subject: Re: [mapguide-internals] Berkeley DBXML native libraries on Linux
>
> Trevor,
>
> I prefer option 3. It's much more inline with the way other open source
> projects manage dependences.
>
>
> Bob
>
> ----- Original Message -----
> From: mapguide-internals-bounces at lists.osgeo.org
> <mapguide-internals-bounces at lists.osgeo.org>
> To: MapGuide Internals Mail List <mapguide-internals at lists.osgeo.org>
> Sent: Thu May 20 06:59:50 2010
> Subject: [mapguide-internals] Berkeley DBXML native libraries on Linux
>
> Hi everyone,
>
> Rohit has been working on switching to native libraries for Berkeley DB,
> Berkeley DBXML, xerces, xalan, and xqilla.  As it turns out, Berkeley DB is
> the only library included in most distributions:
>
> Berkeley DB - included in most distros
> Berkeley DBXML - not included in any distro Xerces - included in Ubuntu only
> Xalan - included in Ubuntu only xquilla - included in Ubuntu only
>
> Furthermore, Oracle does not release binaries for these libraries on Linux.
> They do package Windows installers though.
>
>
> I think we have a few of options:
>
> 1. Keep Berkeley DBXML and all dependencies in our vault and upgrade as
> required.
>
> 2. Build and distribute binaries and headers for the various packages.
>
> 3. Document where to get the required source code and let our user base
> build the required components.
>
>
> Options 1. and 2. put the onus on us to maintain the components.  Option 1
> will continue to clog up our source tree and makes it more difficult to
> share components with FDO.  Option 3 is a trade off.  It makes it more
> difficult to build MapGuide but is more flexible and allows us to share
> components with FDO.
>
> Any thoughts?  Other suggestions?
>
> Regards,
> Trevor
>
>