jettero has asked for the wisdom of the Perl Monks concerning the following question:

I find I'm a bit jealous of Ruby's FFI. I've never written a line of Ruby, but many of my friends do, and they explained the awesomeness of this interface to me.

We have Win32::API under windows. It seems like there should be something totally platform agnostic like Ruby's FFI though. If it was done really well, it would eliminate a lot of the un-funny bugs that come from XS modules and it would make it an awful lot easier to link to system libraries without even needing a compiler installed.

Corion also suggested the apparently wrongheaded P5NCI. I don't know what's wrong with it, but I'm wondering if we need something like FFI, why NCI is wrong, and what other options are there that I simply don't know about yet.

-Paul

  • Comment on platform agnostic foreign function interface, necessary?, missing?

Replies are listed 'Best First'.
Re: platform agnostic foreign function interface, necessary?, missing?
by Joost (Canon) on Feb 19, 2009 at 13:32 UTC
    P5NCI seems to be pretty much equivalent to ruby's FFI, though I haven't used either.

    There are some issues with this kind of approach though, especially in a multi-platform environment. Mainly, it doesn't rely on a C compiler or any of the header files which is great if need to install it on a system for which you don't have a C compiler or header files but it also means you'll end up replicating the header files in the FFI code. And structures and function arguments tend to differ over different operating systems.

    A simple example of this problem that I've ran into when using the CFFI system: the values of the RTLD_* constants (used as the MODE argument to dlopen) are different for at least Linux & BSD, but if you don't know that, the code will probably run but not do what you want on one of the systems. The suggested way to work around that is to parse the header files yourself - that is obviously not a very good way to go about things.

    On the other hand, XS is really pretty good, as portable as C is (which is exactly the right amount of portable) and the only requirement is that you've got a decent C compiler + header files available. With strawberry perl, that should mean it's free for every major OS that perl runs on. Yes it's a bit more complicated, but not really that much. Get the book if you want to good introduction.

      For the record, I like XS and write in it fairly frequently. I'm mainly interested in reducing the number of esoteric things you have to learn to write extensions and I like the idea of not needing a compiler at all to write a new one. If some really good standard FFI was available on most perls, the CPAN install would be basically just copying the .pm to the right place and you're done. This would simplify the install of Gtk2 by quite a bit. It's notoriously difficult to compile on win32 because of the very short command line length restriction.

      I think the Ruby FFI optionally parses header files automatically, so it may get around some of the problems you're talking about here. On the other hand, it may make them worse, since you'd need to have the development versions of package libraries installed just to run things. Gross.

      -Paul

Re: platform agnostic foreign function interface, necessary?, missing?
by moritz (Cardinal) on Feb 19, 2009 at 15:11 UTC
    The good news is that Parrot has a nice NCI, and as a Google Summer of Code Project a NCI compiler was written, ie a program that parses a C include file, and writes an NCI signature for the functions.

    The bad news is that it's not (yet?) straight forward to use from Rakudo (the Perl 6 compiler on parrot). Maybe that could be the topic of another gsoc project...

Re: platform agnostic foreign function interface, necessary?, missing?
by dada (Chaplain) on Feb 19, 2009 at 16:18 UTC
    well, FFI is on CPAN. I did not test it extensively, but it builds fine on linux and cygwin. it requires an external library, but looks a much saner approach than P5NCI.

    cheers,
    Aldo

    King of Laziness, Wizard of Impatience, Lord of Hubris