apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: APR 2.0 proposals
Date Fri, 23 Nov 2007 16:22:43 GMT
Joe Orton wrote:
> ** 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! ;) 
> 
> apr-config is extended to expose a new interface to select which 
> sub-libraries an app wishes to link against.
> 
> Question: could the sub-libraries become optional-to-build?  Not sure.

I think solving this resolves 80% of the second proposal, and ensures the
success of the third proposal ;-)

DBM/DBD are on the right-track.  But not yet on unix.  I hope to have the
working "dynamic" build of these db providers working on unix by end of mo,
because it's critical to one of my own projects.

If LDAP/expat/ssl can be similarly refactored, and only dynaload once the
specific apr object is initialized, then static bindings are very greatly
simplified.  Static builds do become a real PITA though, since we want to
let the linker do what linkers do, and bind the real apr_ldap* and ldap sdk
libraries, and then drop it all when no symbols are refereced.  There's yet
a good case for a hybrid build (static apr fn's with dynamic stubs).

This means that LDAP/expat/ssl are unbound from single library support, at
least once additional plugins are authored.  OpenSSL/FIPS adds complexity,
but it can be dealt with for those who insist on such things if we provide
for it at ./configure time.

So keep the resulting apr(-util) link library free of these dependencies,
let them depend on plugable loadable modules that apr manages, and much of
our prior runtime/linktime frustration will disolve.  This simplifies the
process of adding system packages as well. (And the more sophisticated can
be aware that installing bdb4 + apr opens up the opportunity to install
an apr_bdb, etc.)

I have only one lingering question; this iteration of apr(-util) is not
entirely likely to be ready for apached 3.0, but is probably close to
being ready for httpd 2.4; are we looking at a 1.3 iteration before we
make such radical changes as 2.0?  If so, when?  I'd love to see 1.3
come together over the next month or two for those who don't want to
wait on/depend upon such a major release bump.

(After all, you can only just-now rely on some apr package, most likely
some 1.2, being available from most distros).

Bill


Mime
View raw message