RE: SV: [xml] windows binary with different calling

[Eric Zurcher csiro au]

Peter Jacobi has already provided a better explanation than I could of 
why FUNKY_FUNCTION_MACROS are commonly used in the Windows world. 

I can only add that for me, creation of the .def file has not been 
completely automatic. I build and use libxml2 using the Borland C++ 
compiler, which does not use the same conventions as Microsoft's. By 
default, the Borland compiler prefixes an underscore before the names 
of global identifiers (including function names) in object files. And 
the Borland linker does not recognise the "DATA" keyword in .def file 
EXPORT statements. This means I need to adapt the libxml2.def file 
before I can use it.

Admittedly, this has been only a rather minor inconvenience, but I'm a 
lazy bastard, and I'd rather not have to deal with it at all.

OK, OK. Don't tell me. I already know what I need to do. I should make 
modified copies of Igor's defgen.xsl and Makefile.msvc that work
correctly with the Borland compiler, then check them in for everyone to 
enjoy. That's fine. Give me a few days and I'll see what I can do... 

> -----Original Message-----
> From: Daniel Veillard [mailto:veillard redhat com]
> Sent: Wednesday, 4 June 2003 6:05 PM
> To: Eric Zurcher csiro au
> Cc: xml gnome org; igor zlatkovic com
> Subject: Re: SV: [xml] windows binary with different calling
>
>
>   Any function with its signature in the .h headers are public functions
> part of the API, all of them, no distinctions. There is no need to fiddle
> and argue this one is or is not public, if it's listed in the .h it's
> public, period !
>
>   I *still* do not understand the finality of flagging the functions that
> way. Can someone explain in plain english why making the export list as
> a .def file is a problem ! For me the huge difference is that the .def
> file is now generated AUTOMATICALLY ! So you need to argue clearly about
> why we need to break the existing, working, automated system to fall back
> to a manual mechanism, intrusive in the code, and non standard to the C
> language. I won't make this without a well argumented explanation and
proof
> that the current system is not adequate.
>
>   YOU, yes you ! Why would you "be happy" about it ? You say "This might
> seem like" a positive change for Windows, why being so shy ? Why dou *YOU*
> need it, dammit ?  Why do you "suspect" other platforms need a
non-standard
> extension ? I never got such feedback (or I can't remember), so give 
> *real* arguments, coming from first hand source.
>
> Daniel

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