That's not a compiler, except in the sense of "compile" meaning "to bring together". It's merely an installer-maker.

It does nothing to speed up the run time. It can certainly be fooled about which of your library versions need to be included. It duplicately installs modules. The source code is trivially contained within the exe file, for anyone to pluck out. And the interpreter is useless except for that program, and cannot be reused for other Perl programs.

Much better to tell people to spend two minutes installing Perl from activestate, the three PPM commands they'll need, and then they have not only your program up and running, but have an entire environment to use others as well.

perl2exe is a scam. Please stop promoting it.

-- Randal L. Schwartz, Perl hacker

merlyn, it does have one use. It makes programs easy to install. VB kicks Perl in this regard.

Yesterday we walked into a clients office and installed a VB front end to a database on his machine. It was so easy - CDROM in drive, double click on icon, click go. After a couple of tries, even the client could get it right. Now we can just send him the updates, and he can install them himself. He can even install the program on other machines.

I'm really beginning to envy windows programmers for that little trick. No screwing around downloading this, running that, resolving this error - it's just "disc in drive, double click". Perl could really benefit from something like that. Then we (the whole community) could distribute our programs as exe files that just get up and do their stuff without forcing the users to spend time and mental effort figuring out how to install it.

Something like that is valuable in an enterprise environment. I know all your other comments are correct, but something like Perl2exe helps when dealing with people who have to pause to wipe the drool off the mousepad.

____________________
Jeremy
I didn't believe in evil until I dated it.

I've used perl2exe on win32 with much success. I bought the LITE version and its seems quite solid.

PROS:
No need for perl or any modules to be installed on the destination machines. Just the host(Dev machine).

NEUTRAL:
EXE sizes are over 500K minimum. Not an issue for me.

CONS:
The registration process and KEYING to a windows username was a pain in the ***.

Hope that helps.


WrongWay

A question about the Perl2Exe.
Did you use Perl2Exe with ActiveState or with IndigoPerl?

Thanks in advance
Claude

I spent some time playing with Perl2Exe on a relatively big program and failed to have any success... "Out of the Box", it ignores your site_perl lib directories, so you have to either explicitly use libs or set an environment variable to get it to find them.

While the sample scripts included with the package did run, I never managed to get my script going. A Super Search here for perl2exe convinced me that I was wasting my time trying to get it to work.

Instead, I'm insisting that everyone install ActiveState Perl on their machines. Afterwards, I'm using a free <mode value="slashdot"> (speech, beer) </mode> InstallShield clone, InnoSetup to do the install. I have to put a lot of things in to batch files that run at the end of the install, though.

Installation procedures for commercial software are tricky to design. Even high level tools such as InstallShield still require many decisions to be made. Do you want your program to work with its own private copy of perl, or do you want to allow the user to use a system perl? Do you want to assume that the user has high-speed network access? Deciding these and related issues and implementing the solutions can easily take weeks. This is hard to believe for many of us who are used to open-source software, but packaging concerns can easily absorb a sizable chunk of a shrink-wrap software project. This is especially true when software installation interacts with the licensing of the software.

A large percentage of support calls are for help with licensing and installation, so it is expensive to get it wrong. Be sure to do lots of testing, especially on machines that you have never touched before. This helps to find dependencies on DLLs or other things you didn't realize were on your machine.

I have been on projects where we distributed perl several ways. The best was to build our own version of perl. We compiled perl with a visual compiler from he-who-must-not-be-named. I was shocked to find out how easy it was to build perl in this environment.

I wouldn't want to support software that required the user to work with ActiveState. The ActiveState distribution (when I last looked at it) required the user to load yet another installer program from the web site whose-url-must-not-be-spoken. This unspoken website can't even be viewed with Netscape any more, at least on any of my machines. Also, ActiveState probably doesn't have a worldwide support staff standing by a toll-free number to answer your customer's questions.

The InstallShield software works reasonably well. You can set it up to install a shortcut, check for necessary disk space, and do all the things that you expect from a commercial software install and uninstall. You have to learn to drive InstallShield, and it costs some money of course, but there is no royalty AFAIK. Who knows, maybe someday the InstallShield program will include a button that asks "you want perl with that?"

You could also turn your program into a CGI and just run it from your server. The hard part there is getting the security right, collecting the money, and re-architecting your software to work properly as a client-server application.

You can also distribute a web server with your software and use it to launch perl and act as a GUI. I have used the Apache web server to do this.

If you are ambitious this web-server approach can also take advantage of the performance improvements available from the mod_perl environment. A good place to learn about using mod_perl in your application might be Bridging mod_Perl to Other Persistent Perl Environments at the Open Source Convention.

It should work perfectly the first time! - toma

You can run Perl from a networked drive, with a few notes, and it heps to have ActivePerl at hand -- I did this often with login scripts at my old job in a Win32 enviorment. As I recall, it went something like:

1. Install Perl onto server
   
2. Share out the directory with Perl in it read-only and with tight security (there's a bug from awhile back that required me to share out from the parent dir, i.e. c:\perl instead of c:\perl\bin, might be fixed now
3. Write the perl script per normal
4. Use the pl2bat utility, and edit the batch file to map to the share w/perl
5. Run and test

If you're in a *INX enviorment, I'd think much the same would apply. NOTE: This should be done from a fully secured network -- PLEASE do not try this with your perl.exe on a web server.

----Asim, known to some as Woodrow.

Some things (using some modules) are a little tricky, but you get the hang of it. I even got it to work with external .dll files from Inline::C which is kind of cool.

The major thing with PerlApp and Perl2Exe is that it solves the distribution and deployment problem in such a good way. If you want to get new users of Perl programs in your organization, the wrong thing to do is to make them install Perl (and you really don't want to run around doing it yourself either). Just send them the .exe file.

-"Yeah, just double click on the icon. Ok? It started? Good."

/J