I come to this list because the usabilty of the binary distribution of the .pm files made with inline consistently eludes, me no matter how hard i try. It always insists on recompiling, no Force option enabled (obvious).
It would be preferable for me to simply be able to run the binary form out in the PerlApp packaged exe I have, but it insists on having the local machine having a perl install, as well as the c compiler.....obviously restrictions no one wants to deal with....
I've had the exact same problem with some Inline::CPP code. One solution is to treat the Inline code as it's own module, install the module on your system and have your application use it as any other module. Then PerlApp will pick it up the normal way when packaging the source.
<http://search.cpan.org/~ingy/Inline-0.44/Inline.pod#Writing_Modules_with_Inline> <http://search.cpan.org/~ingy/Inline-0.44/Inline-FAQ.pod#Whatever_happened_to_the_SITE_INSTALL_option?>
This is my Makefile.PL: ----- use Inline::MakeMaker;
WriteMakefile( NAME => 'Game::Decoder::PerlDecode',
VERSION_FROM => 'lib/Game/Decoder/PerlDecode.pm',
);
-----This is the Inline-definition:
-----
use Inline
'CPP' => $code,
NAME => "Game::Decoder::PerlDecode",
VERSION => '0.01',
;
-----This was a while back, and I remember something about commenting out the NAME line (I think) when developing the module, and having it active when building the module. Or something like that... If this sounds familiar, would anyone care to elaborate on that and how the NAME parameter is supposed to work? Or describe the procedure to follow when developing an Inlined module?
/J
-------- ------ ---- --- -- -- -- - - - - - Johan Lindstr�m Sourcerer @ Boss Casinos johanl AT DarSerMan.com
Latest bookmark: "TCP Connection Passing" http://tcpcp.sourceforge.net/ dmoz: /Computers/Programming/Languages/JavaScript/ 12
