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: Fwd: [PATCH] Optimized MD5 implementation from OpenSSL
Date Wed, 03 Jan 2007 19:21:26 GMT
Lucian Adrian Grijincu wrote:
> Having a the possibility to give "--disable-ldap --disable-md4
> --disable-xml" as parameters to ./configure or some other
> precompilation routine would be better than having them bundled with
> the library when they are not needed.

You have that, today.  It isn't quite a solution.

If your library relies on a system-installed libapr/libaprutil and you
link to the shared (rather than static) libraries, your code will pull
in all these dependencies that are never triggered.

Don't you dare install a --disable-ldap/--disable-xml shared library
into the system location, or you have borked svn, httpd, and other apps
that consume apr-util and *do* require those features.

Rather, if we dump apr-util, splitting it into apr-ldap, apr-db, apr-dbd
etc, then your program would pull in only the dependencies it (may) use.

I said 'may use' because if you call up apr-dbd, you might find it's built
with support for postgresql, mysql, db2, etc.  That's OK because if you are
using apr-dbd, you probably mean for your end user to be able to tie into
one of several backend providers that are available.  Right?

If you are only supporting one backend, why use apr-dbd in the first place?

But that has no relationship to xml, ldap etc.  Since you don't need those
backends, so there is no reason to pull them in.

One last point, there is no reason for you to build static --disable-ldap
libraries, etc.  If your module doesn't use the apr_ldap_foo() interfaces,
then those .o modules won't be included in the final binary anyways.


View raw message