On Jun 5, 2006, at 11:41 AM, Peter Karman wrote:
> Which reminds me: while learning Inline::C for the Perl interface,
> I ran across some of your posts, Marvin, on the Inline list. It
> seems like you've opted to write your own Perl/C stuff with a
> special build script instead of using Inline::C.
>
> Care to explain why you went that direction? Just curious as to
> what pitfalls you might have encountered, so that I can avoid them
> myself. :)
There are two reasons.
First, I didn't want to introduce Inline::C as a dependency. Not
everyone can use it. I wanted dependencies held down to a bare
minimum. Etc.
Second, Inline::C doesn't work very well when you want to do
complicated things. What Inline::C does is write XS for you. If you
need to do something that's not Inline::C's forte, you need to learn
XS anyway. It got me started learning perlapi, but I soon wanted
greater control than it was able to provide. Inline::C is like
training wheels for your XS bicycle.
KinoSearch's current build system took a little while to set up, but
for the most part it's not very tricky. Most of it is just basic
Perl text wrangling, the main point of which is to keep the XS and C
code in the same file as the relevant Perl code. It I just populated
the src directory with the .c and .h files, and concatenated all the
XS code in all the perl modules into one giant KinoSearch.xs file, a
lot of the code in Build.PL could go away.
The mildly tricky stuff is the auto-generation of the typemap, and
the way it keeps track of which files have been modified (which
spares me from recompiling everything every time).
One thing I recommend in general is limiting XS to glue code, while
doing most of your work in pure C. XS is kind of clunky, and it's
easier to see what's going on if you separate all the stuff needed
for moving across the Perl/C boundary from the code that does "real"
work.
Cheers,
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/