Re: [xml] Windows build



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]