| [reply] |
How you deploy your Perl code has a lot to due with the sophistication of the users and also how much time you want to spend on the installation/deployment package. Most of my code gets deployed to Windows end-users. These guys have never heard the word "Perl" much less "make". For this case, I make a stand-alone .exe file for Windows with the ActiveState tools. This works pretty well. I can stuff an icon into the .exe file and it looks familiar to them, "click here". It is also possible to make executable files for Mac and Linux.If you are deploying onto a Unix system with a system admin, then the sophistication level is vastly different and some base Perl stuff will already be there to assist a Perl installation script. This is a chicken and egg thing! I mean how do you run the CPAN module without Perl to begin with? You can also have your own Perl environment independent of system default, i.e it is ok for you to run Perl 5.10 even if they have 5.8. But 5.x was there in the first place to get you started! Anyway for the unsophisticated user, I recommend deploying an .exe file. The programs that I've deployed in source code format have been to sophisticated users who don't mind installing or verifying a few modules are there. So I guess this is a "your mileage my vary" thing.
| [reply] |
I'm going to guess from the way you described this that you're dealing with Windows. For that case I've had luck with putting Perl and the required modules on a file server somewhere, and then giving end users a .bat file which uses them. You can start that with the utility pl2bat and then edit it slightly to make it refer to the copy of Perl on the file server.
If done correctly pure Perl programs will work with no local installation at all. And you don't have to create a large executable for every utility.
It has been some years since I did this. At that time I was using ActiveState. What I would do to set things up was install Perl on my machine, copy the Perl directory to the file server, find perlcrt.dll and copy that to Perl's bin subdirectory, then create my .bat files and away I'd go. I could not tell you whether there is still that dll dependency, or whether there might be a new dependency. You will have to experiment to figure out what works. | [reply] |
| [reply]
[d/l] |
To reiterate the previous post... yes, everywhere the code runs, “the library code must somehow be available,” but no, “there isn't Just One Way To Do It.” (This is Perl, after all...)
There are lots and lots of ways to deploy a Perl application. One of them is to create an “executable” which is completely self-contained. It basically contains all the necessary Perl code, and looks only “inward, to itself,” to find it.
Perl = TMTOWTDI!
| |
Another option would be to deploy the modules you want as well as the code and use
use lib "/wherever/you/deployed/them/";
in your code. I find this works for my own modules, so no reason you couldn't do this. However you may hit problems if these modules are then dependant on other modules etc.
Hope that is of use. | [reply]
[d/l] |