Building your own Perl

Author: John M. Gabriele | back to index

  • Building your own Perl

    • ---

    Why?

    Why would you want to build your own Perl? On my system (which is Debian-based), Perl comes stock. On top of that, you can aptitude install almost any extra modules you please. So why bother?

    Probably the main reason is, if you're working on software that will be installed on systems other than your own, you may want to have your own Perl that you can change around as you see fit (upgrade, downgrade, install/remove/replace modules, etc.). You may need to have a specific version of Perl and set of modules which are duplicated on the server you're targeting -- a set with specific versions that you're testing against. Maybe you want to install modules that aren't available via aptitude, but don't want to sneak around Apt.

    Another reason it's nice to have your very own Perl is that, if you really botch it up, you can very easily wipe the whole thing out and start over again from scratch.

    That said, on most Debian-based systems, it's much easier to just aptitude install all the Perly pieces you need, and many setups get by very well doing just that. Note, it's probably unwise to use the CPANPLUS module to install modules into your OS-provided system Perl. If you need a Perl module distribution that's not available via Apt, either use dh-make-perl, or else install the module into your own ~/perllib.

    Building your own Perl

    Get the source

    You get the source code (aka, the "Perl Kit") from CPAN. Specifically, go to http://www.cpan.org/, and click "Perl Source Code".

    For this article, I'll be building in ~/opt/src and installing Perl into its own ~/opt/perl-n.m.o directory (where n.m.o corresponds to the revision.version.subversion numbers). It may also be common to install into /opt instead of ~/opt but you might use ~/opt when installing on a machine where you don't have root access, or if you're just trying things out, so that's what's described here.

    Unpack the archive in ~/opt/src and it'll create its own perl-n.m.o directory.

    Read README, INSTALL, and README.your_platform

    There's a main README file, plus individual ones for the various supported platforms. You'll want to have a look at them.

    Build and Install

    The complete configuration and build instructions are in the INSTALL file. For the common situation of installing Perl in its own alternative directory on your GNU/Linux system, the steps (as described in INSTALL) are: 

    cd ~/opt
mkdir perl-n.m.o
cd ~/opt/src
tar xzf perl-n.m.o.tar.gz
cd perl-n.m.o
rm -f config.sh Policy.sh
./Configure -Dprefix=/home/john/opt/perl-n.m.o
make
make test
make install

    The Configure script will prompt you with various questions. It goes like a conversation with a friendly admin and is instructive to go through at least once. It will ask you many questions for which you probably won't know the answers. The defaults are usually correct. Some quirks I noticed while running it:

    If you read through all the questions, it'll take about a half an hour to complete the configuration process. Then figure at least 5 minutes apiece for make and make test.

    Post-install config 

    cd ~/opt
ln -s perl-n.m.o perl

    Then, you might want to prepend ~/opt/perl/bin to your PATH. If you have two perl's on your system, note which comes first in your PATH. This is key when running commands like perl Build.PL. If the shell finds the system perl first, then the resulting Build script will use the wrong Config.pm and try to install files into a system directory instead of your own in ~/opt/perl-n.m.o/bin.

    Now that you have your own perl at the front of your PATH, you can use this shebang in your scripts: 

    #!/usr/bin/env perl

    and it'll find your own perl first. If you want to be doubly sure which perl your script is run by, try this: 

    #!/usr/bin/env perl
print "This perl: $^X\n";

    Of course, you can also just use the following if you prefer: 

    #!/home/john/opt/bin/perl