Hi Bill, William A. Rowe, Jr. schrieb: > -1... yes it might be present, but it is a waste of process resource > to have a fixed binding for the 90% of apr apps that don't make ldap > queries. The idea is to pull in only the bindings used and save > a bunch of effort in the run time linker resolution table. It gets > worse and worse as apr offers more lib support. And this is nothing > more than what 'just in time' run time linking does, anyways, only > we rolled our own. Do we need 15 additional libraries loaded for > 'hello world'? > > Aside from which, there are three clients that can reasonably be > expected to be plugged in on win32; openldap, netscape or microsoft. four: + Novell CLDAP - works great :) > As this is further abstracted, it becomes easy to substitute to > work around interop quirks with different servers (although never > 'all at once', more of a 'pick one' solution). > > However Netware wants to handle it is fine, but we certainly don't > want Windows to regress here. sorry, but you completely missed the subject in first place here - before we talk about what should be default or what not we need to agree about a proper way how we handle to build one 'driver' as DSO and link another 'driver' statically; once this is done everyone can simply decide with a define change; currently this is impossible, and is like we both said: only all or nothing. So I'd suggest that we decouple the dynamic 'driver' builds from APU_DSO_BUILD, and add separate defines for it, like: APR_HAS_LDAP 1 APR_HAS_MYSQL 1 APR_HAS_PGSQL 1 ... #if APU_DSO_BUILD APR_HAS_LDAP_DSO 0 APR_HAS_MYSQL_DSO 1 APR_HAS_PGSQL_DSO 1 ... #endif
Gün.
