apr-dev mailing list archives

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.