Nah, I tried SWIG back when I wrote the Python wrapper. It really didn't
address ... well, I guess my point is, using SWIG wasn't perceptibly any
easier than just writing Python wrapper code and ending up with a
wrapper that took advantage of Python strengths. Inline seems (and
seemed, back when I wrote my article about it for developerWorks) the
best way to do that same thing with Perl. I've taken umpteen runs
through the XS docs and still hate the whole idea. Inline is much more
elegant and I end up with something that's (1) easily documented and
fixed and (2) very nicely integrated with Perl. If I just knew how to
distribute it to people who might not be in the position to use Inline
directly, for instance, people with precompiled Perls without access to
the compiler used to compile their Perl, which isn't unusual on Windows
or on Solaris. I know that Brian *intended* to address some of this
messiness, but I don't know what the actual state of the art is. Or
didn't. I think Rob's cookbook pointers will help. (I'm working on this
on way-back-burner speed...)
Michael
Jason E. Stewart wrote:
Michael Roberts <[EMAIL PROTECTED]> writes:
I haven't been following things very closely for a while, but the
reason I got involved with Inline in the first place is that I didn't
want to mess with XS when providing a Perl binding for my open-source
workflow toolkit wftk. It's a standard ASCII-C package, under Windows
it's a DLL. What are my options at this point for providing an easily
installable package based on Inline under Windows and under Unix?
Back in the early Inline days I managed to get Perl compiled using
mingw32 and thus included Inline that way for experimental purposes,
but a package based on that probably wouldn't work with ActiveState
Perl under Windows. Not that I've tried, actually.
You can also look into using SWIG (swig.org). It is a heavier-weight
solution, but it works well under windows, and it can be used for many
more languages than just Perl - python, guile, ruby, java, ...
Cheers,
jas.
