Yang Tse wrote:
> Hi Gün,
>
> Relative to the current regression state in which it is impossible to
> build libcurl with c-ares and memory tracking enabled, you have
> several options...
>
> 1) The easy way. Revert the renaming of config.h to curl_config.h and
> ares_config.h.
>
> 2) Modify c-ares API in order to make c-ares capable of using memory
> functions provided/specified by the program or library using c-ares.
> This will obviously require some changes in how libcurl initializes
> c-ares in order to specify the memory functions.
>
> 3) Somehow modify include path(s) to make the magic happen again.
>
> Option two would be another step towards minimizing the build time
> coupling between c-ares and libcurl, and should allow using libcurl's
> memory tracking even with with a c-ares shared library. It could
> happen that memory tracking isn't the last step in fully decoupling
> c-ares from libcurl autobuilds, in this case further analysis and work
> would be required or option one would be equally required.
>
> Option three would further tighten the already existing coupling
> situation, and would require deep examination of non-automake
> makefiles to make sure no build regression is introduced.
>

I was able to get c-ares working with the CMake build. It required
moving the -I stuff around a bit, but I did get it to work. If the
curl -I stuff comes first it seems to work. I only tested on windows.
BTW, the CMake build now has a c-ares option.

-Bill
Received on 2009-07-16