On Thu, 27 Jul 2006, Yang Tse wrote:

> Macros sread() and swrite() are defined in lib/setup.h so the natural thing
> would be to define them in the same way in ares/setup.h or even in
> ares/ares_private.h but the problem is that for debug builds
> ares/ares_private.h pulls lib/memdebug.h and this one pulls lib/setup.h so
> sread() and swrite() would be redefined generating warnings at compile time.

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.

> Obviously the problem is that for stand alone distributions of cares is
> should be available, and the same for libcurl ones. So it seems that it
> should be located as ares/common-deps.h and also as lib/common-deps.h.
> Taking into account that its contents should be the same and always in sync
> it would make sense that they actually were the same file with two different
> paths in CVS.
>
> Is it possible to achive this ?
>
> Or any better or more simple setup ?

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.

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.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html