"be consistent" | |
PerlMonks |
How to use Inline::C for production codeby sfink (Deacon) |
on Mar 30, 2004 at 07:41 UTC ( [id://340881]=note: print w/replies, xml ) | Need Help?? |
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:
$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.) 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. 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.
In Section
Meditations
|
|