RE: [xml] Windows build

[Eric Zurcher csiro au]

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>
> > #else
> > #include <libxml/xmlversion.h>
> > #endif

> 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.

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:
        catalog.h
        encoding.h
        nanoftp.h
        nanohttp.h
        schemasInternal.h
        tree.h
        xmlautomata.h
        xmlIO.h
        xmlmemory.h
        xmlregexp.h
        xmlschemas.h
        xmlschemastypes.h
        xpathinternals.h

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
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.

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, xmlversion.h.in), where the Borland compiler
should be included in those conditionally defining LIBXML_DLL_IMPORT. In my
version, I have changed:

#ifndef LIBXML_DLL_IMPORT
#if (defined(_MSC_VER) || defined(__CYGWIN__)) && !defined(IN_LIBXML) &&
!defined(LIBXML_STATIC)
#define LIBXML_DLL_IMPORT __declspec(dllimport)
#else
#define LIBXML_DLL_IMPORT
#endif
#endif

to:

#ifndef LIBXML_DLL_IMPORT
#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)
#else
#define LIBXML_DLL_IMPORT
#endif
#endif

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
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?

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