On Thu, 30 Aug 2007, Guenter Knauf wrote:

> I believe I've fixed the points you rised now, here's the 2nd shot:
> http://www.gknw.net/test/curl/ldaps/configure.ac.diff

I think it looks fine!

> another question about the output screen: currently we have a couple of
> times 'ebabled' and (now) 2 times 'yes' for features output; should we make
> that all same = change all to 'enabled'?

Yes, I think it makes sense to use the same word for it on all lines. Let's
use "enabled" on them all.

> finally another question regarding the var naming: now I set already
> CURL_DISABLE_LDAPS from configure which is currently unsused, but also
> HAVE_LDAP_SSL to enable ldaps; should I exchange the

> #ifdef HAVE_LDAP_SSL
> with
> #ifndef CURL_DISABLE_LDAPS
> in the code??

> That would however require that all non-configure platforms get this define
> by default, or else they build with ldaps support by default; another option
> would be to change to '#ifdef CURL_ENABLE_LDAPS', or probably 'USE_LDAPS' ??

Well, I think the names are for different purposes. The HAVE_* defines are
what are detected and checked by configure and says what the system has
available or can do. The CURL_DISABLE_* fines are then options that may select
to ignore what the system has available and build without support for that
anyway.

I think in general we've taken the approach to use a _third_ define in the
code, like USE_LDAPS which then gets set in setup(_once).h like:

#if defined(HAVE_LDAP_SSL) && !defined(CURL_DISABLE_LDAPS)
#define USE_LDAPS 1
#endif

... and I think this approach is rather good since it keeps the defines
separated for their specific uses.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html