in reply to Re: Re: Re: In praise of h2xs: A tool you gotta have
in thread In praise of h2xs: A tool you gotta have
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)
$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:
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.)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;
RxMagicDirect contains only
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.require DynaLoader; { my ($pkg) = caller(0); push @{$pkg . "::ISA"}, "DynaLoader"; bootstrap $pkg; }
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.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: How to use Inline::C for production code
by rstarr (Initiate) on Aug 06, 2005 at 02:50 UTC |