Windows user

D

doofus

Hello,

I'm a Windows user.

I upgraded to 5.8.0 and now my CPAN isn't working, as in,

perl -MCPAN -e "YOUR::MODNAME"

It just pauses for a few moments and then returns to the command prompt.

I have installed, uninstalled, re-installed CPAN using the ppm, but no
difference.

Any ideas?

Thanks
 
J

John J. Trammell

I'm a Windows user.

I upgraded to 5.8.0 and now my CPAN isn't working, as in,

perl -MCPAN -e "YOUR::MODNAME"

It just pauses for a few moments and then returns to the command prompt.

I have installed, uninstalled, re-installed CPAN using the ppm, but no
difference.

Any ideas?

I've found that reading the documentation helps on occasion.
 
S

Sam Holden

Hello,

I'm a Windows user.

I upgraded to 5.8.0 and now my CPAN isn't working, as in,

perl -MCPAN -e "YOUR::MODNAME"

It just pauses for a few moments and then returns to the command prompt.

That's what it should so.
I have installed, uninstalled, re-installed CPAN using the ppm, but no
difference.

perl -MCPAN -e "install YOUR::MODNAME"

might actually do something...
 
D

doofus

John said:
I've found that reading the documentation helps on occasion.

I *was* reading documentation.

http://www.verysimple.com/scripts/support_modules_windows.html

<quote>
Option 2 is to use the MCPAN feature that is built into Perl. To do
that, you need to have already done Option 1, because MCPAN still
requires nmake to be installed on your machine. so, at the command line,
you type:

perl -MCPAN -e "YOUR::MODNAME"

(substitute "YOUR::MODNAME" with the name of the mod you're installing,
of course) The first time you run this utility, it will ask if you are
ready to continue with the manual configuration. Unless you know your
networking stuff pretty well, i'd just hit No at this point and let Perl
auto-configure it for you. After that it will attempt to load the module
from CPAN and install it. It will look for required modules and try to
install those for you as well. </quote>

I've heard not being a snotty bastard helps on occasion.
 
E

Eric Schwartz

doofus said:

That's the wrong documentation. There's no reason to look on some
random webpage somewhere if what you need is on your own hard drive:

perldoc CPAN

You should always read the local documentation before trying to look
something up on the web, and if you do look up something on the web,
I'd recommend trying to find a site that's slightly more professional
than that one. http://www.perldoc.com/ is one such.
I've heard not being a snotty bastard helps on occasion.

When people have correct documentation on their own hard drive, and
instead of reading it, go out and choose a website that offers CGI
scripts that give instructions that are just plain wrong, a little
snottiness is indicated. If you didn't know about perldoc, then read
'perldoc perl', and chalk the rest up to experience.

-=Eric
 
S

Sam Holden

Unlike the previous post, this one usefully contributes to my
understanding.

Being pointed to the correct documentation (via perldoc) when you
were using inaccurate documentation seems like a much more useful
contribution to your understanding than spoon feeding.
 
D

doofus

Eric said:
That's the wrong documentation. There's no reason to look on some
random webpage somewhere if what you need is on your own hard drive:

It's a document. That makes it documentation.

If you don't like it, go find yourself another language.
perldoc CPAN

You should always read the local documentation before trying to look
something up on the web

Poppycock. The local documentation has *nothing* on installing modules
on windows. As far as those self-proclaimed unix bigots are concerned,
Windows doesn't even exist.

Besides, the original fart-faced fustilarian, a regular Mr. RTFM, who
made the quip in the first place could have mentioned perldoc CPAN.

Why do you think I went looking on the web in the first place.
, and if you do look up something on the web,
I'd recommend trying to find a site that's slightly more professional
than that one. http://www.perldoc.com/ is one such.

www.google.com. Is that professional enough. Search for "installing perl
modules on windows". It seems plenty of others don't agree with you.

And now, does perldoc.com mention a damn thing about how to use make on
windows. Is perldoc.com likely to be any more concerned about windows
users that whatever dumb **** in the perlsville thought up using 'make'
in the first place?

Mostly, I've found that as a windows user, the only hope of getting help
about installing anything open source is from outside the open source
sneering community and their secret campaign to prosceletyze linux by
making using their code on windows pretty damb impossible.
When people have correct documentation on their own hard drive, and
instead of reading it, go out and choose a website that offers CGI
scripts that give instructions that are just plain wrong, a little
snottiness is indicated. If you didn't know about perldoc, then read
'perldoc perl', and chalk the rest up to experience.

I knew about perldoc, but not perldoc CPAN. To me the option looked like
MCPAN all one word. See, sometimes people just need a heads up.

Listen, you could refer me to the whole vast sea of domentation out
there but fact is, Sam Holden used three words to give me what I need.

What is comp.lang.perl.misc for?

Is it so Mr. RTFM can iterate RTFM and thereby, we presume, make himself
feel good, or is it so people can actually offer one another useful
information.

Why would you not want to help people when it is so easy to do so. If
you don't want to, simply ignore the post. I mean come on, what the ****
is this newsgroup for?
 
D

doofus

Sam said:
Being pointed to the correct documentation (via perldoc) when you
were using inaccurate documentation seems like a much more useful
contribution to your understanding than spoon feeding.

Oh well, **** you then.
 
M

Mothra

[snipped]
Oh well, **** you then.

Now that is uncalled for.
This individual took his time to answer your question then
stressed the importence of using correct documentation and
you treat him like that.
For shame :(

Mothra
 
J

John J. Trammell

I *was* reading documentation.
[link to incorrect docs snipped]

Then why didn't you say so? If you had just said "I'm following
the instructions at http://foo.com/bad-doc.html", we could have
skipped all this.

http://catb.org/~esr/faqs/smart-questions.html#beprecise
http://catb.org/~esr/faqs/smart-questions.html#examples

Feel free to flame me some more if you want to vent. Maybe it will
(1) convince someone else to search the available docs before posting,
or (2) post a precise question.

<garment type="underwear" material="asbestos">
 
E

Eric Schwartz

doofus said:
It's a document. That makes it documentation.

I didn't say it wasn't documentation, I said it was the *wrong*
documentation.
If you don't like it, go find yourself another language.

Um... right.
Poppycock. The local documentation has *nothing* on installing modules
on windows. As far as those self-proclaimed unix bigots are concerned,
Windows doesn't even exist.

Then you must have a broken installation of Perl. My copy of the docs
explain how to install modules, which is pretty much the same on
Windows as it is elsewhere. If you don't have a compiler, then you
can't install XS modules with CPAN, but that's not a Windows-specific
problem-- people who live on real live UNIX machines like Solaris or
HP-UX also don't have C compilers by default.
Besides, the original fart-faced fustilarian, a regular Mr. RTFM, who
made the quip in the first place could have mentioned perldoc CPAN.

Which is why *I* mentioned it.
Why do you think I went looking on the web in the first place.

Because you didn't know about perldoc or CPAN, which is why I brought
them up. Sheesh, try a do a guy a favour sometime, and this is your
idea of 'thanks'.
www.google.com. Is that professional enough.

No. It's a search engine, not a website purporting to hand out CGI
scripts that are bad rewrites of Matt Wright's perl4-based garbage.
Search for "installing perl
modules on windows". It seems plenty of others don't agree with you.

I did. The first link returned was
<URL:http://www.rcbowen.com/imho/perl/modules.html>, which unlike the
one you cited, is apparently correct (I just skimmed it, so bugs may
lurk underneath). Anyway, Google is a poor measure of quality; its
PageRank algorithm rates sites based on who links to them, not how
correct or useful they are. If you get enough people who don't know
any better linking to a site, its Google rank will rise anyway.
And now, does perldoc.com mention a damn thing about how to use make on
windows. Is perldoc.com likely to be any more concerned about windows
users that whatever dumb **** in the perlsville thought up using 'make'
in the first place?

Does cursing make you feel superior or something? 'make' is used
because it's available anywhere you have a C compiler (including, I
might add, Windows), and because it's been used forever, and is the
best and most portable way to ensure that software is built
correctly. What would you have them use? Ant? Jam?
Mostly, I've found that as a windows user, the only hope of getting help
about installing anything open source is from outside the open source
sneering community and their secret campaign to prosceletyze linux by
making using their code on windows pretty damb impossible.

I'd guess at least half the people using Perl on this newsgroup are
using Windows, and nobody gives them crap about it. Sounds like you
have a rather large chip on your shoulder you need to get rid of,
because it's not helping you when you ask for help and then curse at
the people who try to give it to you.
I knew about perldoc, but not perldoc CPAN. To me the option looked like
MCPAN all one word. See, sometimes people just need a heads up.

So I tell you this, and instead of "Thanks, I didn't know about that,"
you respond with curses and insults? Furrfu. 'perldoc perlrun' while
you're at it. perltact would be a good module to look at, if it
really existed.
Listen, you could refer me to the whole vast sea of domentation out
there but fact is, Sam Holden used three words to give me what I need.

And I gave you more information so that next time you'd know where to
look, and would be able to solve your own problems faster.
What is comp.lang.perl.misc for?

It is for discussing miscellaneous questions related to the Perl
language. It is not your personal helpdesk, although most of us are
happy to help out anyway, if we can.
Why would you not want to help people when it is so easy to do so. If
you don't want to, simply ignore the post. I mean come on, what the ****
is this newsgroup for?

It is NOT for cursing people who try to give you help. If someone
asks questions that are in the documentation, we try to refer them to
the documentation for three reasons:

1) If everybody keeps asking questions that are already in the docs,
people get tired of that very quickly, and the experts who really
know their stuff will stop answering questions. Yes, this has
actually happened.
2) The next person who looks through the archives first will see the
reference to the docs, and read them, and not need to ask the
newsgroup.
3) It's a helluva lot faster to read 'perldoc <foo>' than it is to
post to a newsgroup and wait for someone on the other side of the
world to respond.

This newsgroup IS for discussing the Perl language, particularly for
sharing tips and tricks, and other esoterica. It's for asking
questions that the docs either don't answer, or answer ambiguously.
It's for sharing code, looking for improvements or comments. It's for
a lot more, as well. But it's not a substitute for reading
documentation, even if sometimes we feel generous, and help out anyway.

-=Eric
 
E

Eric Schwartz

Ted Zlatanov said:
Actually there's quite a few Perl users, myself included, who think a
Perl-based make would be much better than relying on the standard
one that may or may not be installed, available, or functioning. For
modules that require C compilation, maybe. But for pure Perl
installs? That's silly, given Perl's power.

Tell ya what, *you* try reimplementing make in Perl. and then come
crying back when it doesn't work right in all cases. :) Make is
*hard*, and another good reason to use it is that it's already had a
few decades of work behind it, and (if you leave out gmake-specific
extensions) is portable pretty much everywhere. As opposed to a
brand-new tool that doesn't have that kind of portability or history
or legions of people who know how to use it.
This comes up periodically in Perl discussion lists, and usually the
answer is "just wait for XYZ, it will do this and more."

I went away from clpm for a little while, but I don't recall seeing
these discussions, so I'm not sure what discussion lists are, or which
ones you're referring to.
I'm not sure what the current XYZ is/are, especially regarding why
XYZ hasn't yet replaced 'make' in CPAN installs and standard Perl
usage.

I don't know of any such XYZ.
I'm very
interested in any information, as I have needed tighter integration
between Perl and 'make' many times.

Such as? Offhand, I can't think of any time I've needed to integrate
Perl and make, other than having the one call the other (or vice
versa).

-=Eric
 
T

Ted Zlatanov

Tell ya what, *you* try reimplementing make in Perl. and then come
crying back when it doesn't work right in all cases. :)

I don't think it's fair to ask me to implement a tool when I'm just
asking for information about it. Anyhow, here are two such tools:

http://www.dsmit.com/cons/
http://dapfy.bei.t-online.de/make.pl/

I don't claim that they replace make, I'm just looking for
information on what's available and why it hasn't replaced make.
Make is *hard*,

I don't think it's that hard, as evidenced by the billion make
reimplementations.
and another good reason to use it is that it's already had a few
decades of work behind it, and (if you leave out gmake-specific
extensions) is portable pretty much everywhere.

Right, but the question remains, why use it? For simple (pure Perl)
module installations, running make is absolutely unnecessary. Perl
can do every step of the install. I'm not asking you to show me make
is useful - I know that, I've been using make for a while. I'm asking
why make should be used in the module installation process
specifically, and what tools similar to it with better Perl
integration exist already.

make may be portable, but that doesn't mean it's available,
functional, or accessible. Furthermore, it's a tool external to Perl
and my point was that Perl can do the same job.
As opposed to a brand-new tool that doesn't have that kind of
portability or history or legions of people who know how to use it.

I'm not sure how that's an argument. The horse also had legions of
users, history, and was very well-known before cars came along. For
installing CPAN modules, should it matter to the user whether make is
used or not, as long as the installation works? I'm saying that it
matters if make is broken or unavailable, for instance on Windows.
Perl can do the job by itself.
I went away from clpm for a little while, but I don't recall seeing
these discussions, so I'm not sure what discussion lists are, or
which ones you're referring to.

Perl 5 and 6 mailing lists. I haven't been lurking on those in a
while due to a lack of time, mostly, and I don't have pointers to old
discussions. Sorry.
Such as? Offhand, I can't think of any time I've needed to
integrate Perl and make, other than having the one call the other
(or vice versa).

- installing Perl software (the step Makefile.PL -> Makefile could be
skipped)

- general dependency-driven actions that use Perl syntax inside the
Makefile

- class-based file hierarchies that drive actions when modified

- see the make.pl and Cons pages for more examples

Thanks
Ted
 
E

Eric Schwartz

Ted Zlatanov said:
I don't claim that they replace make, I'm just looking for
information on what's available and why it hasn't replaced make.

I think I explained why make hasn't been replaced. Hope someone gives
you more alternatives.
I don't think it's that hard, as evidenced by the billion make
reimplementations.

Many of which are broken in some way or other.
Right, but the question remains, why use it?

Because it's nigh-universal (it's even easy to get on Windows, with
cygwin and other emulation environments), everybody knows it, and the
old adage, "Standard is better than better".
make may be portable, but that doesn't mean it's available,

Um, where isn't it available? If you can download a perl module, you
can download a copy of make.
functional, or accessible. Furthermore, it's a tool external to Perl
and my point was that Perl can do the same job.

Except that make already does it, and works fine.
I'm saying that it
matters if make is broken or unavailable, for instance on Windows.

Windows has perfectly functional make implementations, at least one of
which is even free.
Perl can do the job by itself.

Sure, but why reinvent the wheel when there's a perfectly good one
available?
- installing Perl software (the step Makefile.PL -> Makefile could be
skipped)

Doesn't require integration. It's a nice WIBNI, but irrelevant.
- general dependency-driven actions that use Perl syntax inside the
Makefile

What's the advantage over using make syntax?
- class-based file hierarchies that drive actions when modified

Either I don't understand what this is, or it's trivially implemented
with a make rule that drives those same actions when a .pm is
modified.
- see the make.pl and Cons pages for more examples

I'll take a look when I get a chance.

-=Eric
 
R

Randal L. Schwartz

Ted> Actually there's quite a few Perl users, myself included, who think a
Ted> Perl-based make would be much better than relying on the standard
Ted> one that may or may not be installed, available, or functioning. For
Ted> modules that require C compilation, maybe. But for pure Perl
Ted> installs? That's silly, given Perl's power.

Ted> This comes up periodically in Perl discussion lists, and usually the
Ted> answer is "just wait for XYZ, it will do this and more." I'm not sure
Ted> what the current XYZ is/are, especially regarding why XYZ hasn't yet
Ted> replaced 'make' in CPAN installs and standard Perl usage. I'm very
Ted> interested in any information, as I have needed tighter integration
Ted> between Perl and 'make' many times.

There already *is* one.

<http://search.cpan.org/author/NI-S/Make-1.00/>

11 April 1999 for the release date.
 
T

Tassilo v. Parseval

Also sprach Ted Zlatanov:
Right, and there's also make.pl and Cons as I mentioned. Thanks for
the info!

Now, my question is why CPAN is still relying on the old-fashioned
external make.

Because it generally works. The whole of CPAN currently consist of
modules which are installed using ExtUtils::MakeMaker. This one produces
a Makefile that does the right thing for all imaginable platforms.
Changing that would surely cause problems for a considerable number of
the many thousand CPAN distributions.

However, there is Module::Build which will sooner or later replace
ExtUtils::MakeMaker. It no longer relies on make but instead produces a
framework that will obey to

perl Build.PL
./Build
./Build test
./Build install

The first line will produce a Perl script 'Build' that contains all the
functionality that was previously specified in Makefile.

Of course, such a change in the build process only makes sense when
other tools can deal with it. For instance, h2xs wont yet create a
module skeleton for Module::Build. I am not sure about CPAN.pm either.
Current release might already be able to deal with those modules, but
older ones certainly aren't.

Tassilo
 
T

Ted Zlatanov

That has nothing to do with CPAN. It's up to each module author to
decide how his/her module gets installed. Most people decide to go
the usual way, which includes the use of a 'make'.

I think most modules (99.99%?) use Makefile.PL, which currently means
having to use `make' but, because of what Perl can do internally,
could be replaced. Let's assume for the moment that `make' is still
useful for compiling modules with C code; I'm talking about pure Perl
modules. For those, "perl Makefile.PL; make; make install" could be
simply "perl Makefile.PL install" or something similar.

Now the question becomes, "why not keep make for everything if it's
still needed for 50% (or whatever portion has C code) of the
modules?" I think you have to start somewhere, and that the
migration to 100% Perl-based Makefile.PL interpretation should be as
easy as possible.
If you don't have a working 'make', install one. If you can't
install software for whatever reason, you can't install a Perl based
make either.

Not if the Perl-based make is a part of the core (like
ExtUtils::MakeMaker). You and Eric are saying it's no big deal to
install `make.' It's not a big deal for experienced users, but at the
very least it's a hassle for new Perl users on the Windows platform.
If you think not using a traditional make is the way to go, please
lobby each individual CPAN module author.

I understand the magnitude of such an undertaking, and am not
proposing modifying all CPAN modules, but rather the interpretation
of Makefile.PL when the module is installed.

Ted
 
T

Ted Zlatanov

Also sprach Ted Zlatanov:

Because it generally works. The whole of CPAN currently consist of
modules which are installed using ExtUtils::MakeMaker. This one
produces a Makefile that does the right thing for all imaginable
platforms. Changing that would surely cause problems for a
considerable number of the many thousand CPAN distributions.

I'm all for stability, but CPAN modules do have tests. It's not too
crazy to modify the CPAN.pm framework and then do regression testing,
is it? If anything, internalizing the Makefile.PL parsing instead of
always relying on an external `make' will make things faster, easier,
and simpler. ExtUtils::MakeMaker is the key here.

The Makefile generated from "perl Makefile.PL" in such a framework
However, there is Module::Build which will sooner or later replace
ExtUtils::MakeMaker. It no longer relies on make but instead
produces a framework that will obey to

perl Build.PL
./Build
./Build test
./Build install

The first line will produce a Perl script 'Build' that contains all
the functionality that was previously specified in Makefile.

That's the fourth alternative to make and second make-replacement CPAN
module mentioned so far (Make being the other one). I hope a clear
winner emerges. My opinion is that the existing Makefile.PL has to be
migrated or interpreted seamlessly for CPAN installs, so replacing
ExtUtils::MakeMaker is harder than extending it given the number of
modules and authors.
Of course, such a change in the build process only makes sense when
other tools can deal with it. For instance, h2xs wont yet create a
module skeleton for Module::Build. I am not sure about CPAN.pm
either. Current release might already be able to deal with those
modules, but older ones certainly aren't.

There's also the documentation written, volumes and volumes of it in
soft- and hardcopy, that would have to be modified. I'd rather see
the existing Makefile.PL parsed than a new system replacing it.

Ted
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,431
Messages
2,571,677
Members
48,796
Latest member
Greg L.

Latest Threads

Top