Jan Wieck <janwieck@Yahoo.com> writes:
> [ why hasn't plperl been fixed yet? ]
IMHO, the portability problems with plperl will need a Perl guru to fix.
Specifically somebody who knows the ins and outs of embedding Perl into
other applications, which is not such a commonly done thing. pltcl was
a simpler project because Tcl has always been designed to be embedded as
a library into other applications. Perl is still in process of being
redesigned from a standalone program into an embeddable library, and
most everyday Perl programmers don't know much about the pitfalls that
still remain in using it that way.
Just to give you one example of the ways in which Perl is not designed
to be embeddable: last I checked, libperl was not built as PIC code by
default. On machines where that makes a difference (like HPUX) that
means that plperl cannot work with a default Perl installation. Period.
Not one damn thing you can do about it except reconfigure/rebuild/
reinstall Perl, which is a tad outside the charter of our build process.
The cross-version compatibility issues could be fixed more easily, but
probably not with just an hour or two's work (has anyone here actually
done anything with Devel::PPPort? how hard is it?). When working around
them just takes "add POLLUTE=1 to Makefile build", I can see why people
aren't eager to invest the work for a cleaner solution.
Perl is getting better over time (indeed 5.6.0 may do the right thing
already on the PIC front; I haven't installed it yet) but I think in
the near term it's going to be difficult to have a really robust
portability solution for plperl.
regards, tom lane