Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Aristotle (5147)

Aristotle
  pagaltzis@gmx.de
http://plasmasturm.org/

Blah blah blah blah blah [technorati.com]

Journal of Aristotle (5147)

Tuesday October 28, 2008
05:09 AM

Installing a perl with a minimal, collapsed directory layout

[ #37756 ]

I just started getting onto the one-perl-per-app train. By default, Configure wants to set up an installation with a deeply nested directory layout so as much as possible can be shared across installs. I don’t care about that – having completely separate installs is quite affordable these days. So all that hierarchy is merely annoying and serves no useful purpose, and I would prefer to simply have all modules in ./lib and all XS components in ./archlib below the root directory of the installation, without any further nesting for different Perl versions, system architectures and packaging authorities.

But figuring out exactly how to get Perl’s Configure to give me I want took almost two hours of fiddling and research (and the final hint came from a rather tangential archived mailing list post).

So I thought I would jot the recipe down here:

PREFIX=$HOME/perl/5.10.0  # pick any root directory you like
sh Configure -des \
    -Dprefix=$PREFIX \
    -Dinc_version_list=none \
    -Dprivlib=$PREFIX/lib \
    -Darchlib=$PREFIX/archlib \
    -Dsitearch=$PREFIX/archlib \
    -Dsitelib=$PREFIX/lib

The maddening part was to figure out that inc_version_list must be none, otherwise the sitearch and sitelib settings will be ignored and Configure will generate the default deeply nested layout for them.

I have to say that Perl requires rather a lot of work to beat it into submission to my preferences…

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Thanks for sharing this idea. Do you also extend it to Apache/mod_perl usage? I would like to upgrade Perl from 5.8 to 5.10 in a project that is deployed on a development machine and four mod_perl production web servers. If I expect the current code can run under 5.8 and 5.10 with no modifications, perhaps it doesn't have to be so complicated.
    • Hmm, that’s a good question. I don’t know, nor am I likely to figure anything out. My own tendency has been to treat mod_perl as something to use specifically for writing Apache modules, but to not use Apache modules as a web app deployment platform.

      For that I now prefer an in-process HTTP implementation – in this case, Catalyst::Engine::HTTP::Prefork – along with whatever reverse proxy is most handy. I also don’t bother with highly involved configurations for serving static fi

      • Thanks for sharing your techniques. How do you handle some of the functions typically be handled by Apache in web application, for example, rewrites, redirects and aliases (allowing a directory outside the web server root to appear within it)?
        • All decent dedicated reverse proxies have features on par with mod_rewrite, so it’s not hard to adapt the practice accordingly. However, rather than using such features for everything I have actually come to consider some of that work, esp. redirects, as part of the app itself – f.ex. redirects to support the URI structure of an old version of the app. So I write logic for them in the app using the framework’s features. The reverse proxy is the place for rewrites that concern the integrati