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
In reply to Re: Perl executables on a machine w/out Perl installed
by toma
in thread Perl executables on a machine w/out Perl installed
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |