|
Cody Pendant has asked for the wisdom of the Perl Monks concerning the following question:
I'd really appreciate some help with making my perl script into a Windows executable.
Background: I've contracted to create a screen-scraper for a client. The client is remote and not remotely knowledgeable about perl, although he has installed ActiveState on his PC successfully. I'm not creating an executable for any reason other than to make it easier for him. If he lived around the corner I'd go there and install all the necessary modules and give him a script.
The script is a scraper, and uses WWW::Mechanize and HTML::TableExtract.
My script is ready and works on my Mac and a Win2K PC. On that Win2K PC I've created an executable version with Audrey Tang's pp utility.
I've had some success with this approach before and no complaints. But the only module my success story uses is LWP::UserAgent.
Problem: He's downloaded the executable and tried it on two PCs.
- One PC with unknown OS and no Perl, it doesn't run at all, or rather he gets a command-prompt window with no output and nothing happens.
- Windows 98 PC with ActiveState Perl installed, it runs but it quits with no error message as soon as it tries to open and write to a file. The file is created but has no content.
Questions: - Should executables created with pp work on any version of Windows?
- Am I right in thinking that just by my having use WWW::Mechanise in the script, it will pick up on dependencies? Because I've tried it with different options including the ones which say they run or check the script to find all dependent modules, and the files they produce seem identical.
- The default settings of pp include a perl interpreter, right? So why did the script work on the computer where he has Perl and not on the vanilla one?
- Any idea why it would die, but without a proper die() message when trying to print to a filehandle? Anything special about Windows here? Although my other project does exactly that with no problems.
- Is it possible that the inclusion of more complex modules which rely on HTML Parsers and the like has caused problems which weren't evident in the other project?
- Where is the interpreter in the file? I'm searching through it (it's really just a ZIP file with lots of Perl magic, right?) and I can't see it.
- What's my best option at this point for turning my perfectly good script into a Window EXE?
($_='kkvvttuu bbooppuuiiffss qqffssmm iibbddllffss')
=~y~b-v~a-z~s; print
|
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] |
|
|
