Chapter 10

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!

238