How Well Does Perl2exe Work for Large Applications?

bobm writes "One of the issues with not using the 'standard' MS tools (VC, VB, etc) is that you face the possiblity of having to load a lot of DLL's to support an application. I'm in this boat with a Perl app I would like to migrate to a couple of Windows 2000 servers. It's a simple app that runs well on our Unix boxes and if it wasn't for the overhead of having to install perl and all of the required modules, it would be a no brainer. However I just stumbled upon Perl2Exe at Indigostar. A small app worked great and I'm wondering if anyone else has used it and how large of an app have they released? Any other pointers and info on pertinent issues would be helpful too."

Comments

Works okay, some usage problems.

[Raskolnk]

I've used it to build a moderately sized installation application that was distributed to clients to install our huge application. I had mixed results.

Main problem was licensing. Because it was an installation app, the Build/CM team was responsible to maintain it. IIRC, the license was tied to a given username and host. So, developers can't build the installer themselves, the CM team must do it on request, or setup a shared perl2exe user for everyone on a build server somewhere. Developers, if they want to fix it, must go and work on the shared server. Pain in the ass.

The other issue was lack of Perl know-how. When the compiler complained, I'd have ten people at my desk while I tried to explain how to setup @INC corrrectly.

Seems like a _very_ small shop produces it, and is a little kludgey. Overall though, if my team was just me or a few Perl savvy people, I would recommend it.

As an aside, my reasons behind using perl2exe were:

1) perlcc didn't seem to work at all, and I didn't have the time to muck with it. Has anyone gotten this to work for more than just small or test programs?

2) (and most obnoxious, at least with 5.003(?)) Perl is a pain in the ass to deploy. Licensing issues didn't allow us to distribute ActiveState on NT, and Perl really wants to be compiled on the target machine for Solaris. Compiling a distribution on Solaris hard-codes the prefix-dir, so it expects the target machine to have the same dir structure--which is in violation of my requirements. I emailed the mailing list and got a reply from non other than Randall Schwarz, who basically said (heavily paraphrased), "Yeah, that sucks. Someone's going to fix it eventually." The only solution I could come up with in a short amount of time was to write a wrapper script that mucked with @INC and included paths from the environment before execing anything else.

I love the language, but this is why I don't use it. You can't depend on everyone having installed Perl + all your needed PMs themselves, and its not worth trying to automate it for them. IMHO, its the downfall of the language.

We wanted to have Perl installed with our large Java system to help in performing scripting type tasks, but it was way too big of a pain. Oh well...

I *adore* Perl2exe

[clintp]

First off I don't:

• use Perl2exe to obfuscate and hide my source code. Generally, I'll give it out to whoever asks for it.
• use Perl2exe to speed up my code. That doesn't work. And if I wanted fast, I'd write in C.

I know Perl isn't *terribly* difficult to install. But it's a helluva lot simpler to drop an exe file and maybe a DLL or two onto someone's system than the (ever growing) Perl distribution and the required modules. Heaven forbid I need to update Perl too. The software I distribute matches the version of Perl I've distributed with it. Always, and without hassle.

The disk-space argument against perl2exe isn't holding much water lately either. I can distribute a perl2exe'd Perl program for about 2-3MB. My Perl installation (Activestate, including Tk) is about 40MB. So my tradeoff point on disk space is about 12 programs before I start "wasting" disk space. With 5.8 and 5.10 I'm sure that break-even point will be even higher.

In the long run it makes support and distribution so much easier to people who have *zero* interest in using Perl, just my applications.

I've distributed large (several thousand line) scripts using a lot of modules with lots of prerequisites (think Tk!) without problems. The *only* problem I run into are modules that aren't use'd until runtime need to be included manually before "compilation" into the exe (Tk is especially bad about this). That just means I need to test everything before I distribute it to make sure I've picked up all of the component modules.

Re:Perl still has a few probs on Win2000

[gruntvald]

Uh, did you try the Win32 modules, and specifically Win32::AdminMisc from roth.net ?

My opinion: Do it.

[IggyBung]

In an attempt to keep our software build process as uniform as possible, we keep most of our build tools under version control, including a perl script to do a basic product release. Obviously, putting ALL of perl under out VCS just so people could run the build script was abhorent. The answer was to use perl2exe (actually perlapp from the Active State PDK, but the behaviour is similar).

The script is not small, it performs alot of grunt work (version labeling, coping to archives etc) and I have NEVER had any problem with it. The executables it produces are perhaps a little big as they include everything necessary to run the script, and of course, startup time sufferers, but in terms of convenience, it can't be beat!

My two cents anyway.

Ian

Perl2exe problems

[Xunker]

I've used P2E a few times and I'm actually pretty happy with it save a few issues:

1. Don't run the executables off a CD-ROM drive. They will run slow as dirt unless they are loaded from some sort fo fast media, faster than CD.

2. You may have to declare ("use" or "require") stuff you wouldn't have to normally. A good example is "Storable" that is used by some modules -- you may have to explicitly declare that in your code to get it to "compile" right. The program will actually tell you what you need, though (usually).

Re:this is a problem with cd distribution/automati

[reverius]

That's not a binary, it's source code

Here is a list of many win32 binary distributions of Perl, some of them with installers. I'm sure you can find one to suit your needs.

Tied PerlApp...

[Schwuk]

I've not used perl2exe, but have used PerlApp in the Perl Dev Kit by ActiveState. It has worked very well for my needs: the client I currently work for installs perl on every machine, but it is the original pre-activestate version bundled in the NT Resource Kit. I need to use a more modern version for something, but they wouldn't agree to upgrade. Hence PerlApp.

Ideally, I would upgrade all the machines, and have a shared site library for additional modules, but if until then, or for sites where you can't rely on perl being everywhere, PerlApp and perl2exe do a good job...