Hi Yang,
Yang Tse schrieb:
> 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.
not an option - just the renaming showed us that we include the wrong
setup.h + wrong config.h when we enable memory debugging - formerly we
didnt even notice.

> 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.
that's only a hack, sure; though what I did for the moment, and restores
the previous sutiation before the renaming.

> 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.
what about option four? Let us just copy over the memdebug files from
the lib so that ares has its own - this way we could include ares
setup.h which includes ares_config.h ...; or what's wrong with this
approach?

Gün.
Received on 2009-07-16