* 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? pkg-config is increasingly becoming the standard way of providing build time information. Currently, the way to do this would be to do pkg-config --libs apr-util-dbd apr-util-buckets, but if somebody comes up with a good and general UI for it, I'd be happy to include that in pkg-config (since other projects might reasonably want this too). «pkg-config --libs --enable-modules A,B,C apr-util»? | Question: could the sub-libraries become optional-to-build? Not sure. I don't see why not. You'd have to do dependency tracking internally (if part A of apr needs part B, you obviously can't build A without also building B), but assuming a not-too-complex dependency graph it is doable. 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. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
