Well, I'd really like to try out Strawberry Perl, but the installer doesn't give me any options about where to install it. It doesn't even tell me where. Since the only Win32 box I use is for customer work and requires me to maintain a functional ActivePerl install, I won't install Strawberry unless and until that changes.

I love the idea, and if it works it might replace ActivePerl for Win32 projects of mine in the near future (when it's out of alpha, and the installer is fixed).

Everything is installed under "c:\strawberry-perl". Right now, directories are hard-coded at compile time, so users can't be given the option for where to install it. Soon, Perl will support a "relocatable @INC" with relative paths. See "Poll: Is your $^X an absolute path?" for some discussion.

There's been a request or two for a version of Strawberry that gets installed to "c:\perl" to seamlessly replace ActiveState installs, but I'd rather wait for 5.8.9 and let people install it wherever they want.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

That's very good to know. I get that this is alpha software, and that there are good reasons not to be able to choose installation paths right now; however, I'd still suggest that in your next release you tweak the installer to tell me "Ready to install into C:\Strawberry-Perl" or some such.

Having now installed and played with it a bit, I noted one other thing that made me glad I'm so careful with pre-release software: even when running Strawberry Perl's perl.exe, my $ENV{PERL5LIB} is "C:\Program Files\ActiveState Perl Dev Kit 6.0\lib\". Fortunately, I didn't put Strawberry Perl in my path by default, but launch it from a Windows .CMD file, so was able to fix the issue:

@ECHO OFF
REM sperl.cmd - use Strawberry Perl for this session

C:\strawberry-perl\perl\bin\perl -x -S "%0" %*
goto ENDOFPERL
#!perl
#line 6

$basePath="C:\\strawberry-perl\\perl";
local $ENV{Path}="$basePath\\bin;".$ENV{Path};
local $ENV{PERL5LIB}="$basePath\\lib";

system($^X, @ARGV);
__END__
:ENDOFPERL
[download]

This is simple, and works on my system; I'm not sure it would work for everyone else. (And yes, I know that this isn't fixable, really, on your end -- ActiveState sets that env. var. during their install process.)

<–radiant.matrix–>
A collection of thoughts and links from the minds of geeks
The Code that can be seen is not the true Code
I haven't found a problem yet that can't be solved by a well-placed trebuchet

This is great news. We're really looking for win32 testers. I am by no means the expert on how to set things up for CPAN smoking, though. Ideally, you should log on to irc.perl.org, join the #win32 channel and ask "chorny" (Alexandr Ciornii). He has contributed a huge amount of test results and corresponding RT tickets.

Steffen

Wrote first version of CPAN smoke tutorial. As it is wiki based, I will develop it further. Please ask questions there or by e-mail.

I don't really use it (I'm hardly ever on Windows) but I did download it, install it, installed a few modules from CPAN and ran a few programs. Everything went smoothly just as it does on my linux box. As someone who has used ActivePerl before, this came as a great surprise ;-)

Many good questions.

I already have MinGW and dmake. Will installing Strawberry Perl have any impact on those existing MinGW and dmake installations ?

Sadly, yes, maybe. Again, it's path dependent. I suspect that you could install Strawberry, and delete "c:\strawberry-perl\mingw" and "c:\strawberry-perl\dmake" and those directories from your PATH and it would work OK. Long term -- optional installation of those is probably a good thing. It's more backlog for the installer work queue, I guess.

Does Strawberry perl come with a ppm utility?

No. Strawberry Perl only comes with Perl modules on CPAN. If ActiveState ever makes PPM non-proprietary, perhaps it could be considered. In the meantime, external libraries are a problem and various options are being explored. (cf. RFC: Portable Alien Library System)

I see that GNU make is part of the Strawberry distro. Why is it provided?

Some external libraries want it instead of dmake or nmake. Notably, Alien::wxWidgets uses it. Given the special name for it ("mingw32-make"), it's not likely to be invoked by accident.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

There is a PPM package on CPAN that could be used. However, this is quite old (version 2), and for people especially getting used to the ppm gui of the current ActivePerl, may take some getting used to with the different syntax.

At this point I can't lose the the "known good" distro, activestate, that I have installed as I could lose development time.

If the installer was updated to the ability to change install location, if I could leave current perl in place and install this as a secondary, I would be more than willing to isntall and use!

At this point I can't lose the the "known good" distro, activestate, that I have installed

To be very clear, Vanilla/Strawberry Perl do not install over the top of ActiveState. They install in their own, separate directories at the root of the "C" drive. The proper paths are added at the end of the PATH environment variable. Which Perl runs when you type "perl" at the command line will be based on the first perl.exe found in the path, which should continue to be ActiveState. Moreover, no file associations are changed.

So, while I make no promises, I suspect that Strawberry Perl can live peacefully alongside ActiveState if you want to try it out. Just run it explicitly with the full path, like so:

> \strawberry-perl\perl\bin\perl.exe -V
[download]

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

xdg

Thanks for the clarification... will have to try it out!

My sig Sucks!