Right, so I'm supposed to be learning something about XML, and I'm reading a book about it. That book has a couple of examples in Java at the point where I'm at right now (explaining SAX), and I wanted to try to get them to work with Perl.
I had installed a bunch of XML modules already yesterday with PPM, including XML::SAX and XML::SAX::Expat, so I tried to get this working.
D:\Temp>perl BookCounter1.plx could not find ParserDetails.ini in C:/Perl/site/lib/XML/SAX Unknown Parser handler type: DoctypeFin Valid types: Attlist CdataEnd CdataStart Char Comment Default Doctype Element E nd Entity ExternEnt Final Init Notation Proc Start Unparsed XMLDecl at C:/Perl/s ite/lib/XML/SAX/Expat.pm line 100
This was because I had requested XML::SAX::Expat to be used. When I commented that out, so that XML::SAX picked its own parser, I got:
D:\Temp>perl BookCounter1.plx could not find ParserDetails.ini in C:/Perl/site/lib/XML/SAX There are 3 books.
Which was better. But I wanted to use the C-based expat parser if possible, and the ParserDetails.ini bit was nagging me as well.
I had a look at the offending bit of source in XML::SAX::Expat and wondered whether my version of XML-Parser was wrong. So I tried installing a new version of that.
I had tried that yesterday with verify -upgrade -force XML-Parser but it had refused to download and install anything, so I tried install XML-Parser today.
This indeed installed the module, but when I wanted to ask it its version number, I got:
D:\Temp>perl -MXML::Parser -e "print $XML::Parser::VERSION" Can't load 'C:/Perl/site/lib/auto/XML/Parser/Expat/Expat.dll' for module XML::Pa rser::Expat: load_file:Das angegebene Modul wurde nicht gefunden at C:/Perl/lib/ DynaLoader.pm line 200. at C:/Perl/site/lib/XML/Parser.pm line 15 Compilation failed in require at C:/Perl/site/lib/XML/Parser.pm line 15. BEGIN failed--compilation aborted at C:/Perl/site/lib/XML/Parser.pm line 19. Compilation failed in require. BEGIN failed--compilation aborted.
as well as a pop-up dialog box telling me Windows couldn't find LIBEXPAT.dll. I tried copying Expat.dll to LIBEXPAT.dll but then it complained about not finding ordinal 46, or something.
So I guessed that maybe Expat wasn't properly installed. I found this strange, because I expected PPM to install a package containing all dependencies; after all, this is for pointy-clicky Windows users who need to be spoon-fed. (Incidentally, at this point PPM stopped working as well, but I had expected that since, I believe, it uses XML for its internal configuration files and if XML::Parser is unhappy it probably won't get very far.)
My next stop was Jim Clark's web site. That told me that newest versions were to be found from SourceForge, so I headed over there.
There, I found a "Windows binary distribution" (or something like that) link, which sounded promising. It was an EXE file which installed to C:\Expat-1.95.6, and after it did so, I found a LIBEXPAT.dll in C:\Expat-1.95.6\Libs. Maybe that's it?
I modifed PATH to include that directory and tried again. This time it worked. However, I still got the message "could not find ParserDetails.ini".
I googled for that filename and found an email message from someone saying he had created an empty file and that made the message go away, so I tried that for a first approximation.
Another hit was in the search.cpan.org documentation for XML::SAX, giving SAX driver authors some code to insert into Makefile.PL; this looked as if it'd register that driver with XML::SAX. I tried executing that by hand, and lo and behold, ParserDetails.ini was then filled.
Again, I would have expected ppm install XML-SAX-Expat to have updated that file automatically. (On the other hand, PPM can probably only overwrite files, not append to them; manual installation would have probably done the Right Thing.)
(This probably also explains how XML::SAX::ParserFactory will use "the parser you installed last"; I was wondering how it could determine that. I suppose now that it goes by the order of entries in ParserDetails.ini.)
Anyway, after I did that, my little toy script worked. Using Devel::TraceSAX showed that even after I commented out the line specifically requesting XML::SAX::Expat, it chose that driver (rather than XML::SAX::PurePerl), which is also good.