apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <jor...@redhat.com>
Subject Re: APR 2.0 proposals
Date Mon, 26 Nov 2007 20:58:42 GMT
On Mon, Nov 26, 2007 at 11:29:34AM +0100, Tollef Fog Heen wrote:
> * Joe Orton 
> 
> | apr-config is extended to expose a new interface to select which 
> | sub-libraries an app wishes to link against.
> 
> Pimping my own tool here, but could we make pkg-config the preferred
> interface and deprecate apr-config?  

It's a requirement of the apr/httpd build system that it works out of 
the box on any Unix box without requiring the user to build lots of 
other random stuff first.  At the moment httpd (and similarly I guess 
with Subversion, etc) all depend on apr-config to fulfil that 
requirement.

> | Question: could the sub-libraries become optional-to-build?  Not sure.
...
> On the other hand, is this something we want to have?  It will lead to
> people having trouble moving a binary compiled against apr on one
> machine to another machine, since apr could then easily have been
> compiled with different modules enabled.  The breakage should be
> fairly obvious to debug, though.

Right; but I suppose the normal approach taken to this question is that 
providing APR_ENOTIMPL stubs is the right thing to do, because that 
leaves the door open for applications which can be written to 
*optionally* use the particular API, falling back/failing gracefully at 
run-time if the functions do give APR_ENOTIMPL.

Thanks for the feedback!

joe

Mime
View raw message