2006/7/27, Daniel Stenberg wrote:

> Note that the debug builds that involve c-ares are considered a huge hack.
> c-ares and libcurl are different projects and products and they need to do
> their things apart from each other.
>
> The reason the debug builds don't fully "keep things apart" is simply because
> I like our curl-way of doing memory tracking/debugging and I've found it
> convenient to check c-ares the same way.

Yes, any c-ares build with CURLDEBUG defined will pull memdebug.h from
libcurl and in turn as a 'nice' side effect it will be pulling into
compilation of c-ares libcurl's setup.h and curl's curl.h along with
libcurl's config.h

In case there is a a conflicting definition done in libcurl's config.h
with one in c-ares config.h, the unwanted side effect, or feature, is
that libcurl's config.h definition will override c-ares's one.

> I think I would rather have code in the c-ares headers that check for some
> specific curl-define (that only is defined when the curl memdebug.h header is
> included) and then it can undefine whatever macros/defines that it itself
> wants to define, like sread() and swrite() etc.

The problem is that memdebug.needs to be the last header included, so
any new symbol defined in memdebug.h should not be visible by c-ares
headers. As a matter of fact we might want the opposite, make
memdebug.h pull only the absolute needed minimum of libcurl when being
used from c-ares.

Seems trivial, but actually as you said debug builds that involve
c-ares are a huge hack, that serve the purpose of detecting memory
leaks.

> We might move away the c-ares CVS repo from the curl one in the future and we
> must not add "hard" connections between them that aren't allowed to deviate.

It seems I had the wrong impression that it was the opposite way, and
that some day c-ares could be fully merged into libcurl's codebase.

Do we have any numbers or feedback about the use of stand alone c-ares
without libcurl ?

Finally, what I've done is create two new header files
lib/setup_once.h and ares/setup_once.h which use the same symbol
__SETUP_ONCE_H as multiple header inclusion prevention definition.

In this way the connection between libcurl and c-ares is kind of soft.
Each one can compile without having the other one, so moving away the
c-ares CVS repo from the curl one shoul be no problem.

And on the other hand, when both are available definitions done in
setup_once.h of one package will not get overridden by those done in
setup_once.h of the other package even when doing a debug build which
includes libcurl's memdebug.

setup_once.h is pulled from the end of each package's setup.h

The only requirement for this to work as intended is that both files
use the same symbol __SETUP_ONCE_H as its respective multiple
inclusion prevention symbol. The first file to define it will prevent
the other from being included.

-- 
-=[Yang]=-