Writing Perl Modules for CPAN

Here's a simple example script that uses Inline::C to print out "Just Another Perl Hacker":

#!/usr/bin/perl -w use Inline C => <<END_OF_C; void japh() { PerlIO_stdoutf("Just Another Perl Hacker.\n"); } END_OF_C japh();

This script uses the Perl C API function PerlIO_stdoutf() to print a string. When you run this script, it works as expected, after a sizable pause for compilation:

$ ./inline.pl Just Another Perl Hacker.

The second time you run it there's no pause. So, what's happening here? Inline::C follows these steps:

1. Inline::C receives the C source code passed as an argument to use Inline C. This happens at compile time.

2. Next, Inline::C checks to see if it already has a compiled version of this code available. If so, it loads the compiled code with DynaLoader and returns. More on how this works in Step 5.

3. A directory is created in which to build the code if one doesn't already exist. Since I didn't provide any configuration options to control this selection, Inline::C will create a directory called _Inline in the current directory.

4. The C code is then parsed with Parse::RecDescent, which looks for a C function to wrap with XS.

5. Inline::C creates all the files and directories necessary to build an XS module containing the C code. This includes Makefile.PL, a .pm file, and an .xs file. The name for the directory used to build the code is derived from an MD5 signature of the code to be compiled. This is how Inline::C is able to know in Step 2 if the code needs to be recompiled or not.

6. The code is built using the normal perl Makefile.PL && make procedure employed by XS modules.

7. The compiled code is loaded with the DynaLoader module.

All of this is transparent to the Inline::C programmer, unlike with XS. Better yet, it works in scripts just as well as it works in modules. This makes testing new C functions easy: Just create a script that uses the function and run it-no compile step required!