Re: PC Problems with pp
by reneeb (Chaplain) on Feb 04, 2006 at 10:58 UTC
|
pp uses Module::ScanDeps to find all dependencies. This includes all dependencies of your scripts' dependencies.
But you have to be aware of modules that are loaded via code like eval (e.g. eval "require YourModule;"). In that case you have to use the -M option of pp (add a module manually to the archive).
the executable should run on "all" Windows PCs.
Your client/friend should run the executable from DOS-Box, so he gets an error message. That should be helpful.
If you use modules with XS, you may have to add the .dlls with pp's -l (add library) option.
That can be the reason why your exe runs on the PC with ActivePerl (ActivePerl has lots of modules with XS) and not on the other PC.
If you just pack your script, then there is no perl58.dll. It's just an archive with all dependencies (no executable). You have to make an executable... | [reply] |
|
| [reply] |
|
| [reply] |
Re: PC Problems with pp
by JamesNC (Chaplain) on Feb 04, 2006 at 14:17 UTC
|
What's my best option at this point...
You are on a contract to deliver. Why mess around spend the $145 on ActiveState's PerlDevKit (Deployment Tools), which you can download now and try free for 21 days if you are sheepish about buying before you try. It is fully documented and has been around a while. I ran into similar issues as you and their product and support helped me solve the issue. There are lots of nice deployment options and even an installer, and you can bind your own icons to the exe and so on... Your customer might even cover the cost. (I don't work for AS) | [reply] |
Re: PC Problems with pp
by liverpole (Monsignor) on Feb 04, 2006 at 15:17 UTC
|
I second JamesNC's advice -- get a developer's license from Active State, and use perlapp!
(That's the program which produces a standalone Perl application).I was the main Perl programmer at my last company, so they actually bought me a license, but if I had to get one again, I now know its benefits. Perlapp has the nice features of running on Linux and Windows both (and one or two other OS's I never used), and any modules which you're using when you build the executable are automatically included, so you don't have to worry about it running on a "non-Perl" machine. There's a lot more to the developer's package as well, but perlapp alone makes it worth the price.
@ARGV=split//,"/:L";
map{print substr crypt($_,ord pop),2,3}qw"PerlyouC READPIPE provides"
| [reply] |
|
| [reply] |
|
Oh, I'm sure it does. I haven't used it in awhile (my current company is a Linux shop, so I'm blissfully removed from Windows now), but my experiences with Active State all indicate that they are above doing that sort of thing.For example, when I got the license for the developer's kit, I was happy to see that it permits the user to run it on multiple computers, as long as it's just one at a time. This, in contrast with the software licenses of many other places, which forbid installing on other than a single computer.
@ARGV=split//,"/:L";
map{print substr crypt($_,ord pop),2,3}qw"PerlyouC READPIPE provides"
| [reply] |
|
If I remember rightly, the AS perlapp creates a fully functional .exe, but it has like a 5-second pause and shows a "You're using a trial version" banner before it exectutes. You can send it to your client and if it works, buy the full Dev Kit and get him the non-pause program.
Something I thought of: To test for dependencies, go find perl58.dll in your Windows directory and rename it. Then rename c:\perl to c:\Notperl or something. If you can't run your packaged script with all dependent paths cut off, then the problem is likely in what you're packaging. See above messages for where to look.
--marmot
| [reply] |
|
|
PAR and perlapp are equivalent in features and platforms they'll run on. If anything, PAR will run on some platforms perlapp doesn't.
| [reply] |
Re: PC Problems with pp
by Anonymous Monk on Feb 04, 2006 at 10:02 UTC
|
Am I right in thinking that just by my having use WWW::Mechanise in the script, it will pick up on dependencies?
-v, --verbose[=*NUMBER*]
Increase verbosity of output; *NUMBER* is an integer from 1 to 3, 3
being the most verbose. Defaults to 1 if specified without an
argument. Alternatively, -vv sets verbose level to 2, and -vvv sets
it to 3.
| [reply] |
|
I don't really know what I'm suppsed to get from your answer.
Adding verbosity tells me some interesting things. The pp script adds a ton of core modules by default. Are there dependencies of WWW::Mechanize, but non-core modules, which are being added? I can't tell, because I can't find a combination of flags which adds dependencies but leave out core modules. I must say it's a little confusing. What for instance is the difference between -x for execute and -r for run?
($_='kkvvttuu bbooppuuiiffss qqffssmm iibbddllffss')
=~y~b-v~a-z~s; print
| [reply] |
|
-r, --run
Run the resulting packaged script after packaging it.
-x, --execute
Run "perl inputfile" to determine additonal run-time dependencies.
| [reply] |
|
| [reply] |