> 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]
>
> Joe is, to put it bluntly, wrong (under-informed) on nearly every
> count --
> sorry!
It could be that many of my guesses are wrong. But I do have further
comments below.
>
> > am guessing that the intent of your message is that CPAN will not work
> > with a normal windows configuration?
>
> Nothing to do with normal Windoze whatever that is, so much as certainly
> won't work (as has been amply proven to their own satisfaction by
> all those
> who've gotten curious or fed up with waiting for PPM and tried
> ..) with AS
> Perls and 'doze _alone_, unaltered.
>
> The key certainly is in the Configuration, capital "C", as in _Config.pm_.
>
> > 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.
Whoops, I forgot. I support two CPAN perl builds. I built the second using
the NT shell (I wanted to make sure 4NT didn't polute it since others who
don't use 4NT would be using that perl.) So the standard NT shell works.
Although I strongly suspect that building on Win 95 might be a problem.
>
> > -I have some unix clone tools in my path.
> They alone will not make a fully operational CPAN possible.
Perhaps but it certainly helps. When the CPAN module asks mosts of its
questions I can just take the default.
>
> > 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.
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.
>
> > 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. Do you have a specific reference?
PERL_OBJECT is a build option for perl. It is defined in my build. It
looks like any C module built by me will have that defined. Is it not
defined in the AS build? How would that affect using CPAN? I suppose it is
possible modules might not build but wouldn't that be a module problem?
Perhaps for this single point you could explain the problem more fully?
>
> 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. So the 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. What does this have to do with the requirements for
running the CPAN module?
> 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.
>
> Regards,
> soren andersen
>
>
> ---
> You are currently subscribed to perl-win32-users as: [EMAIL PROTECTED]
> To unsubscribe, forward this message to
> [EMAIL PROTECTED]
> For non-automated Mailing List support, send email to
> [EMAIL PROTECTED]
>
---
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]
