Strange as it may seem, there are no tools to automate the task of embedding Perl as there are for extending Perl. Why is that? After all, extensions also have to account for translating data from Perl to C and back (input and output parameters). The reason is that when Perl drives C code, it specifies precisely how and when a C extension is loaded. As an extension writer, you have the job of simply writing XSUBs in a callback style, providing some initializations; the XSUBs will be called when the script invokes the appropriate corresponding functions. In contrast, since there is no standard way to write a C application, you have to decide when to initialize an embedded Perl interpreter and how to give control over to a Perl script.
To simplify embedding, this chapter shows you an easy-to-use veneer over Perl’s internal API. These routines have been developed for this book to save you the bother of assimilating over 50 pages of internal documentation. But if you are the type who thrives on such details, Chapter 20, should provide the needed fix. It also explains the code for these convenience routines.
It so happens that the Perl executable is made up of two parts: a
library of core Perl routines (libperl.a on UNIX systems and
perl.lib on Microsoft Windows systems, or
dynamically loadable equivalents of the same) and a simple driver
main(), which, shorn of all its portability
aspects, looks like this:
#include <EXTERN.h> #include ...