|
Re: Installing modules to a private module directory
by tinita (Parson) on Apr 21, 2008 at 20:42 UTC
|
do you have an example where
perl Makefile.PL PREFIX=/dir LIB=/dir
does not work? i didn't find one in your blog. | [reply]
[d/l] |
|
|
It was quite recently reported again that Module::Build still hates PREFIX= (despite it having been quite a while since the last time I heard rumor of somebody going to teach its author how to handle PREFIX= in a reasonable way). Perhaps the report is due to an old version of the module being used, but I suspect not. (And, yes, "perl Makefile.PL" 'should' work even if Module::Build was used, that is, so long as you don't specify PREFIX=.)
Of course, I don't have to strain at all to imagine cases where "cp -pr ..." would fail.
| [reply] |
|
|
I guess you refer to my report. The version of Module::Build was as you suspect recent:
perl -MModule::Build -e 'print "$Module::Build::VERSION \n";'
0.2808
It was no big deal doing a perl Build.pl --install_base ~/perl5lib, other than having to resolve a couple of dependencies the same way before succeding. I'd really like to get that .modulebuildrc configured correctly to avoid the hassle.
Now, I'm not sure if I find it a relief or terifying that issues like these even annoys people like Dominus, who are not a just litle bit smarter and more knowlegdable than I am.
It will be interesting to see if the method he describes on his blog works for me. If it does, it can't be to hard to make a nice litle script for it.
| [reply]
[d/l]
[select] |
|
|
|
|
|
|
i didn't find one in your blog.
Did you actually try this? I did, and it fails, for reasons I did explain in the blog. ("...the first thing everyone says is that you can just set PREFIX to X. No, because...")
| [reply] |
|
|
Instead of PREFIX, you can use INSTALL_BASE, which I believe is now the perferred option for Module::Build and ExtUtils::MakeMaker (so long as you have up-to-date versions of both). I haven't had a problem with this, altho I haven't installed all of CPAN with it.
You still run into the problem of setting your @INC, since things seem to randomly install in a subdirectory called either 'site_perl', 'perl5' or '5.x.x', meaning you have to add 3 entries to your @INC. This can be annoying if your paths can change depending on the box you're working on.
| [reply] |
|
|
Did you actually try this?
otherwise i wouldn't ask.
maybe i just don't get it, but it has always worked for me
to install my modules with setting PREFIX and LIB. i
just asked for an example. show me a module where it
doesn't work. that's all i asked for. i would be really
interested because i use the PREFIX/LIB method for my
cgipan script and i would like to correct it if it has got a mistake.
in your blog you gave the reason why it doesn't work to set PREFIX. but you didn't say that using PREFIX and LIB together fails.
| [reply] |
|
|
|
|
Re: Installing modules to a private module directory
by Anonymous Monk on Apr 22, 2008 at 14:33 UTC
|
D:\> md extutils-installed-t
D:\> cd extutils-installed-t
D:\extutils-installed-t>
D:\extutils-installed-t>h2xs -AXn Testi
Defaulting to backwards compatibility with perl 5.8.7
If you intend this module to be compatible with earlier perl versions,
+ please
specify a minimum perl version with the -b option.
Writing Testi/lib/Testi.pm
Writing Testi/Makefile.PL
Writing Testi/README
Writing Testi/t/Testi.t
Writing Testi/Changes
Writing Testi/MANIFEST
D:\extutils-installed-t>cd Testi
D:\extutils-installed-t\Testi>perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for Testi
D:\extutils-installed-t\Testi>nmake test
Microsoft (R) Program Maintenance Utility Version 1.50
Copyright (c) Microsoft Corp 1988-94. All rights reserved.
cp lib/Testi.pm blib\lib\Testi.pm
D:\perl\theoryx5\Perl\bin\perl.exe "-MExtUtils::Command::MM" "
+-e" "test_harness(0, 'blib\lib', 'blib\arch')" t/*
.t
t/Testi....ok
All tests successful.
Files=1, Tests=1, 0 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 C
+PU)
D:\extutils-installed-t\Testi>perl -MExtUtils::Install -e "install({ @
+ARGV } )" blib/lib ../daBOMBlib
Installing ..\daBOMBlib\Testi.pm
D:\extutils-installed-t\Testi>cdt ..
D:\extutils-installed-t>perl -IdaBOMBlib -MTesti -e"die Testi->VERSION
+"
0.01 at -e line 1.
D:\extutils-installed-t>tree /f /a
D:.
|
+---daBOMBlib
| Testi.pm
|
\---Testi
| Changes
| Makefile
| Makefile.PL
| MANIFEST
| pm_to_blib
| README
|
+---blib
| +---arch
| | | .exists
| | |
| | \---auto
| | \---Testi
| | .exists
| |
| +---bin
| | .exists
| |
| +---lib
| | | .exists
| | | Testi.pm
| | |
| | \---auto
| | \---Testi
| | .exists
| |
| +---man1
| | .exists
| |
| +---man3
| | .exists
| |
| \---script
| .exists
|
+---lib
| Testi.pm
|
\---t
Testi.t
D:\extutils-installed-t>
| [reply]
[d/l] |
|
|
The doc say
Both install() and uninstall() are specific to the way ExtUtils::MakeMaker handles the installation and deinstallation of perl modules. They are not designed as general purpose tools.,
but its de-facto standard (same as blib), both Module::Install and Module::Build use it.
| [reply] |
Re: Installing modules to a private module directory
by naikonta (Curate) on Apr 28, 2008 at 15:24 UTC
|
First of all, now I'm really sure that I'm not the only one who has need of including non standard CPAN modules in the application distribution as I presented in my meditation. Further, my situation was, even if the target host did have one or more of the modules, I inclined that the application used the ones in its private lib dir.
After struggling with docs from ExtUtils::MakeMaker and Module::Build, I managed to install the modules with the following command:
perl Makefile.PL INSTALLDIRS=perl PREFIX=/path/to/appl/lib LIB=/path/t
+o/appl/lib
make
make install
Well, I think that covers the first three ways you are informed about. While the other two gave me permission error (as a normal user), only PREFIX installed smoothly. However, it layout its stuffs (lib, share, man, bin) under /path/to/appl/lib.
I somehow insisted on using so-called "standard mechanism" but failed to prevent the extra stuff from spring. One thing I noticed was I also got i486-linux-gnu-thread-multi directory for, I thought, XS modules. I don't think I would get this directory with your cp -pr approach, but I believe that directory is just a fancy place for whatever it is.
Fortunately, I didn't get any problem regarding PREFIX. It just worked.
Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!
| [reply]
[d/l]
[select] |