All the Perl that's Practical to Extract and Report
use Perl Log In
Aristotle (5147)
Installing a perl with a minimal, collapsed directory layout
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…
I pour myself a cup of strong coffee. :-)
-- Jarkko Hietaniemi
extended to mod_perl (Score:1)
Re: (Score:1)
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
Re: Aristotle's web app deployment model (Score:1)
Re: (Score:1)
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
Re: Aristotle's web app deployment model (Thanks) (Score:1)
Thanks, for the reply.
I'm coming to the same conclusion about the benefit of self-contained apps, and having a maximal amount under source control, compared to creating a coupling between app changes and web server configuration.