Hi Gisle,

On Thu, Jan 10, Gisle Vanem wrote:

> lib/Makefile.m32 has this:
>
> ifdef ARES
> INCLUDES += -I"$(LIBCARES_PATH)"
> CFLAGS += -DUSE_ARES
>

Yes that's a problem with makefiles which don't write a curl_config.h
file and expect to fully control build behavior even when a
config-platform.h provided file defines default settings, and both try
to define build time macros..

config-platform.h in this case (config-win32.h) should be defining
USE_ARES and verifying that USE_THREADS_WIN32 is not defined when
"WITH_ARES" or "ENABLE_ARES" is defined.

config-win32.h should verify that USE_ARES and USE_THREADS_WIN32 are
none defined when "WITH_SYNC_DNS" or "ENABLE_SYNC_DNS" is defined.

config-win32.h should define USE_THREADS_WIN32 and verify that
USE_ARES is not defined when "WITH_THREADS_WIN32" or
"ENABLE_THREADS_WIN32" is defined. (This should also be the default
behavior when none of "WITH_ARES" or "ENABLE_ARES", "WITH_SYNC_DNS"
or "ENABLE_SYNC_DNS" are defined).

In this way makefiles could define one of "WITH_ARES", "WITH_SYNC_DNS"
or "WITH_THREADS_WIN32" ("ENABLE_ARES", "ENABLE_SYNC_DNS" or
"ENABLE_THREADS_WIN32") and merrily expect intended behavior.

Notice that changing this in config-win32.h affects all makefiles
which can be used to build a win32/64 target. Your proposed change
would equally affect same number of makefiles.

Decoupling of "non-configure" make-time macro names from those used to
actually configure the build is something we should be aiming at. And
as this case shows it is even mandatory to allow full option usage.

I'm personally not going to make this changes happen any time soon,
nor I'm ready for another naming-quarrel. So if you or anyone else
wants to take on this, please do so.

Thanks,

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html