package YourPackage; use XSLoader; XSLoader::load 'YourPackage', $YourPackage::VERSION;
For a more complicated interface, see DynaLoader. Many (most) features of "DynaLoader" are not implemented in "XSLoader", like for example the "dl_load_flags", not honored by "XSLoader".
package YourPackage; require DynaLoader; our @ISA = qw( OnePackage OtherPackage DynaLoader ); our $VERSION = '0.01'; bootstrap YourPackage $VERSION;
Change this to
package YourPackage; use XSLoader; our @ISA = qw( OnePackage OtherPackage ); our $VERSION = '0.01'; XSLoader::load 'YourPackage', $VERSION;
In other words: replace "require DynaLoader" by "use XSLoader", remove "DynaLoader" from @ISA, change "bootstrap" by "XSLoader::load". Do not forget to quote the name of your package on the "XSLoader::load" line, and add comma (",") before the arguments ($VERSION above).
Of course, if @ISA contained only "DynaLoader", there is no need to have the @ISA assignment at all; moreover, if instead of "our" one uses the more backward-compatible
use vars qw($VERSION @ISA);
one can remove this reference to @ISA together with the @ISA assignment.
If no $VERSION was specified on the "bootstrap" line, the last line becomes
XSLoader::load 'YourPackage';
package YourPackage; use vars qw($VERSION @ISA); @ISA = qw( OnePackage OtherPackage ); $VERSION = '0.01'; eval { require XSLoader; XSLoader::load('YourPackage', $VERSION); 1; } or do { require DynaLoader; push @ISA, 'DynaLoader'; bootstrap YourPackage $VERSION; };
The parentheses about "XSLoader::load()" arguments are needed since we replaced "use XSLoader" by "require", so the compiler does not know that a function "XSLoader::load()" is present.
This boilerplate uses the low-overhead "XSLoader" if present; if used with an antic Perl which has no "XSLoader", it falls back to using "DynaLoader".
A sufficiently complicated module using XS would have both Perl code (defined in YourPackage.pm) and XS code (defined in YourPackage.xs). If this Perl code makes calls into this XS code, and/or this XS code makes calls to the Perl code, one should be careful with the order of initialization.
The call to "XSLoader::load()" (or "bootstrap()") has three side effects:
Consequently, if the code in the .pm file makes calls to these XSUBs, it is convenient to have XSUBs installed before the Perl code is defined; for example, this makes prototypes for XSUBs visible to this Perl code. Alternatively, if the "BOOT:" section makes calls to Perl functions (or uses Perl variables) defined in the .pm file, they must be defined prior to the call to "XSLoader::load()" (or "bootstrap()").
The first situation being much more frequent, it makes sense to rewrite the boilerplate as
package YourPackage; use XSLoader; use vars qw($VERSION @ISA); BEGIN { @ISA = qw( OnePackage OtherPackage ); $VERSION = '0.01'; # Put Perl code used in the BOOT: section here XSLoader::load 'YourPackage', $VERSION; } # Put Perl code making calls into XSUBs here
package YourPackage; use XSLoader; use vars qw($VERSION @ISA); BEGIN { @ISA = qw( OnePackage OtherPackage ); $VERSION = '0.01'; XSLoader::load 'YourPackage', $VERSION; } # Put Perl code used in onBOOT() function here; calls to XSUBs are # prototype-checked. onBOOT; # Put Perl initialization code assuming that XS is initialized here
In particular, this is applicable to the structure of @INC used for testing not-yet-installed extensions. This means that running uninstalled extensions may have much more overhead than running the same extensions after "make install".
CPAN version is currently maintained by Sebastien Aperghis-Tramoni <sebastien@aperghis.net>.
Previous maintainer was Michael G Schwern <schwern@pobox.com>.