Ask a Question related to PERL Miscellaneous, Design and Development.
-
Michael P. Broida #1
Installing from CPAN on Win32
Hi!
I downloaded a module from CPAN. I want to install it on my system,
but NOT in the net-wide perl "lib" area; I want it in a subdirectory
under my home dir until I can verify that it does what I need AND I
can convince the site admin to install it permanently. So, I can't
follow the installation instructions EXACTLY; I have to tailor them
a bit. OK, check the docs on how to do that.
I did:
perldoc -q "install a module"
and perldoc -q "keep my own module"
and got back some useful looking info.
The first one basically says to do:
1) Unpack the source into a temporary area.
2) perl Makefile.PL
3) make
4) make test
5) make install
Sounds pretty simple, and the second perldoc search tells me to use
"perl Makefile.PL PREFIX=<path>" insted of 2) above to make it use a
local library instead of the site-wide one. Good.
But when I try that, WITH or WITHOUT the PREFIX arg, it tells me it
can't find installed Perl. It's looking on the S: drive (my DVD drive),
but our Perl is installed on a network drive connected to T:. NOTE:
my PERLLIB env.var. points to the same directory via a UNC path. (I
think "UNC" is the right term; please correct me if needed.)
I can run Perl normally, so there's no path problem. Yet, this
"perl Makefile.pl" step fails. After the error, it does tell me:
Checking if your kit is complete...
Looks good
but I don't know if it's just checking the Manifest for the module
at that point or what.
Any ideas?
Mike
Michael P. Broida Guest
-
Need help installing via CPAN
I have been trying to install the module FileHandle::Unget via CPAN. When I execute 'make FileHandle::Unget' Running make for module... -
RESOLUTION: Using CPAN.PM on Win32: How Direct to Proper Perl Location
Hi, this message is to let you know the resolution of an issue I posted on 25 Jan 2004. I post this for the benefit of anyone Googling on the... -
Using CPAN.PM on Win32: How Direct to Proper Perl Location
Hi, I'm getting an error when trying to install Text::Diff with the CPAN module. The specific error is: *snip* Checking if your kit is... -
CPAN and case for problem win32?
There are 2 modules that only differ in case: Crypt::Tea and Crypt::TEA, and I think using CPAN to install them gets confused on win32 (maybe also... -
PPM3 Activestate Perl (and CPAN on Win32)
> What rpm repositories does everyone use with ppm? Here are a few I know of: http://theoryx5.uwinnipeg.ca/ppms/ <-- many CGI/Apache/DBI/GD... -
Sisyphus #2
Re: Installing from CPAN on Win32
Michael P. Broida wrote:
Try 'perl Makefile.PL LIB=<path>'.> Hi!
> I downloaded a module from CPAN. I want to install it on my system,
> but NOT in the net-wide perl "lib" area; I want it in a subdirectory
> under my home dir until I can verify that it does what I need AND I
> can convince the site admin to install it permanently. So, I can't
> follow the installation instructions EXACTLY; I have to tailor them
> a bit. OK, check the docs on how to do that.
>
> I did:
> perldoc -q "install a module"
> and perldoc -q "keep my own module"
> and got back some useful looking info.
>
> The first one basically says to do:
> 1) Unpack the source into a temporary area.
> 2) perl Makefile.PL
> 3) make
> 4) make test
> 5) make install
>
> Sounds pretty simple, and the second perldoc search tells me to use
> "perl Makefile.PL PREFIX=<path>" insted of 2) above to make it use a
> local library instead of the site-wide one. Good.
>
> But when I try that, WITH or WITHOUT the PREFIX arg, it tells me it
> can't find installed Perl. It's looking on the S: drive (my DVD drive),
> but our Perl is installed on a network drive connected to T:. NOTE:
> my PERLLIB env.var. points to the same directory via a UNC path. (I
> think "UNC" is the right term; please correct me if needed.)
>
See 'perldoc ExtUtils::MakeMaker' for some additional documentation.
Cheers,
Rob
Sisyphus Guest
-
Michael P. Broida #3
Re: Installing from CPAN on Win32
Sisyphus wrote:
I looked there yesterday; LOTS and LOTS of confusing info. :)>
> Michael P. Broida wrote:>> > Hi!
> > I downloaded a module from CPAN. I want to install it on my system,
> > but NOT in the net-wide perl "lib" area; I want it in a subdirectory
> > under my home dir until I can verify that it does what I need AND I
> > can convince the site admin to install it permanently. So, I can't
> > follow the installation instructions EXACTLY; I have to tailor them
> > a bit. OK, check the docs on how to do that.
> >
> > I did:
> > perldoc -q "install a module"
> > and perldoc -q "keep my own module"
> > and got back some useful looking info.
> >
> > The first one basically says to do:
> > 1) Unpack the source into a temporary area.
> > 2) perl Makefile.PL
> > 3) make
> > 4) make test
> > 5) make install
> >
> > Sounds pretty simple, and the second perldoc search tells me to use
> > "perl Makefile.PL PREFIX=<path>" insted of 2) above to make it use a
> > local library instead of the site-wide one. Good.
> >
> > But when I try that, WITH or WITHOUT the PREFIX arg, it tells me it
> > can't find installed Perl. It's looking on the S: drive (my DVD drive),
> > but our Perl is installed on a network drive connected to T:. NOTE:
> > my PERLLIB env.var. points to the same directory via a UNC path. (I
> > think "UNC" is the right term; please correct me if needed.)
> Try 'perl Makefile.PL LIB=<path>'.
> See 'perldoc ExtUtils::MakeMaker' for some additional documentation.
Just now tried using "LIB=" as you suggest, pointing to a new
subdirectory on C:, but I get the same error: it wants to find
the Perl installation on the S: drive, but ours is on T: instead.
Any ideas how to make it see the Perl installation on T:??
Or why MakeMaker wants to see it on S:??
Mike
Michael P. Broida Guest
-
James Willmore #4
Re: Installing from CPAN on Win32
"Michael P. Broida" <michael.p.broida@boeing.com> wrote in message news:<3F60C5B5.2CA81791@boeing.com>...
<snip>> Sisyphus wrote:> >
> > Michael P. Broida wrote:Just some suggestions/questions ...>
> I looked there yesterday; LOTS and LOTS of confusing info. :)
>
> Just now tried using "LIB=" as you suggest, pointing to a new
> subdirectory on C:, but I get the same error: it wants to find
> the Perl installation on the S: drive, but ours is on T: instead.
>
> Any ideas how to make it see the Perl installation on T:??
> Or why MakeMaker wants to see it on S:??
Are you _sure_ the drive mappings are correct? Something isn't fouled
in whatever login script may be launched? Re-map the drive just to be
sure?
And how about your PATH? Is it set properly? Have you tried to
change it so that the only directories in there are for what you're
trying to do?
What do you get when you type 'perl -V'? Is the result from this
command expected? @INC is what you expect it to be?
Again, just some suggestions/questions to be answered.
Jim
James Willmore Guest
-
Michael P. Broida #5
Re: Installing from CPAN on Win32
James Willmore wrote:
No problem. I appreciate any insights.>
> "Michael P. Broida" <michael.p.broida@boeing.com> wrote in message news:<3F60C5B5.2CA81791@boeing.com>...> <snip>> > Sisyphus wrote:> > >
> > > Michael P. Broida wrote:>> >
> > I looked there yesterday; LOTS and LOTS of confusing info. :)
> >
> > Just now tried using "LIB=" as you suggest, pointing to a new
> > subdirectory on C:, but I get the same error: it wants to find
> > the Perl installation on the S: drive, but ours is on T: instead.
> >
> > Any ideas how to make it see the Perl installation on T:??
> > Or why MakeMaker wants to see it on S:??
> Just some suggestions/questions ...
>
> Are you _sure_ the drive mappings are correct? Something isn't fouled
> in whatever login script may be launched? Re-map the drive just to be
> sure?
> And how about your PATH? Is it set properly? Have you tried to
> change it so that the only directories in there are for what you're
> trying to do?
> What do you get when you type 'perl -V'? Is the result from this
> command expected? @INC is what you expect it to be?
>
> Again, just some suggestions/questions to be answered.
Yep, the drive mappings are as expected, and have been for a long time.
This is Win2K, so there's no "login script" launched when running a Perl
script; and all my Perl scripts work fine. I use that mapped drive (and
several others) all day long for other tools as well as Perl scripts.
The PATH is setup fine; Perl is exactly where expected, and there is no
other Perl installation at or below any path element before or after that
one in the PATH variable. I haven't modified the path because there are
paths to several critical tools in there that I can't remove without
screwing up all of their functionality (and losing a lot of work time).
Otherwise, it's set as minimal as I can safely make it.
"perl -V" says a LOT of stuff. <grin>
Main info:
perl5 (revision 5 version 6 subversion 0)
osname=MSWin32
@INC looks as expected, PERLLIB looks as expected (and fits with @INC
content. Both show the UNC path that corresponds to my T: mapping.
"libpth" includes "S:\Perl\lib\CORE" which is the error I mentioned
earlier: I don't have an "S:" drive.
Here's one oddity that hasn't hurt my USING perl, but maybe it's a
problem with trying to install a perl module: Inside of "ldflags"
for "Linker and LIbraries" (and in "lddlflags" for "Dynamic Linking"),
there is:
-libpath:"E:\Utils\Perl\lib\CORE"
I don't have an "E:" drive mapped, either, so I don't know why that
is there. My Perl installation is on the mapped T: drive and not under
a "Utils" directory at all.
So, I'm still at a loss as to why Perl (including "perl -V") thinks
our Perl installation is on S: and won't see the T: installation (that
SOME of "perl -V" points to).
Anyway, I've decided to go a different way with the project that started
this whole thing. I was trying to use Win32::GUI (from CPAN) to setup
a simple GUI over the main Perl tool. Due to this problem (and because
we don't have a Java2 compiler handy), I'm building an MFC0-based GUI
that will kick-off the Perl script to do the real work. Thus, we can
just let this thread die out, unless you have some further insight into
the whole thing. :)
Thanks for the inputs!
Mike
Michael P. Broida Guest



Reply With Quote

