apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Phillips <ryan-...@trolocsis.com>
Subject Re: APR 2.0 proposals
Date Mon, 26 Nov 2007 19:55:58 GMT
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

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.


View raw message