curl-library
Re: Removing WIN32 dependencies
Date: Fri, 21 Jul 2006 18:14:14 +0200
> 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.
I'm afraid that at this point I'm unable to see how the whole picture
would look like for some cases. I'll try to explain myself.
As a general rule it should be Ok to protect _all_ header file
inclusion with its respective check. In code it would be:
#ifdef HAVE_HEADER_H
#include <header.h>
#endif
I think that making this change for all non-curl headers is safe to do
as long as configure actually checks for all of those headers and
defines HAVE_HEADER_H if appropiate. Can I make this change ?
Now let's go with what I'm unable to fully understand. Let's take for
example the following part from easy.c
#if defined(WIN32) && !defined(__GNUC__) || defined(__MINGW32__)
#include <time.h>
#include <io.h>
#else
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
#endif
...
#ifdef HAVE_SYS_SELECT_H
#include <sys/select.h>
#endif
#endif /* WIN32 ... */
I think that it pretends to include <time.h> and <io.h> only if we are
building a Windows Native target, and will include <sys/socket.h>
<sys/select.h> if not.
How should we address this if we were to remove/change the check for
symbol WIN32 ?
For example cygwin would have all four HAVE_TIME_H, HAVE_IO_H,
HAVE_SYS_SOCKET_H and HAVE_SYS_SELECT_H defined. But <time.h> and
<io.h> should only be included for a Win native target
while <sys/socket.h> and <sys/select.h> should be included for the
unix like target.
Maybe it is not "our problem" and cygwin/gcc should properly protect
its header files in a way that only the ones that are intended for the
a specific target being compiled should be exposed/available.
But I'm afraid that cross-compiling under other environments could
have the same problem. So in the end we'll face it again even if
cygwin/gcc was changed.
I think that msys/mingw32 has the same problem it exposes UNIX headers
even when it is suposed to build a Win native target.
-- -=[Yang]=-Received on 2006-07-21