Re: Disconnecting -lldap from utilizing apr-util

[William A. Rowe, Jr.]

Joe Orton wrote:

On Thu, May 15, 2008 at 05:17:00PM -0500, William Rowe wrote:

http://people.apache.org/~wrowe/ldap/apr-util-1.x-ldap.patch

As expected, this breaks source compatibility, as defined by the APR versioning guidelines. The fact that you need to patch httpd to make httpd continue to build seems like ample demonstration that source compatibility is broken ;) So it's 2.x material, and because it's 2.x material the DSO stuff is unnecessary, the LDAP code can simply be moved into a separate library.

You know, I don't buy it.  Not the bit of splitting into multiple libs
for 2.x, that's a possibility but possibly unnecessary if the dso approach
serves us well.  (In fact, this might get us to the point of merging all
-util into the base apr-2.  Something to ponder.)

No - I'm not buying that we've broken a rule...

There is no assurance that you have an apr-util built --with-ldap period.

If you have one, the source code is compatible.  APR is not the author of
ldap_* namespace.  Anyone who detected (the same) ldap as apr-util is not
affected.

The source code (.c) compiles identically against version 1.3.0, there is
no source code API change.

There *IS* a build system schema change.  I don't see where we wrote out
the versioning rules for building APR.  But I beg to differ with you, this
change does not violate versioning guidelines.

Otherwise:

- surprisingly simple patch, kudos

Thanks.  Simple in retrospect, PITA to author ;-)

- the pool lifetime stuff is probably dodgy because in 1.3.x you can now create unparented pools, i.e., there's no longer any guarantee that following pool->parent gets you to the APR global pool which lasts for the lifetime is the process. (who knows what else that new misfeature may break)

Then do we all decide that there is a global pool and an API to obtain it?
I know how to do this, but I'm just asking if that's how to go.

The reason for this of course is that people do want to consume APR in their
libraries, which means consumers X and Y might not even be an "application",
and may not start up and shut down at the same time.

- mingling the autofoo in with the DBD autofoo is obviously ugly ;)

You mean DSOfoo with DBDfoo I presume.  Yes, patch inc.