Re: [xml] Windows build

[Igor Zlatkovic <igor stud fh-frankfurt de>]

Hi Peter,

> > That is clean, yes. The problem is that we don't have a fixed set of
> > compiler-features, but every compiler has its own oddities. Common
features
> > are rare. What I thought is rather something like
> >
> >   #ifdef __MSVCRT__
> >   #undef snprintf
> >   #define snprintf _snprintf
> >   #endif
>
> But this is a perfect example of a common feature. Every compiler strictly
> complying to ANSI/ISO (before C99) was bound not to use "snprintf".
>
> So without a compiler/feature split, you keep getting requests for "||"
> clauses in the above conditional.

Wait... I'm confused. Adding a

  #ifdef _MSC_VER
  #define __MSVCRT__
  #endif

and a

  #ifdef __BORLANDC__
  #define __MSVCRT__
  #endif

few rows earlier produces exactly what you proposed, not true? The only
difference to my version is that these two are defined in the makefile, not
in the source. I fear that would force people to use a specific runtime with
a specific compiler.

Your proposal is good and I agree with it. I would just make this
runtime-specific macro an exception to that rule and have it defined outside
libxml code. This __MSVCRT__ does not specify a compiler-feature, it
specifies which runtime is used. In the above example, the availability of
snprintf is a runtime-feature, it has nothing to do with the compiler.

> That doesn't help, as (Gott strafe Microsoft!) winsock.h and winsock2.h
> includes windows.h. Use any of the Win32 headers and most likely the
> rest of gang will follow.

That is the sad truth.

> Without actually checking the newest CVS version, I was under the
> impression that limiting inclusion of winsock.h will be dropped.

Ahaaaaa, now I get it. No way. The inclusion of winsock.h is still guarded
by the same mechanisms. Winsock.h will be included only where needed, means
in nanohttp.c and nanoftp.c.

The WinSock things have been moved to their own file, so that an Unix-hosted
cross-compiler can make use of those WinSock->Berkeley compatibility macros
without getting the rest from win32config.h. That's all. The logic of
including winsock.h or not remains the same.

Ciao
Igor