[ copies to nobody: all this copying is probably unnecessary and i am not
sure why so many individuals on this List do it ]
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]
> > Behalf Of Soren Andersen
> > [ copies to: Joe Schell <[EMAIL PROTECTED]> ]
> > 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]
> > > I run CPAN. My configuration...
> > > -MSC version 5.0
> > > -I built Perl from the CPAN source (not a AS build)
> > > -I use 4NT as my shell, which perhaps does more than the
> > regular Win command
> > > shell but it certainly isn't a unix shell.
> > It does far more.
I meant that the NT shell does far more than the Win9x shell does, I
misread the "4NT" part (it's something I don't know about, I have heard of
"4DOS". i don't need to know about it, BTW.).
> > > I suspect that it is only the last part of the above the
> > > determines whether > > CPAN works or not
> That's an incorrect suspicion. It's mainly
> the _first_ part: you have the M$ C /C++ compiler (in order to build
> XS modules), and that's what makes the difference. Why would you assume
> that everyone has M$C? Or wants to?
> My assumption is that anyone who is going to venture into the 'build your
> own' area should have an idea that they are going to need a compiler.
Joe, for some reason there is still misunderstanding, + lack of
comprehension of my meaning here. I spelled it out very clearly I thought.
Why do you assume that other people have MICROSOFT'S C COMPILER
installed? Are you really _still_ that much monoculturally in the M$
orientation towards computing even after 6 months on this List?
> Naturally if they do a build from the source, then they must already have
> a compiler. And back to thread that I was responding to, I would guess
> that even if CPAN was made more windows friendly it would still need a
> compiler.
There are compilers other than M$, but AS perl is built with M$ compiler.
Since you haven't (apparently) ever used another compiler and apparently
don't have a notion that one even exists, it might be self evident to many
people reading this that while there's nothing wrong with optimistic
speculations per se, and I don't mean to seem to be coming down hard or
anything (after all I don't care, but I mind a little bit being made to repeat
myself in a way that makes me look obnoxious, argumentative and
contentious), but Joe, if you haven't actually *done* this all you should
probably allow for the probability that there is FAR more to it than you are
aware of. And that in fact is the case -- there is far more to it. The devil is in
the details.
> > > I can't really see that it matters that the build is AS or not.
> > That's because you haven't looked at it in detail, try the
> > Perl-Win32-Porters List for more info. I am not going to be detailing
>point-by-point
> > the reasons in this response because I am moving a large part of my household
> > possessions later this week and there isn't time to go into it. I can only
> > drop clues:
> > "PERL_OBJECT".
>
> I have been been on that list for about six months. I can't recall that
> specific issue being raised.
What you do then is go use the search facility on Lyris, the Web interface to
this list.
> Do you have a specific reference?
No. Lyris. *** <-- CLUE
> PERL_OBJECT is a build option for perl. It is defined in my build.
Yes, and you used M$C/C++.
> It looks like any C module built by me will have that defined.
Yes. Exactly.
> Is it not defined in the AS build?
It IS defined in the AS build. That is precisely the problem. Other compilers
don't support it and you might have understood that this is the point
(instead of the inverse understanding you seem to be working from) if you
had both really more carefully read what came before this point in my
response as well as particularly the latter portion below of my previous
response. *If one >>_doesn't_<< own M$C++ one cannot build xs modules
on to AS Perl before 5.6.*
Should AS undertake to do something that can only benefit those of the
ActivePerl users who have paid Bill for M$VC++? I don't know, that's for
them to say. I am not interested, it has nothing to do with me or anything I
want to see achieved. I am interested in Free Software, not M$ enrichment.
I hazard to say because there seems like a major culture or comprehension
gap possibly here, that I speak not only for myself here but (I know it to be
an objective fact) for quite a lot of others.
> How would that affect using CPAN? I suppose it
> is possible modules might not build but wouldn't that be a module problem?
No, see above.
> Perhaps for this single point you could explain the problem more fully?
No.
*** Perl-Win32-Porters. *** <--- CLUE
> > I also wonder this, Joe: Do you have _every_ functionality in your home-
> > brewed Win32 Perl that AS Perl does? Are you sure? What exact version of
> > Perl did you build?
> I can't be sure. My version is 5.005_03. I built is using the source
> from CPAN, not the AS source. There are differences as AS incorporates
> bug fixes in the core and the modules that come with the core.
Exactly.
> CPAN and AS source are never in sync. Just as the AS PPM modules are
> never in sync with the CPAN.
> But you have lost me.
Sorry, it wasn't intentional.
> What does this have to do with the requirements for
> running the CPAN module?
*** Perl-Win32-Porters *** <-- CLUE ;-)
> > What would be really good would be if a Win32 Perl comparable in
> > non-broken-
> > ness to AS Perl could be built with any non-proprietary Free
> > Software compiler
> > as an alternative to MSC/C++. It certainly has been done with
> > Cygwin gnu gcc
> > and Perl 5.005, but it eludes those who want to build _AS_ Perl
> > from source
> > with that or with it's less encumbered, fully native, growing
> > cousin minGW
> > (www.mingw.org). Perl 5.6 (AS build 613 based on that) in theory
> > can be built
> > on something other than M$C/C++ from source, the 'Porters could
> > inform those
> > who want to know how that is going for people. AS Perl 5.005 _cannot_ be
> > built other than on M$C/C++. As a result modules that require
> > compilation of source into object code cannot be built for AS Perl 5.005
> > except with M$. **The compiler used to build the module for any given
> > Perl installation must be the same as is listed in Config.pm as the
> > compiler that built Perl core.**
>
>
> I don't think that problem is related to using a Microsoft compiler. The
> Perl core is written in C/C++. A C compiler must be able to provide
> allocation and de-allocation of memory. To do memory handling on any
> operating system certain assumptions must be made. And so unless the
> developer is very careful two compiled modules from different compilers
> can not be linked together. This can even be the case between different
> versions of the same compiler. Other differences can also appear, such as
> in stack handling of function parameters and how printf() does its job.
>
> Has that not been your experience?
>
>
> >
> > It might be helpful to people if someone who has used a non-M$C/C++ cc
> > posted / made available their Config.pm so that those who wish to
> > emulate what I did with hair-raising trial-and-error (manually editing
> > my Config.pm) in order to get CPAN.pm to work (sort of) could have more
> > clues about what they might want to have in there. Some experts have
> > found that suggestion unsound when I have made it in the past, but I (at
> > least vaguely) know what sort of witchcraft I had to employ to get CPAN
> > working, and it would have helped to compare someone's non-AS Win32 Perl
> > Config.pm and AS Win32 Perl 5.005 Config.pm side-by-side. It would have
> > given me some place to start. It might give a cooperative project to
> > streamline this some place to start. I posted asking someone to do this
> > when I was undertaking it at that time but nobody responded by doing so;
> > however that was when I was informed by an expert respondent that
> > Config.pm wasn't the ultimate stumbling block for Perl 5.005, rather the
> > cc system was. This has changed with the new AS Win32Perl.
Cheers,
soren andersen
-
"Everything that I've learned about computers at MIT I have boiled down into three
principles:
- Unix: You think it won't work, but if you find the right wizard, he can make it
work.
- Macintosh: You think it will work, but it won't.
- PC/Windows: You think it won't work, and it won't."
-- Philip Greenspun
---
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]
