All the Perl that's Practical to Extract and Report

libiconv

ziggy on 2002-02-12T02:47:29

So, I started looking into Matt's AxPoint today, but unfortunately I started working on a WinNT4 box. Turns out that CPAN tried valiantly to install AxPoint, and even got the PDFLib dependency (after I remembered to install it under cygwin).

However, there was one major hiccup. libiconv. Turns out that libiconv hasn't been ported to cygwin yet (there's a link failure looking for WinMain@16...is this a 16bit app?). The libiconv sources for version 1.7 do build on Windows, but only with VC++.

I really don't need this headache. Time to start working on a linux box or something that has libiconv header files so Text::Iconv can build (a dependency for XML::SAX::Writer).

Of course, when I get home, it installs like a charm, because I have the iconv.h header files squirreled away somewhere. :-)

(Note to self...must try force installing XML::SAX::Writer first, and ignore the build error for Text::Iconv...)

Shouldn't be required

Matts on 2002-02-12T07:41:18

You shouldn't need Iconv - if it's not installed XSW will just not support encoding switching. At least I hope that's what it should do. We need to make that Makefile a bit smarter so it tests for Encode.pm (5.7.2 thing) too and uses that instead.

Re:Shouldn't be required

darobin on 2002-02-12T12:46:04

Short answer is: you can force install, comment out the use Text::Iconv, and from there on only ever use same encodings in and out. It'll work (that is, recent versions will :).

Long answer is that that may only be a temporary hack as in the close future it will be automatically generating XML Decls for you and other such treachery, so that it might need to do some conversions behind the scenes. So do get Text::Iconv ;-) Isn't there a PPM for that?

Also, we will make it smarter (ie have an external encoding set of classes that it'll intelligently chose from at run time -- something which it already does in part) but that's lower on my current priority list than UTF-16 bugs, Barrie's patches, and the split out of the actual XML writing bits (so that it can be a generic SAX writer).

Re:Shouldn't be required

Matts on 2002-02-12T14:01:50

Umm, it already is a generic SAX writer. Both AxPoint and XML::Handler::HTMLWriter subclass it.

Re:Shouldn't be required

darobin on 2002-02-12T14:13:52

Yes, it already is possible to use it as such. But all the conveniance subs that can help there haven't been doc'd or clearly specified (which pretty much keeps people away from looking that way) and you can't yet use some facilities such as XML::SAX::Writer->new(WriterClass => 'MyFooWriter'); and all that.