Re: [xml] Windows build

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

Hi Eric,

> While you're tinkering with the Win32 configuration and header
> files, would you be willing to add a few additional
> modifications to better support Borland C++ Builder?

Od course, yes. What must be done?

> For example, many of the headers currently use the
> following construct:
>
> #if defined(WIN32) && defined(_MSC_VER)
> #include <libxml/xmlwin32version.h>
> #else
> #include <libxml/xmlversion.h>
> #endif
>
> Neither WIN32 or _MSC_VER are predefined by the Borland
> compiler, yet the xmlwin32version.h header is the appropriate
> one. I've been circumventing this problem by using a manually
> generated libxml/xmlversion.h that just includes the win32
> version, but that's a somewhat ugly solution.

Actually, xmlversion.h and xmlwin32version.h are identical here. That
clearly makes one of them obsolete. The configuration script on my platform
generates xmlversion.h from its respective .h.in. Then it copies
xmlversion.h over xmlwin32version.h.

It would be generally better to concentrate on xmlversion.h, as that one is
always up-to-date in respect to those LIBXML_*_ENABLE macros.

> There are other places where code conditionally included when
> _MSC_VER is defined would also be applicable to the Borland
> compiler. (For example, the definitions for isinf and isnan.)
>
> Of course it would be easy to manually define _MSC_VER when
> using the Borland compiler, but that would then make it
> difficult to deal with those cases where the two compilers do
> differ in their behaviours.

Does Borland C++ Builder use its own runtime, or does it rely on
Microsoft's? 99% of those _MSC_VER checks actually check for the MS runtime,
not for the compiler. Threads.c is the only file where something specific to
the MS compiler is used, everything else actually refers to the MS runtime.
I have, possibly wrongly, assumed that MSVC and mingw were the only
compilers who use MS runtime and all others have their own.

Since my compiler does not define anything specific to the runtime, we can
agree on what mingw defines (namely __MSVCRT__) and check for that whereever
the runtime is an issue. That would then be cleaner and compiler
independent. I would then define that in my makefile, mingw defines it per
default anyway, and all other compilers who use MS runtime (or a compatible
one) would then define it in their makefiles or IDE project files. A check
for _MSC_VER would then be limited to threads.c.

Is that an option?

Ciao
Igor