apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Garrett Rooney" <roo...@electricjellyfish.net>
Subject Re: APR 2.0 proposals
Date Mon, 26 Nov 2007 20:10:15 GMT
On Nov 26, 2007 2:55 PM, Ryan Phillips <ryan-apr@trolocsis.com> wrote:
> Joe Orton <jorton@redhat.com> said:
> > ** Key proposal: "one tree, multiple libraries"
> >
> > Justin has long argued that there is no point in having apr and apr-util
> > as separate trees since everyone uses both or neither, and I agree.  The
> > fact that every downstream application picks up depdendencies on half
> > the third-party libraries in existence by linking against apr-util -
> > regardless of whether or not the app uses them - is also a real problem.
> >
> > I think the way forward is to consolidate apr and apr-util into a single
> > tree, but where the code exposes a dependency on a third-party library,
> > build that code into a separate library.  So along with libapr, you get
> > a libapr-dbm for the DBM code, a libapr-xml for the XML code, etc.  (I
> > know various people have talked about various things along these lines
> > before; not claiming this is an original idea! ;)
> I agree APR and APR-util should be combined into one, but I hate the notion
> of chunking the library into multiple parts.  If a developer wants to
> disable a feature, then a simple --without-xml or --without-dbm should
> suffice.
> What is the benefit in chunking a library?  In the case with embedded
> projects (which I work on), I am more inclined to simply disable the bits I
> am not using on the configure line and be done.  I don't care that they are
> split into libapr-xml and friends.

I'm sorry, but --without-foo simply doesn't cut it.  Relying on
configure time flags means that any linux distro that packages up APR
needs to build in any options that a potential application that links
against APR would want, which means that the ones that DON'T need DBD
or XML or DBM or whatever are out of luck, they're stuck with the
implicit dependency, so you get situations like Subversion linking
against postgresql client libraries and other such nonsense (which can
easily happen today with a statically linked APR-Util).  Separate
libraries remove all of these problems, and I don't really see the
down side.


View raw message