On 10 May 00, an entity purporting to be Joe Schell [Joe Schell
<[EMAIL PROTECTED]>] wrote [regarding RE: Suggestion: put CPAN
module on ActiveState PP]
> So many issues so little time.
Indeed.
> > Behalf Of Soren Andersen
> Yes I am aware of other compilers. My first attempt to build perl 4 was
> with Borland 3.1 on a DOS 3.1 machine. Not very successful but it was
> interesting. I have used various others including gnu gcc (although not
> on Windows.)
> Now when I attempted that first perl build, Borland had about 90% of the
> C++ market and perhaps 40% of the C market. I suspect the currently
> Microsoft has more than 90% of the market for both compilers.
90% of WHAT market?! Not, for sure, of the market for compilation of all
the non-Windoze programs that are being built out there.
But yeah, Borland, it's my impression, is a fading into the past thing. it
seemed once to be dominant enough but now seems more and more just a
bit obsoleted and being forgotten.
> consider it reasonable that a module writer writes modules using MS VC and
> doesn't even bother testing with other compilers. Since most of it is
> volunteer time it seems even more reasonable to me.
Joe, in the Perl world, UNI* is dominant. The vast vast majority of Perl
modules are NOT written by volunteers using their MS VC but by
volunteers who are not developing the module on Windows _at all_. You
are supposing a dominance that just doesn't exist. The only place in the Perl
world that MS VC is dominant and matters is right here in this little corner
of it where people have been developing the Win32 port of Perl, that is, AS.
The ONLY place.
Nowadays that means that (to really make a wild guess) maybe 80% or
better of the modules are being authored by people on Linux boxes or
maybe running FreeBSD; with various sorts of proprietary UNIXen making
up whatever 10-20% error might be in my statement. NONE of them are
using MS VC.
> I would like to point out here that I thought the point that I was
> originally responding to was the requirements needed for the CPAN module.
> However, most of the rest of the comments (which I deleted for efficiency)
> seem to be directed at the fact that MS VC compiler seems to be needed to
> build the modules.
You did get the point, below, however. There isn't as much point in CPAN
unless those very popular modules that aren't being supplied by AS in PPM
form but do require compilation, can be compiled as part of the build
process inside CPAN. Yeah, there are a lot of modules that don't require
compilation. OK. But that means that if this was done it's a half-broken (or
half-functional) CPAN.pm and that isn't so attractive. Your semantic
distinction between other pieces needed "by CPAN" and the compiler itself
seems rather arbitrary to me. The cc *is just as much a part of what CPAN
does as is tar or FTP*. Otherwise after all this hot air (well ... torrid
keystrokes)? we've used on this topic, why not just go and *download* the
module archives one wants and install them manually?
> -I was under the impression that the core perl does build with gnu gcc and
> I believe several other compilers. Correct?
Yes. Non-AS Perl ("core Perl") from the CPAN place its always found in.
> -And the CPAN module is entirely built using perl. Correct?
This is where I am confused about what you are saying CPAN.pm is or
does. Yes, its all Perl, and no, it doesn't have much point to its existence all
by itself! It's part of a complex Rube-Goldberg contraption that on briefest
close examniation shows its basic UNI* assumptions, a networked
interactive system of module code retreival, expansion, compilation
(possibly) and testing finally followed by installation of various parts of the
module including documentation and binary libraries.
> -So given the above I suspect that the CPAN module can be installed using
> another compiler. But, it seems to be your point, that that wouldn't be
> worthwhile because very few if any of the extra modules will actually
> build without MS VC. Does that sound about right?
CPAN would work FINE in a Perl BUILT with another cc from the start.
BUT it wouldn't be AS Perl and that's where and why I asked you about
your Perl. AS source is NOT the same as the core Perl generic source on
CPAN; as you yourself pointed out; and you don't actually know, to
paraphrase you, what if anything you don't have working that AS people got
working. Yes, its Perl, so AS is actually bound to release the source code,
but that doesn't mean that *Perl built from different (non-AS) source is
exactly functionally the same as Perl built from AS source.* Does it? How
could that be? I am just asking questions here (and I am not the only one,
again in a display of synchronicity i noticed a thread titled with this subject
in a perl newsgroup this week).
> If that is your point then I surely wouldn't disagree with you. But that
> doesn't have anything to do with the CPAN module.
It has EVERYTHING to do with the CPAN module! The discussion point
raised was "Wouldn't it be great if Active State got CPAN up on PPM"?
What would be _the point_ of them doing that if it won't actually WORK
with their product (ActivePerl)??? And it WON'T except and unless the
user has *compiled A-Perl themselves [!!!!!!!!!]* from source, not
downloaded it as a binary like most users do! And until now most _nobody_
has built A-Perl using anything _but_ M$ VC. (And I am not going to ever
use M$ VC, period).
I know it seems like we're going around and around here (and I must stop
now with this message, I won't respond further -- not because I've lost
patience or am pissed off but because it isn't creating value anymore, we've
used up the topic, and because I don't have the time).
What all this means is that there is (again, from the standpoint of what I
remember <LOL> to have been the _original_ topic) very very little point
in AS putting CPAN up on PPM or something like that. That is to say, it's
already there as a part of Perl, if someone can make it work, go for it, but
the pieces that aren't in place to actually make it work like it does for
someone using a UNI*-like OS are too various to make this a reasonable
thing. For what tiny tiny minority or users is this going to be done? Who
benefits?
> Instead the problem
> lies with those additional modules that have made assumptions about how
> they will be built.
You can go tell the UNI* world that. Now you get a hint what's discussed on
the minGW (gnu for Win32) List. You will discover that your tremendous
cries of protest fall on quite deaf ears -- especially if you make statements
like (that suggest that) "M$ VC is the only compiler to use". And
REMEMBER, Perl _comes out of the UNI* WORLD.
> My personal view is that I will continue to use MS VC because it owns so
> much of the market and I will continue to work with windows.
My personal view is I will continue to support gnu because M$ owns so
much of the (PC) market and it's Cathedral-paradigm software with anti-
social licensing contracts attached to it. My conviction is that more and
more great software and entire innovative, superbly refined and debugged
systems will come into the spotlight with a background heritage of Free
Software (Open Source) behind them, and M$ and their mostly horrible
bloated half-finished compromised software engineering will slowly but
surely glide down into the depths of secondariness, followed eventually by
obscurity. We have a bit of an assumption-and-paradigm conflict, you and I
:-).
> And it would
> seem reasonable to me that anyone else who wants to work in windows should
> assume that they are going to need MS VC.
Totally disagree with that statement of reasonableness regarding that
assumption, especially since:
1) There is absolutely no one forcing anyone at gunpoint to CHOOSE
between one or the other. Not even financial considerations, since the
minGW is free (lowercase, as in free of charge) and Free (as in Open Source
or CopyLefted).
2) I work in the PERL world. I need Perl .. I use Windows .. but I LOVE
Perl. I do not _need_ M$VC to write even xs modules, all I need is my own
ambition and creativity and determination. Which is part of what the
Romance of Perl is about.
> If for no other reason than
> because the other compilers probably won't keep up with the newest things
> in windows.
"The newest things in Windows ... " what, like DDE? Oh well, I am really
going to start badgering now ;-), i better quit here. You have never used
minGW, most of the readers of this List are not aware how far its come in
the last 18 months, so i know it's just a matter of unfamiliarity and out of
date information and erronious assumptions. Even 2 years or so ago gcc, a
highly optimizing truly great compiler, could spit out compiled 'doze bytes
that could run faster than those chugged out by M$ VC in certain cases. You
know, assumptions can KILL you if you make too much of a habit of them ...
soren andersen
www.mingw.org ** <<--HINT!
---
You are currently subscribed to perl-win32-users as: [archive@jab.org]
To unsubscribe, forward this message to
[EMAIL PROTECTED]
For non-automated Mailing List support, send email to
[EMAIL PROTECTED]
