RE: [xml] Windows build

Hi Igor et al.

-----Original Message-----
From: Igor Zlatkovic [mailto:igor stud fh-frankfurt de]
Sent: Tuesday, 1 October 2002 8:42 PM
To: Eric Zurcher csiro au; xml gnome org
Subject: Re: [xml] Windows build

For example, many of the headers currently use the
following construct:

#if defined(WIN32) && defined(_MSC_VER)
#include <libxml/xmlwin32version.h>
#include <libxml/xmlversion.h>

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

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

Ah, you're quite correct. I must confess that I was stupid and built libxml
without first running the configuration script. Mea culpa.

Since xmlwin32version.h and xmlversion.h are now identical after configuring
for the Windows platform, then the conditional construct which I mentioned
earlier is actually obsolete, and could (and should) be removed from:

The less conditional code the better! <G>

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
not for the compiler. Threads.c is the only file where something specific
the MS compiler is used, everything else actually refers to the MS
I have, possibly wrongly, assumed that MSVC and mingw were the only
compilers who use MS runtime and all others have their own.

BCB does use its own runtime, but it has been designed to be highly
compatible with the Microsoft runtime. I would have to check the specific
instances to be sure, but in most cases the runtimes contains identically
named functions with identical (or nearly indentical) behaviours. One
example would be the "_isnan" and "_fpclass" functions.

Actually, for Borland compatability, the main change is just a minor one to
xmlversion.h (or, rather,, where the Borland compiler
should be included in those conditionally defining LIBXML_DLL_IMPORT. In my
version, I have changed:

#if (defined(_MSC_VER) || defined(__CYGWIN__)) && !defined(IN_LIBXML) &&
#define LIBXML_DLL_IMPORT __declspec(dllimport)


#if (defined(_MSC_VER) || defined(__CYGWIN__) || defined(__BORLANDC__)) &&
!defined(IN_LIBXML) && !defined(LIBXML_STATIC)
#define LIBXML_DLL_IMPORT __declspec(dllimport)
#elif defined(__BORLANDC__) && defined(__DLL__)
#define LIBXML_DLL_IMPORT __declspec(dllexport)

The macro __BORLANDC__ is predefined for the Borland compiler. The __DLL__
macro is automatically defined when building a DLL. 

Since my compiler does not define anything specific to the runtime, we can
agree on what mingw defines (namely __MSVCRT__) and check for that
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
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?

Probably, so long as we can regard __MSVCRT__ as implying "uses a runtime
compatible with the Microsoft runtime" rather than the more strict "uses the
Microsoft runtime".

Eric Zurcher
CSIRO Livestock Industries
Canberra, Australia
Eric Zurcher csiro au

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