Hi Daniel,
>> good question - but then let me ask why you want to put the hardcoded
>> path on Linux at same place?

> We do? The way I read the code is that if you don't specify a cacert with
> the
> command line tool, it won't set it to libcurl and thus libcurl will use
> the
> default path it was built with. In a typical *nix world, libcurl would be
> built to point to the system's CA cert bundle as used by multiple
> applications/libs.
hmmm, but that's the point: the define I'm taking about _is_ the default path libcurl was build with;
and as you pointed out in previous post it makes no sense to hardcode a path here on non-configure platforms since we dont know nor can figure out where the system's CA cert bundle is located - thus we use the getenv() hack in order to give the user a chance to specify the default location with binary builds.

> I think we should create an empty file for all non-configure cases, and
> #ifdef
> the define properly in the code in the short term, and then work on
> getting
> the define properly defined in lib/config.h instead and get rid of the
> ca-bundle.h file completely.
ok.

>> So I take your first comment as permission to fix it for all Win32 builds
>> the way I proposed it, and after release I will look closer into removing
>> the ca-bundle.h entirely....

> Yes, if you're really quick as I hope to put together a release within a
> few hours!
did already, but only for MingW32 so that it builds fine now independent from MSYS.
The other Win32 stuff I left untouched since with releases ca-bundle.h was empty, and therefore CURL_CA_BUNDLE undef'd all the time (except for MingW32 and Watcom builds were its def'd from makefile);
and I didnt want to change this now.

Guenter.
Received on 2007-01-29