Daniel E. Lautenschleger [17/01/02 11:55 -0600]: > I want one .exe file that contains all the goods to run by itself without > requiring Perl to be on the machine. That is what PerlApp claims to do.
Yup. Sorry. I started out writing the email, then just ended... Check this out: http:[EMAIL PROTECTED]/msg00444.html Relevant bit: ----8<---- Well luckily I work at ActiveState. I just talked to the PerlApp folks. We figured out how to add support. I'll try to add a fix before YAPC. This might be release 0.41 or maybe just a patch. ---->8---- Looking at the Perforce logs, no such patch materialized. I could be wrong, of course, and Ingy would be the one to correct me. All that aside, if you look at the flow of control inside Inline, it seems you need to: 1. follow prior instructions to build a "distributable" Inline-based module. You know, set it up with the VERSION => ... and NAME => ... options, so Inline won't try to build on-the-fly. 2. Bundle the .so and .inl file. You may not even need the .inl file; I don't know if it's used in an "installed" environment. That should be it! The reason NAME => ... helps is because the .so will be named the same as your module, which means PerlApp will pick it up nicely (given enough coaxing). I don't remember if PerlApp will automatically look in the blib/ tree, or if you'll have to "install" the .so into your Perl tree. But it sounds like what you want is this: (this doesn't work, I just made it up -- but it's what you want) $ perlapp --include=_Inline/lib/arch/auto/script_pl_103a/script_pl_103a.so \ --include=_Inline/lib/arch/auto/script_pl_103a/script_pl_103a.inl \ script.pl Again, I'll get back to you with how you add arbitrary files into PerlApp'd binaries. Later, Neil
