Daniel Stenberg wrote:

> On Thu, 2 Apr 2009, Piotr Dobrogost wrote:
>
>>> I don't. To me, backwards compatibility and "working the same as the
>>> previous versions" is a very dear concept that I go very far to
>>> maintain. Thus --with-ssl should remain and it should pritoritize
>>> openssl even with my suggested changes, to remain working the exact
>>> same way for the existing users who use --with-ssl and thus have
>>> OpenSSL installed.
>>
>> How about adding warning about the change of meaning of --with-ssl
>> option in a couple of releases before the actual change?
>
> That could work, but I'd rather proceed as I already have explained and
> I don't see how that would need any warnings at all!

Doing this as you proposed wouldn't change the meaning of --with-ssl so
no warnings would be needed of course.

But I'd like to stress out that having OpenSSL singled out in build
process just because that used to be this way is not the cleanest design
of this configuration feature. We can make better by treating all ssl
libs in the same way.

In your proposition how would one build curl with NSS support;
--without-openssl and --with-nss ?

-- 
Piotr Dobrogost
*** curlpp.org - c++ wrapper for libcurl ***