h2xs comes with perl by default, so most people who have perl are already going to have h2xs. So your title isn't quite right (I know, pick, pick, pick).

Yeah -- I should have said something like "A tool you've gotta try". I knew that h2xs was part of the Perl distribution.

Anyway, h2xs is useful for building general modules, but it has a lot of stuff that is useful only for XS modules that you'll have to remove for PP modules.

Right -- I figured that from the 'xs' at the end, even though it sounds like Ingy's Inline::C is the preferred method when linking C code into a Perl script/.

I just know that watching my colleague build all this stuff, everything was pre-cooked and ready to go. Thanks for the link to ExtUtils::ModuleMaker, I'll definitely check that out.

Right -- I figured that from the 'xs' at the end, even though it sounds like Ingy's Inline::C is the preferred method when linking C code into a Perl script/.

This is probably subject to another meditation of some sort, but the way I see it, Inline::C is great, I love it, but it's not suited for distributions into environments where there is not a compiler present -- or for Windows environments either. Thus I doubt it can be the preferred method for production code. Unfortunately, I have yet to learn XS, but I get the feeling around here that Inline::C is considered 'training wheels' -- please correct me if I've gotten that wrong. After all, XS modules have to be compiled as well, but perhaps it is easier to distribute them in native form? Are there sufficient performance tradeoffs (not bugs, per se, but performance tradeoffs) when using Inline::C rather than XS after initial compile/build time?

I use Inline::C for some production code, and had to work around the issues you described. My solution was to create some infrastructure for precompiling the XS generated by Inline::C when requested. So when developing, I run using Inline::C, and get automatic recompiles when I change the C code. To release, I run make precompiled, which is a target I defined to force compilation of all of the Inline::C code and copy it over to the installation location. At runtime, the module chooses based on an environment variable whether to use Inline::C or the prebuilt stuff (on a production machine, you don't need to install the Inline module at all.)

In more detail:

Each of my Inline-using scripts looks like:

package Whatever;
BEGIN {
  do ($ENV{DEVEL_MODE} ? 'MyMagicInline' : 'MyMagicDirect') or die $@
}
...perl code...
__DATA__
__CPP__
...C++ code... (ok I lied; I'm using Inline::CPP, not Inline::C)
[download]

$ENV{DEVEL_MODE} is set automagically by something else, but don't worry about that. Just always have it set while you're developing.

MyMagicInline contains something like:

use Inline with => 'MyScriptInline';
BEGIN {
  $inline_code_file = abs_path($INC{__PACKAGE__ . ".pm"});
}

sub find_code {
  local $_ = shift;
  s/^.*?__CPP__\n//s;
  return $_;
}
use Inline(CPP => $inline_code_file, FILTERS => \&find_code);
Inline->init;
[download]

The MyScriptInline file contains a single subroutine named Inline that returns a hash ref of Inline settings (eg { INC => '-I/my/path' }). (This is how Inline implements its with magic.)

RxMagicDirect contains only

require DynaLoader;
{
        my ($pkg) = caller(0);
        push @{$pkg . "::ISA"}, "DynaLoader";
        bootstrap $pkg;
}
[download]

Ok, so that's just a sketch of what's going on; there are details about where the files are found and the precompilation target that runs everything under Inline and then copies the generated *.so files to the appropriate lib/ directory, but the end result is that I can install onto a production machine and not have to install Inline there.

I'm sure this isn't the cleanest way to do this. I never really bothered to go back and clean it up after I got it to work, but it seems to work quite well for what I need.