On Wed, Mar 18, 2009 at 9:05 PM, Piotr Dobrogost <pd_at_curlpp.org> wrote:
> Daniel Stenberg wrote:
>> On Wed, 18 Mar 2009, Piotr Dobrogost wrote:
>>
>>> I take it from the above excerpt that naming of ssl parameters in
>>> libcurl's build script is misleading at least. It looks like
>>> --with-ssl refers only to OpenSSL. Shouldn't it then be called
>>> -with-openssl instead? This way one wouldn't have to give
>>> --without-ssl with other SSL libs.
>>
>> I would rather have it test for each different lib, one by one and pick
>> the first one that works.
>
> Nice idea but I think
> - it shouldn't be the default behavior
> - users should have more control over this process
>
> To resolve these two problems I would suggest adding something like
> --try-with-openssl, --try-with-gnutls, --try-with-nss
> for the feature you proposed and I would change current --with-ssl to
> --with-openssl.

--with-something is a standard part of autoconf. --try-with-something is not :)

Normally the way it works (I am not talking about libcurl in
particular) is configure may or may not try to work out for itself
what SSL lib (or whatever) is available on the system. If configure
is not written to look for itself (i.e. default is no SSL lib) then
using --with-ssl (or --with-ssl=yes) will cause it to search for a
compatible SSL lib, and --with-ssl=/usr/local/ssl will tell configure
exactly where to look. Some projects also use something like
--with-ssl=/usr/local/include:/usr/local/lib or --with-ssl=yes
--with-ssl-includes=/usr/local/include --with-ssl-libs=/usr/local/lib.

Maybe --with-ssl (or --with-ssl=yes) could search for various SSL
libs, e.g. OpenSSL (or compatible), then if not found, GnuTLS, and if
that is not found, then NSS. --with-ssl=no or --without-ssl would
disable SSL support completely. If someone wanted to force NSS even
if they had OpenSSL installed, then maybe this would work: --with-ssl
--with-ssl-nss (optionally with =/usr/local/nss). Or should that be
--enable-ssl --with-ssl-nss=/usr/local/nss?

But actually I don't mind the way it is now :)

-- 
Michael Wood <esiotrot_at_gmail.com>