RE: [xml] Header taint

[Eric Zurcher csiro au]

Igor,

I'm a bit confused about the "*exports.h" files. I don't see these in CVS,
and all the 
#define directives appear to be in xmlversion.h.in. Also, the
win32\Makefiles don't appear to have been updated. In addition to no longer
requiring the .def file (which
doesn't matter), I think they need to have dict.obj and SAX2.obj added to
their dependency lists (which does matter).

I've been able to compile with the new export declarations using the Borland
compiler, but to do so I needed to add "extern" to the various definitions
of XMLPUBVAR.

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

> -----Original Message-----
> From: "Igor Zlatkovic" <igor zlatkovic com>
> To: <xslt gnome org>, <exslt gnome org>, <xml gnome org>
> Date: Mon, 25 Aug 2003 12:24:06 +0200
> Subject: [xml] Header taint
>
> Hi there,
>
> As promised, here it is. The headers have been tainted to 
> contain export
> declarations on every function, every variable.
>
> New files called xmlexports.h, xsltexports.h and 
> exsltexports.h contain the
> macro definitions. Macros are:
>
>   xPUBFUN for declaring public functions
>   xPUBVAR for declaring public variables
>   xCALL for stating the function calling convenction
>
> where 'x' is XML, XSLT or EXSLT respectively. The default 
> export defs are:
>
>   #define XMLPUBFUN
>   #define XMLPUBVAR extern
>   #define XMLCALL
>
> for libxml, analogue for libxslt and libexslt. This matches 
> what has been
> used so far on Unix, where everything should compile just the 
> way it did
> before.
>
> What remains to be done is to align the parameters the way 
> they were before
> the taint. I'll do this. Libxml headers up to parser.h, 
> alphabetically, have
> been aligned allready. If someone wants to help, welcome :-), 
> but let me
> know what you are doing so we don't end up doing it twice.
>
> This does not interferre with the .def file in any way. 
> Makefiles are not
> using the .def file anymore, but even if they would, things 
> would go fine.
> MS linker seems to accept both at the same time and they do 
> not have to
> match. It will export a symbol if it is either declared as 
> exportable or
> mentioned in the .def file, or both.
>
> Please risk a glance at this and if there is a slightest problem, I'll
> appreciate an email, a phone call in the middle of the night, 
> whatever, but
> this must work for the next release. Not only for the next 
> release, it must
> work before that. Before any additional change is made to the 
> headers. This
> must be, so the change so big as this one can be easily reverted if it
> doesn't work.
>
> Ciao,
> Igor