To be honest, perl is somewhat designed for this. First question is what platform this is.
Windows: Have everyone "net use" a shared drive as the same drive letter. Update Config.pm such that it points to this drive letter (this is important for "use diagnostics" to work). Done.
Unix/Linux: Same idea, except using NFS or some other shared disk technology (AFS, DFS, SAN, NAS, etc.). Here you may be compiling from scratch, and Configure.sh actually has an option to pay attention to for setting this up during compilation. If you're compiling your own, then Config.pm will already be set up properly.
Either way, remote access to perl makes it easier to manage, but does also make it slower, and, depending on the sharing technology (SMB, NFS), can also make it less reliable.
| [reply] |
| [reply] |
The reason for all the machines to see perl as installed in the same location is so that you can update Config.pm. (I realise that case is unimportant on Windows, but I like to use the Unix case since it works everywhere.)
If the values in Config.pm are incorrect, then diagnostics won't work, and I'd imagine there may be other modules that may not work, although I haven't yet hit upon them (because I use diagnostics, I already have Config.pm fixed everywhere, so I wouldn't see further problems).
Just scan through your Config.pm (the one in your lib directory) for where you have perl already installed, and change those instances of the directory to the new directory, and you're all set.
| [reply] |
We have approx 15-20 different machines with Perl at work. We simply install ActivePerl on every machine, to get the "Windows only features", like PerlScript to work.
Then we have two directories "perl58lib" and "perl56lib" where we install the modules that do not come with the standard installation.
So after every installation, we simply add the appropriate directory to the PERL5LIB environment variable and voila, all additional modules are accessible from that machine.
| [reply] |