Compile a development version of perl

Nowadays, perl development happens at a fast clip. Every month there’s a new development release that gives you a preview of what’s going to show up in the next stable version. This not only gives the perl developers a chance to test the new perl in the wild, but also for you to try new features so you can get your application in shape for the next stable release of perl. As The Effective Perl gives you a preview of some of the upcoming features, you’ll need a development version of perl to try them for yourself.

Starting with Perl 5.7, the development versions of perl have an odd number in the minor release portion of the version number, for example, 5.7, 5.9, 5.11, or the current development series, 5.13. Each month, the perl developers create a new point release. As of this writing, the latest development release of perl is 5.13.6. That means the the current development, then, is leading up to 5.13.7. Any development point release can introduce (or take away) features. The latest state of perl development is called blead.

The stable, or maintenance, versions have an even number as the minor version, such as 5.10, 5.12, or 5.14. A point release in the stable series fixes bugs but doesn’t introduce new features. We’re not concerned with those releases for this Item though.

Installing a development release is almost the same as installing a stable release (Item 110. Compile and install your own perls). In Item 110, we told you to run Configure with command-line settings so you don’t have to go through the interactive questions:

% ./Configure -des -Dprefix=/usr/local/perls/some_dir

If you do this in a development release, Configure detects that it is not a stable release and refuses to run, giving you a warning and telling you what to do. It stops because it uses the default answers, and the default answer to “Do you want to install a development release” is “no”:

First let's make sure your kit is complete.  Checking...
*** WHOA THERE!!! ***

    This is an UNSTABLE DEVELOPMENT release.
    The version of this perl5 distribution is 13, that is, odd,
    (as opposed to even) and that signifies a development release.
    If you want a maintenance release, you want an even-numbered version.

    Do ***NOT*** install this into production use.
    Data corruption and crashes are possible.

    It is most seriously suggested that you do not continue any further
    unless you want to help in developing and debugging Perl.

    If you *still* want to build perl, you can answer 'y' now,
    or pass -Dusedevel to Configure.

Do you really want to continue? [n]  
Okay, bye.

When you adjust your Configure options, you can compile a development version:

% ./Configure -des -Dusedevel -Dprefix=/usr/local/perls/some_dir

For a released version, you can name the target directory after the version:

% ./Configure -des -Dusedevel -Dprefix=/usr/local/perls/perl5.13.6

If you want to try blead, you can checkout the sources from the git repository (see perlrepository). You run Configure in the same way. Since blead is constantly changing, perhaps by the hour, you might want to always install it in the same place:

% ./Configure -des -Dusedevel -Dprefix=/usr/local/perls/blead

There’s one side effect from Configure as it sets up a development release. It automatically adds the perl version to the end of the program names under $prefix/bin. However, with blead, the version may be the previous release, not the next one. If you install from the sources leading up to Perl 5.13.7, for instance, the program names may come out as perl5.13.6. It’s best to leave those under the installation prefix so you don’t overwrite (or overlink) other releases that you installed.

Realize, though, that blead might not always compile correctly. It is, after all, the lastest state of the source. It’s nice when it does, but not surprising when it doesn’t. If you run into problems, you can use the perlbug program to report it. Use the one that comes with the perl that you are trying to install so it collects the right information!

Leave a comment


    • I don’t particularly like perlbrew. It’s so easy to compile and install your own perl that perlbrew really doesn’t save you that much. Not only that, people tend to use it as an excuse to not learn how to do it themselves. If you never learn to do it yourself, you’re setting yourself up to fail as you depend on abstract tools to hide what’s really happening. Not only that, the switching feature that perlbrew provides isn’t a feature I need or that I think people should use. It’s only bound to confuse applications about which perl you really want to run. It might be fine it you only ever run one program at a time, but I doubt anyone actually does that. See make_links to per-version tools for the way that I do it.

Leave a Reply

[ Ctrl + Enter ]