apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: Modular APR
Date Wed, 25 Mar 2009 14:23:34 GMT
On Wed, Mar 25, 2009 at 01:46:22PM +0100, Branko ─îibej wrote:
> IMHO having to link 55 libraries instead of one is a big pain.

The difference should be passing a single extra argument to 
apr-N-config.  Why such a big pain?

> I prefer just putting internal wrappers for 3rd-party stuff into 
> external modules that are loaded dynamically (or, optionally, linked 
> into the base lib if the packager prefers that). Telling the linker to 
> "-lapr" should be enough, regardless of the features you're using.

So there are two distinct cases here:

1) hard dependencies: use of the APR API implies a direct dependency 
between the consumer of the API and a *single* underlying 3rd-party 

 -> xml (libexpat), crypto (whichever crypto library), xlate (iconv)

in all these cases, I want any consumer of the API to have a dependency 
on the underlying library wihch is tracked via SONAMEs.  None of these 
APIs can isolate the user of the code from the library -- if you want to 
use apr_xml.h, you need expat.  If you want to use xlate, you need an 
iconv implementation.  It is desirable and correct that such deps are 
expressed by library linkage and resultant SONAMEs/DT_NEEDED, so that:

a) the runtime linker checks they can be satisfied at app startup, and

b) your package management system of choice automatically translates 
SONAME/DT_NEEDED into package dependencies, and can ensure everything 
"just works"

2) soft dependencies: use of the particular APR API implies an indirect 
dependency on one-of-many compatible implementations.  It's fine for 
this case to push the implementation out to a given DSO.

Trying to use DSOs for case 1 "hard" dependencies:

a) adds bloat and runtime overhead by requiring a stub entry point in 
libapr for *every single API function* which thunks out to a DSO

b) adds unnecessary complexity by having error paths ("the DSO didn't 
load") where none should be needed, c.f. all the poor sods in bugzilla 
who found the LDAP DSO code doesn't work for them

c) increases cost of maintenance because you have to maintain the thunks 
as well as the real API implementation, and make sure they are in sync.

d) increases costs for downstream distributors who have to start 
manually tracking interdependencies between consumers-of-APR and 
particular dependencies, or, more likely, just punt and ensure that any 
consumer of APR pulls in all APR's dependencies.  Which means all these 
costs have exactly zero benefit.

Regards, Joe

View raw message