cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Removing WIN32 dependencies

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Thu, 20 Jul 2006 12:26:22 +0200 (CEST)

On Wed, 19 Jul 2006, Yang Tse wrote:

> Compilation of curl is heavily dependant on the fact of having symbol WIN32
> defined or not.

Indeed.

> In other words this has to be fixed somehow to properly build cross-compiled
> Windows targets and cygwin targets.

Well, we can in fact build curl both cross-compiled and for cygwin already,
even though there's a "nice" set of complicated #ifdef-lines that sets the
foundation for this...

> curl's code is plagued with statements like:
>
> #if defined(WIN32) && !defined(__GNUC__) || defined(__MINGW32__)
> #if defined(WIN32) && !defined(__CYGWIN__)
> #if defined(WIN32) && !defined(WATT32)
> #ifndef WIN32
> #ifdef WIN32
>
> And all of them should be revisited, and most of them modified to fix the
> before mentioned problem.

Yes. We should probably switch to using "proper" ifdefs on features/files in
the sources files and define features that vary between the win32 compilers by
using #ifdefs etc in config-win32.h.

> This could be done using compiler specific defined symbols, but I think it
> is better to try to get rid of most of the compiler dependant symbols in
> source code.

Yes, it'll make it easier to write portable code, both when adding new code to
the library and when porting the existing code to a new platform.

> This could be done introducing a new symbol which could be
> "TARGET_WIN_NATIVE", "WIN_NATIVE" or something similar which would be
> defined in config.h or specific config file when building a Windows native
> target, making source code depend on this new symbol being defined or not
> instead of depending on WIN32.

Do we even need any "native windows" define in the source? If we fix this
setup completely the "native windows" define would instead be converted to a
set of features and we'd then ifdef on those features.

> Somehow related with this is compilation for Windows CE. Windows CE should
> not be treated as a Windows native target, at most it is a subset of WIN32
> and a subset of WinSock with lots of limitations and only a partially
> implemented standard C library. In plain words, WinCE is a different OS than
> Windows, and as such definition of symbols _WIN32_WCE and TARGET_WIN_NATIVE
> should be mutually exclusive.

Well, to extend my reasonsing above, neither _WIN32_WCE or TARGET_WIN_NATIVE
would then be needed but instead the config-wince.h would define a lesser set
of features than what config-win32.h does.

Or doesn't this work?

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Received on 2006-07-20