It appears that, after beating my head slightly, simply changing my environment variable from PERLLIB to PERL5LIB fixes an odd problem.
Quick background: local install to ~/perl. In order for cpan to properly detect pre-reqs that it just installed, you need to set the environment to include all the proper locations. So I just put this in a file, I called it 'sp' (short for "set perl environment" - if I'm going to make a short cut, I emphasise short), and just run ". ~/sp":
(I'm sure I could do that with just perl, no find, but, hey, the point is lazy, not perl purity.) As long as I'm being lazy, I omit the '5' in 'PERL5LIB' because, well, perlrun says that when PERL5LIB isn't set, it falls back to PERLLIB. That turns out to be true for perl. But not for everything else. Specifically, if you're installing something that requires another module that is also not core (and thus in your local module directory), and, I think, the current module also uses MM instead of Module::Build (though maybe I just didn't hit it with MB), I think the PERL5LIB gets set, basically ignoring your PERLLIB, and suddenly things can't be found, and tests fail. Miserably.export PERLLIB=`find $HOME/perl -name 5.8.8 -o -name aix* -o -name sit +e* | \ xargs perl -e 'print join ":",@ARGV'`
Adding in the 5 again, and suddenly "cpan -i Perl::Critic" works just fine. Ugh. Shortcuts that aren't. Don't use PERLLIB. Use PERL5LIB. Because that seems to be what some others are doing, and you'll get bit otherwise. Woops.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: PERLLIB vs PERL5LIB: not quite the same
by JavaFan (Canon) on Jan 08, 2010 at 10:41 UTC | |
by almut (Canon) on Jan 08, 2010 at 11:21 UTC | |
|
Re: PERLLIB vs PERL5LIB: not quite the same
by Anonymous Monk on Jan 08, 2010 at 07:51 UTC | |
by almut (Canon) on Jan 08, 2010 at 09:54 UTC |