How can I create a portable perl when I can't install modules on the target host?

Question

I need to run Perl applications I develop on cygwin Windows on HP unix / Solaris hosts. I am not a superuser on the unix machines and I can't touch the default Perl module location nor can I install modules to the default Perl module location. Also the unix installation lacks most basic modules and I can't change that.

For example, I have a Perl application that needs Expect which has native C compiled parts to it. How would I roll out this application to unix with its required dependencies without having to install anything else on that box?

Is there way to build the entire Perl application under Cygwin Windows and then just roll out one executable to unix and run it from my home directory there?

---

EDIT addition based on answers so far:

Thanks in particular to brian, the local LIB dir solution seems to work in case of native Perl, but in case of Perl module needing C components, cross platform compiling, ie compiling on cygwin to run on Solaris, is not really possible as I feared.

However would having an other linux installation help, i.e. would this be possible easier between different flavors of Unix like package Perl on linux and then deploy to Solaris/HP? And what about something like lcc ?

Also I'd still like to hear little more if somebody has rolled out a native Perl package on Windows that includes all dependencies for a complicated Perl app that can then be moved to unix as just one file? (I do now understand that it won't work in case native C code is included like in in Expect.pm, but what about in case of app only using pure perl modules?)

Basically for many reasons I am trying to minimize time I need to spend being logged into these "production" unix hosts and do as much as possible locally beforehand.

---

Added a new cross-compile question, since I felt I was maybe veering too far from the original perl question.

---

EDIT -- Par looks promising for pure Perl, although same deal, it doesn't look to solve the cross platform compile problem for native extensions

Answer 1

Set your environment variable PERLLIB to your personnal Perl lib directory or use the -I command line switch to Perl to indicate it.

If you have access to the HP-UX machine you can compile Expect there and install it in your directory. But cross compilation from Windows to HP-UX is probably much more difficult. You would have to build a GCC cross compiler.

Answer 2

Compiling a Perl script with all its dependencies on Windows with Cygwin and running it Solaris is just not going to work.

Now the question is: do you have access to a compiler on that Solaris computer? It's not because you do not have root access that you cannot compile and install Perl modules in your home directory by using:

perl Makefile.PL PREFIX=$HOME

If you have CPAN available on your Solaris system you can set the prefix in the CPAN shell this way:

1. start the shell perl -MCPAN -e shell;
2. change the prefix with conf makepl_arg PREFIX=/path/to/your/home/directory

For your script to run, you can either start perl with the -I $HOME command-line switch, e.g.:

perl -I $HOME script.pl

Your other option would be to place this at the begining of your script

use lib $ENV{'HOME'};

Answer 3

If you have a compiler on each of your systems (and some other tools needed by configure like grep), you should not only be able to compile modules, but you should also be able to build your own perl executables.

Answer 4

I haven't tried this particular feature, but perl2exe says it supports cross platform builds.

Answer 5

You'll want local::lib. Once you've done that, the pure Perl modules should work cross platform, but you'll have to identify and reinstall the compiled modules on the foreign platform. Do the initial install on a real unix, cpan on cygwin is slow.

Answer 6

In this case, I'd consider delivering a complete application complete with its own Perl. You get to choose any version you like and any modules you like. Compile everything, organize everything into a directory, then tar the result. To deploy, copy the file and untar. Use the advice that others have already noted about library search paths, etc. In essence, your application gets its own stack.

Now, the trick there is the cross compilation. Why are you developing on Cygwin? Is that a target too? Is there a reason you don't have an HP/UX or Solaris development machine? What architecture are you targeting (RISC, SPARC, Intel, etc). If you can't get hardware to run those, get some virtual machines for your targets and develop there.

Aside from that, you can install modules anywhere you have permissions. See perlfaq8:

• How do I keep my own module/library directory?
• How do I add the directory my program lives in to the module/library search path?
• How do I add a directory to my include path (@INC) at runtime?

Answer 7

I've run across this several times on my work systems. We have a base install of Perl 5.8 and I don't have the ability to add modules. Here's the solution I use:

1. Create a folder called 'lib' in your project root (ex: ~/projects/MyProject/lib)
2. Any modules you download from CPAN should have a Makefile as well as a directory called "lib". Copy the contents of the lib folder into your newly created lib folder. Some modules may only contain a single .pm file, and no lib structure. Just copy the .pm file.

Your code should do the following: first, use any modules that have been installed normally, then unshift your @INC environment variable to use your local libraries:

# Declare Includes --------------------------------------------------------------------------------
use Getopt::Long;
use vars qw($VERSION);
use DirHandle;
use FileHandle;


# Force perl to use our local 'lib' directory for imported modules, this allows us to
# use modules without having to install them in th emain perl assembly. However, this
#also prevents these modules from being used in other projects.
BEGIN { unshift @INC, "lib"; }
use Error qw(:try);
use SOAP::Transport::HTTP;
#use LWP::Protocol::https;
use XML::Simple;
use XML::Writer;
use XML::Writer::String;

The caveat to this method is that some Perl modules don't use the 'lib' method or have additional dependencies. If you run into problems, examine the Makefile.PL for the module and see what it's doing.