Strawberry and Vanilla Perl

[Anthony N]

Can somebody clarify this for me? Strawberry Perl is a Windows distribution
of Perl, and Vanilla Perl is a Windows distribution of Perl for building
one's own Windows Perl distribution, could somebody tell me if I'm right or
not. If not then can you explain to me? Thank you!

 

[sisyphus]

This differs from ActiveState's perl in
that AS (a) apply quite a few patches to their perl before distributing
it, (b) don't supply a compiler

They don't provide a compiler, but 'ppm install MinGW' will provide
you with the MinGW port of gcc, along with the 'dmake' make utility -
no additional configuration required.

And a compiler compatible with ActivePerl is not cheap

The MinGW port of the gcc compiler is both compatible with ActivePerl
and free.

though AS do include a somewhat half-
    hearted hack to try and make it work with gcc if you've got that
    installed.

That "half-hearted hack" means that *any* perl extension that builds
on Strawberry Perl, can also be built in exactly the same way on
ActivePerl, using the MinGW port of the gcc compiler. (You could even
set things up to use Strawberry Perl's MinGW with ActivePerl if you
wanted.)
If you 'ppm install MinGW' (rather than use Strawberry's MinGW),
you'll even be able to build some extensions (eg PGPLOT and various
PDL components) on ActivePerl that can't be built on Strawberry Perl -
because the MinGW that you 'ppm install' includes the g77 fortran
compiler, whereas the MinGW that ships with Strawberry Perl does not.
(At least, it didn't last time I checked - apologies if this omission
has since been rectified.)

Cheers,
Rob

 

[sisyphus]

Try installing Perl.pm. At least last time I tried, their %Config
override didn't override enough, and it ended up passing MSVC switches
to GCC.

No problems with that module for me on ActivePerl/MinGW/dmake.

Yes, I am a little annoyed here . I spent rather more time than I
would have liked trying to figure out what on Earth was going on, and
why some people seemed to have an ActivePerl that kind-of worked with
GCC whereas mine absolutely didn't (I have MSVC6, and it was in my
PATH).

I think it's the inclusion of MSVC6 in the path that's the problem.
This (from the ActivePerl::Config documentation) is probably all you
needed to see:

$Config{make}
This will be "nmake" by default, but if no nmake program can be
found and other compatible make programs are found, then this
value
will reflect that. Currently dmake is the only other make
implementation that is compatible enough to build perl extensions.

$Config{cc}, $Config{ccflags},...
The value of $Config{cc} will be "cl" by default, but if no "cl"
program can be found and gcc is found, then this value is "gcc"
and
other values related to the compiler environment is adjusted
accordingly.

The ACTIVEPERL_CONFIG_CC environment variable can be set to "gcc"
to
use "gcc" even when "cl" is found.

I've just checked that adding MSVC6 to the end of the path is a
showstopper (wrt MinGW) - and it is.
And setting ACTIVEPERL_CONFIG_CC to gcc, does override MSVC6 as
advertised - though you still have to use 'nmake' as your make
utility. (I initially assumed that I would then use 'dmake' - but
there's nothing in the documentation to support that assumption

The other thing that should be mentioned is that you have to be using
a recent release of ActivePerl (anything from the last year, maybe
even last 2 years) for this to work reliably. There were some bugs in
the early attempts to get the alternative Config set up correctly.
Even now there is still the potential for problems to arise - $Config
{incpath} and $Config{libpth} are not being overridden when gcc is in
use. (I've recently submitted a bugzilla report for this. Hopefully,
it will be addressed in the future.)

I don't know. I presume you've reported this in the appropriate place
(which appears to be the Perl-Dist-Strawberry RT queue, AFAICS)? It
seems like a trivial thing to fix, if it's causing real problems.

Yes - I reported it to a Strawberry Perl wiki (which was the
appropriate place at the time). I think Adam felt that it wasn't
"causing real problems", which I'm not going to argue with - given
that no-one else has ever complained about it.

Cheers,
Rob

 

[sisyphus]

AFAIC ActiveState took something that worked perfectly well on any
standard build of Perl, and broke it, and that's Not Fair .

Yes - that *would* be annoying. I use ActivePerl on a regular basis
(though not exclusively), so moving with the changes was a fairly
painless experience for me.

This is all from longer ago than last year, so it's possible that some
of the bugs I came across have been fixed.

I would go so far as to say that *all* of the bugs you came across
have been fixed. At least, PerlInterp-0.05 is definitely building/
testing fine for me on ActivePerls 5.8.9 and 5.10.0, with MinGW.
(Build 820 of perl 5.8 is the last build of ActivePerl to have had any
of these Config bugs in it, afaik. Build 826 is the latest build.
These bugs were fixed before 5.10 was released.)

I never did understand why
they left half of %Config untouched: simply including a *complete*
Config.pm for gcc *must* be easier, no?

I don't know. ExtUtils::FakeConfig does the same thing. Maybe it's
just a case of doing no more than is necessary. There's nothing to be
gained by overriding existing values with the exact same values.
And, as I understand it, there's more to it than just providing an
alternative Config.pm - you then have to get those altered values into
%Config, and that's why we see, in FakeConfig.pm:


sub import {
shift;
my $obj = tied %Config::Config;
my $key;

while( $key = shift ) {
$obj->{$key} = shift;
}
}

(ActiveState is doing precisely the same thing as EU::FC, but in a
more automated way.)

I do realise that at this point I'm being somewhat petulant .

Petulance is a feeling I know well ;-)

Cheers,
Rob