William A. Rowe, Jr. wrote:
I can strongly disagree by looking at how many feature-tests and strange macro comparisons are used in util_ldap or mod_authnz_ldap of httpd. Clearly we've failed - it isn't anywhere near ready for run-time alteration of a provider, eh?
No - it means that people have been placing the macro comparisons in the wrong place.
The solution is to move these to the right place.
++1; the point isn't to ponder dropping one for it's bugs, but to set out to add functionality to apr-util-1.3 to break our compile-time dependencies on the consumer of apr-util, and in apr-util-2.0 to deprecate bogusness.
The basic problem we face is that in Unixland we have the autoconf system that is capable of running lots of pre-compile time tests, and so create a header file that can list in detail what symbols are available, and what possibly incompatible symbols we should choose from on this particular platform.
In Windowsland, to my knowledge, we have no such tool - we must hardcode a set of expected behaviour into the code and hope for the best. If two different versions of Windows come out with incompatible APIs (and this is happening more and more i seems), then we end up working on one combination and not working on the second combination.
To fix the LDAP code, we need to find a way to determine which Windows API we are building against, so the right set of ifdefs are used. This either needs to happen before compile time, ie at autoconf time, or at compile time.
As to breaking compile time dependencies, to my knowledge APR binds to just a single version of postgres, a single version of mysql, a single version of the available SSL libraries, etc. It is not clear why consumers of APR should expect multiple possible versions of LDAP libraries to available to them, but only one version of postgres.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
