Perl is a must have tool on every system. I use it almost every day to manipulate data from command lines and to write small utility scripts. I made the jump to Ruby a number of years ago and concede to the readability and cleanliness of it's object oriented language over Perl. Anything that I can do in Perl I can also do in Ruby. That said, I still use Perl because of the huge repository I have of legacy Perl scripts and the sheer number of scripts available on the net. Ruby will ( in my opinion ) surpass Perl in this regard, but until that day comes, I will still be writing some Perl.

Even more recently I have been writing a lot of Groovy code. Groovy is a great Java scripting language that has access to the entire Java API. It is incredibly useful language and I highly recommend giving it a try. 

All that said, lets get on to the subject at hand.. Transportable Perl.  Ok, what the heck does that mean? Perl scripts are generally transportable from system to system and can even, within some limits, move from OS to OS. What I am referring to, is the ability to move the Perl executable from one place to another on your system without recompiling Perl. Why would you want to do this? Well, several reasons spring to mind. Out of space on a primary disk. Disk restructuring. You work for a company that delivers OSS content to the desktop, and you want to be able to install Perl anywhere the end-user wants to specify, without making them recompile. 

And that, is the exact reason why I have been looking at the issue.

When you compile 'C' projects you can ( and frequently do ) specify the install directory where the build artifacts will reside. [ - - prefix during configure on Unix systems ]  That is very handy. However, lets say you precompile perl to the install directory of c:\toolbox\perl.  Then you bundle that compiled binary and place it on a different computer say in c:\tacklebox\perl.  The Perl interpreter will work. It will run perl scripts and everything will be fine.

Unless….  you want to extend that install of Perl. You just found a cool new module on CPAN, and you want to install it and play with it. Now, you have an issue with that new path. The original path                  ( c:\toolbox\perl ) is compiled into, and configured into that Perl distribution. Even if you have the right tools to compile that module on your windows ( yuck! ) box, it will install it into that old path, rather than the new path you would rather have. 

We need some tool that can fix that inbred old path turning it into the new  path that we really want.  What tool should we use to do that? Perl, of course,  it is a great language to data parsing and replacement.

The first  thing we need to do is find all of the places were that old path is lurking. 

Most module builds will use the Perl module ExtUtils::MakeMaker and Config to generate the Makefile that will be used to install the module. That module creates / uses several files by which it generates the makefile. Those files are the key to moving the Perl install. With just a few one liners you can fix the install path. The first file to work on is in the Perl source, it is config.sh.

We want to reset the "head" of the Perl distribution so an example one liner to do that would be.

perl -p -i.bak -e 's/c:\\toolbox\\perl\\lib/c:\\tacklebox\\perl\\lib/g' config.sh 

Then we would do the same command on the file Config-heavy.pl. ( Found in the lib dir of Perl )

We need to do the same on the Config.pm file, but as we look in it, we see that it uses double slashes rather than singles for referencing directories. ( man, that is a pain in the neck!!) So, we would modify our  one liner to look like this :

 perl -p -i.bak -e 's/c:\\\\toolbox\\\\perl\\\\lib/c:\\\\tacklebox\\\\perl\\lib/g' config.sh

And viola!! you should have a working set of files. There are some gotchas along the way here. If you are using a UNIX style perl distribution, you will have the lib dir under the Perl src directory, you will need to make a copy of that and move it to lib. Also, Windows nmake will look for a config.h file in the src directory that does not exist. It does not have to have anything in it, but does need to be created.

Once you pull down a module, then you can run : perl Makefile.pl.   This should create a correct makefile for the new perl path and allow you to then run nmake, and build the module. nmake install && nmake test should both work ( if present in that particular module ) 

Additionally, the PERLLIB and PERL5LIB environment variables need to be set correctly for the new Perl location. 

The next steps would be to roll the changes into one "Fix" script. ( Creation of the environment variables, conifg.h file, in place edits of the config scripts ) Actually, in my case I have built these changes into the OpenLogic Enterprise software package, such that when a user of our software request an install of Perl, we can install a pre-compiled version of Perl, and then restructure the compiled elements to live anywhere on that users system that they request.