On Fri, 24 Sep 2004, Peter Sylvester wrote:

> When using the --with-ssl=/path/to/nonstandard/ssl-version on a system where
> the standard version is installed with a a pkg-info available, includes and
> libs from the pkg-info are added before the non standard location.

That pkg-config info is tricky and I'm not sure how to use the info in all
cases. I think the above statement sounds wrong, so if that is how it
currently works I think we should fix it.

The problem is of course when systems do as Redhat did in Redhat 9: the SSL
includes require that there's a krb-path in the include path since they enable
some krb-stuff in there that requires krb-headers that aren't found in the
default include paths. How is configure supposed to know if that extra info
taken from pkg-config is needed or not when --with-ssl is used? I guess using
--with-ssl should ignore pkg-config and leave it to the user to deal with.

> If I understand the intended logic of the cases for opt_ssl is:
>
> - no => no support at all
>
> - off => try pkg-info (if no support => no)
>
> - yes => try pkg-info or /usr/local/ssl
>
> - * => use the */{lib/include} etc.
>
> Am I right?

Correct. I think I once had in mind that if pkg-config has the info, the
option should be set to 'off' so that it won't also try /usr/local/ssl. I'm
not sure why it doesn't do this atm. The "off" case can't seem to occur.

But, we should move the whole block that checks for pkg-config into the yes
case in the switch and then we can remove the off-case.

Something like the attached patch (against the current CVS version).

Comments?

-- 
      Daniel Stenberg -- http://curl.haxx.se -- http://daniel.haxx.se
       Dedicated custom curl help for hire: http://haxx.se/curl.html