Your skill will accomplish
what the force of many cannot
Packaging Perl Programs (is) Painfulby Sue D. Nymme (Monk)
|on Sep 03, 2010 at 21:00 UTC||Need Help??|
Sue D. Nymme has asked for the
wisdom of the Perl Monks concerning the following question:
I am writing GUI programs for users throughout our company. The users all have Windows workstations (mostly XP). I would like to package up these programs as individual, independent, Windows .exe files.
Now before a bunch of people jump all over me, let me make two points: 1) I am not trying to hide my source code from anyone—most of my users don’t know or care about Perl or programming, and although the programs are proprietary, I’m not real worried about theft by internal users. 2) I am under no illusions that this will make my programs in any way faster. All I ask is that it doesn’t slow them down significantly.
The reason I want to package each program is for simplicity of distribution to (and use by) the users. I’d like to copy the .exe file onto the network, or onto a USB drive, and just have the users use it from there, or copy it to their workstation. These people don’t have Perl installed on their workstations, and why should they?
I used to use ActiveState’s perlapp, from their Perl Dev Kit. But they want $150 for a license, and I have grown to dislike AS Perl over the past few years. Installing modules is a pain. I vastly prefer Strawberry Perl, and I mostly use that nowadays.
Then I tried Cava Packager. Nice slick interface, and everything builds smooth as ice cream. However, it does not package everything up into one nice bundle. It makes a nice, neat, small .EXE file (124k!), but requires that a 'lib' directory be installed in the same location. I took a look inside that 'lib' directory, and it was stunning. 860 encrypted library files, eight megabytes. Good God, what a mess. And if you try to install two Cava-packaged programs to the same location, their 'lib' files stomp on each other.
I have been playing with pp lately. It too is apparently a pile of crap. If you use the --gui option and your program dies for any reason, you get zero error indication, it just stops. It also does not know about "use lib" when scanning for dependencies. How insane is that? Here is a simple WxPerl program:
It’s short and simple, the boilerplate that most Wx apps follow. When I compile it:pp --gui -o test.exe test.pl
pp sits and churns for a while, then creates a 4 meg .exe file. When I run this program, it sits and does nothing for about fifteen seconds, then returns to the prompt. Nothing, nada. So I removed the --gui option, re-compiled, and re-ran:
Can’t locate threads/shared.pm?? What is this? It’s the first thing in MyApp.pm! So I ran PAR’s scandeps on my little test program:
Yep, it does not follow "use lib" directives. I couldn’t believe it, so I even delved into the source code of Module::ScanDeps to confirm. Incredible.
So now I add the libraries to the pp command line:pp -I H:\dev\lib -I H:\dev\MyAppDir\Wx -o test.exe test.pl
It then grinds away for half an hour, using 80% of my CPU the whole time. What the HELL is it doing? I haven’t seen compile times like that since I used a mainframe. When it finally did stop (yes, 35 minutes later), I ran the program (7.5 megabytes). It sat for twenty seconds, then popped up a dialog box that said,The program can't start because wxbase28u_gcc_custom.dll is missing from your computer. Try reinstalling the program to fix this problem.
Yeah, that's helpful.
Are there any sane packagers for Perl?