Anyway, is Strawberry Perl compatible with ActivePerl? Is it possible to use compiled modules from AcrivePerl in Strawberry Perl? If so, then the addition of PPM would be useful, as in this case there would exist usable PPM repositories.

And for g77, maybe this could be added in the planned Chocolate Perl distribution.

I added the CPAN version of PPM to Strawberry Perl - this required XML-Parser and SOAP-Lite, both of which installed successfully. For XML-Parser, I used a version of the expat library compiled with VC++ 6. A small patch:

--- PPM.pm.orig    2007-12-29 18:00:03.234375000 -0600
+++ PPM.pm    2007-12-29 17:59:58.218750000 -0600
@@ -113,8 +113,10 @@
 
 # add -5.d to archname for Perl >= 5.8 
 my $varchname = $Config{archname};
-if (length($^V) && ord(substr($^V,1)) >= 8) {
-    $varchname .= sprintf("-%d.%d", ord($^V), ord(substr($^V,1)));
+if ($] >= 5.008) {
+    my $vstring = sprintf "%vd", $^V;
+    $vstring =~ s/\.\d+$//;
+    $varchname .= "-$vstring";
 }
 
 #
[download]

was needed for PPM.pm to get it to correctly append "-5.10" to the architecture string MSWin32-x86-multi-thread. I then installed via the ppm client the GD ppm package from the UWinnipeg Perl 5.10 repository, which worked fine.

Update: If anyone wants to try this out, I've placed an archive of the files needed for installing ppm up at http://theoryx5.uwinnipeg.ca/strawberry-perl-ppm.tar.gz; to install this, save it to the C:\strawberry directory and unpack it there. You may have to edit C:\strawberry\perl\site\lib\ppm.xml to change at least the value of BUILDDIR, indicating the temporary directory which ppm uses to build things. There's a command-line utility, ppm, supplied; type help within the ppm shell to get a list of available options.

Thanks for that randyk. There's also a patch at PPM can't handle zip files that enables that CPAN version of PPM to handle binaries that have been packed in the zip format as well as in the tar.gz format. (The trouchelle rep uses the zip format.)

That patch does the trick for me, but it's probably not well tested.

Cheers,
Rob

For anyone using Module::Build (v0.30) to build PPM's for distribution, here's a simple fix (no patching involved) that you can put into your custom build code (add this to your custom builder code in your Build.PL file):


##BUGBYPASS: [for Module::Build v0.3 and perl v5.10+ $^V version strin
+g change] repairs incorrect version interpretation for perl v5.10+ (s
+till works for 5.8 and earlier, as well)
sub my_varchname {  # Copied from PPMMaker.pm
      my ($self, $config) = @_;
      my $varchname = $config->{archname};
      # Append "-5.8" to architecture name for Perl 5.8 and later
      #if (defined($^V) && ord(substr($^V,1)) >= 8) {
      #$varchname .= sprintf("-%d.%d", ord($^V), ord(substr($^V,1)));
    #}
    ## BUGFIX: send to Module::Build::PPMMaker and PPM
    if (defined($^V)) {
        my @v = split(/\./, sprintf(qq{%vd},$^V));
        if ($v[1] >= 8) {
              $varchname .= '-'.$v[0].'.'.$v[1];
              }
              }
    return $varchname;
}
[download]

It bypasses the BUG until it's fixed in Module::Build.

cpan.bat has been flagged as an issue before. See #21864: Explicit path in cpan.bat.

While I'm not sure exactly how we can save you from having similarly named tools in different parts of your PATH, please add your suggestion to the RT queue.

Added a few remarks to the RT queue

(Strawberry Perl)++ ! Getting further and further. I also suggest to (sym)link/copy dmake to nmake and make and bundle Tk, as it cannot be installed with cpan, as make requires the extra argument "MSWin32" to succeed.


Enjoy, Have FUN! H.Merijn

Please don't link/copy dmake to nmake. Just because I install Strawberry Perl doesn't mean I don't have other Perls or other things that use nmake. It seems a very bad idea to potentially break things that actually want/need nmake in a way that will likely be quite confusing to diagnose.

- tye        

What's wrong with Tk? I think it should build fine with Strawberry Perl, at least there's one PASS at cpan testers.

Lack of platform-detection sounds like a bug in the Tk Makefile.PL. It's not any concern of Strawberry's