"Martin Raspe" <[EMAIL PROTECTED]> writes:

> > I'll add a hints file for Windows - could you tell me what the output
> > of $^O (the operating system variable) is?
> 
> 
> It just says 'MSWin32'.

Good, I can add some windows conditionals for this in Makefile.PL

> >> For some reason, Xerces.C isn't compiled by the makefile. I had to
> >> compile it by hand.
> 
> > This one I don't understand.
> 
> Nor do I. I seem to recall that it used to work. Perhaps it's due to
> problems with the uppercase C in "Xerces.C" I had before. Anyway, make
> just silently skips making "Xerces.C" and tries to link "Xerces.obj"
> which it can't find.

Does renaming it to Xerces.cpp make any difference?

> 
> > There's probably a linker flag that tells it where the library is
> > located at runtime - if you find that out, I'll include it in the
> > windows help file.
> 
> I'd just say: put "Xerces-c_2_3_0.dll" somewhere in your system
> path.

Hmmm. OK. I really want to find a good way of checking whether the
library is in the system path. There *is* a method in MakeMaker.pm,
but it has way too many side effects, so I commented it out for 2.3.

> >> Exception handling seems particularly weak (tests fail mainly on
> >> exceptions). The message is always "Handling Unknown exception".
> 
> > Hmmm... Not sure about this one - that message comes from my exception
> > handler getting some exception that it can't deal with and killing
> > Xerces. It seems that almost all the methods are failing - I'd be
> > surprised if you could write an application that works.
> 
> Yes I can! As far as I see, at least XercesDOMParser and SAXParser
> work as they should. Parsing errors are reported correctly. Even
> schema validation works (to a certain extent - constraints are
> ignored, but maybe I haven't set the correct parameters).
> 
> 
> Now I see the message is *not* always "Handling Unknown exception".

Ok, that's better.

> It's the exception objects that don't behave. I seems they are mostly
> created and returned OK, but the {code} and {msg} hash values contain
> just garbage (it seems they somehow don't get initialized, but reflect
> some random memory location). That's why most of the tests fail.

Hmmm. Sounds bad.

> $e = XML::Xerces::DOMException->new(42,'test');
> print "$e : $e->{code} : $e->{msg}";
> 
> prints
> 
> "XML::Xerces::DOMException=HASH(0x1b90e2c) : 42 : "
> - is that OK?

I'll have to think about this one a bit more.
jas.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to