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
