in reply to Are you using Vanilla/Strawberry Perl? Tell me about it!

Haven't yet tried it - and probably won't until it gives me a choice of install locations. I would also like to see an option to not have the path altered in any way. I have some questions (which don't really belong in this thread ... but I'll ask them anyway :-)

I already have MinGW and dmake. Will installing Strawberry Perl have any impact on those existing MinGW and dmake installations ? (The option I'd prefer is to install Strawberry Perl, but not MinGW and dmake - and have Strawberry Perl use those pre-existing MinGW and dmake installations.)

Does Strawberry perl come with a ppm utility ? There are times when that can be damned handy. For example, if you want to install a module (such as GD) that needs a C library, you first have to build (or otherwise acquire) the requisite C library - or you can just 'ppm install' the module and save yourself the hassle of chasing up the C library. There's a lot of ppm's out there and it would be good if Strawberry Perl at least provided us with the option of grabbing them.

I see that GNU make is part of the Strawberry distro. Why is it provided ? (No big deal about this ... I'm merely curious.)

Cheers,
Rob
  • Comment on Re: Are you using Vanilla/Strawberry Perl? Tell me about it!

Replies are listed 'Best First'.
Re^2: Are you using Vanilla/Strawberry Perl? Tell me about it!
by xdg (Monsignor) on Oct 03, 2006 at 01:42 UTC

    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.

[reply]
      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.
[reply]
        There is a PPM package on CPAN that could be used. However, this is quite old (version 2)...

        I just gave that a try on my MinGW-built perl 5.8.8. Things like 'ppm help' and the various 'ppm set' commands work fine. And the interactive shell is available and functional ... but: 
        D:\comp58_M\PPM-2.1.7>ppm install Math::FFT
Installing package 'Math-FFT'...
Element 'IMPLEMENTATION' cannot contain a child element 'PROVIDE' at D
+:/perl58_M/site/5.8.8/lib/PPM.pm line 1658.
Can't locate object method "rvalidate" via package "PPM::XML::PPD::PRO
+VIDE" at D:/perl58_M/site/5.8.8/lib/PPM/XML/ValidatingElement.pm line
+ 38.

        [download]

        I guess that's something that's in the ppd file (since "PROVIDE" does not occur anywhere in the PPM-2.1.7 source). I'd take a look if I could remember just where the hell they hide their ppd files. Somebody gave me the link a while back, but I'm damned if I can now find it.

        That was actually a good, simple, easy-to-use version of ppm. (I now recall that I've used it before.) But if they've taken to writing ppd files that it can't handle, then it's not much use .....

        I think it will work ok with the uwinnipeg repository, as (all of ?) the ppd files there don't contain a "PROVIDE" child element in the "IMPLEMENTATION" element. I was about to test that out, when the uwinnipeg site apparently went down. (Hope it wasn't something I did :-)

        Cheers,
        Rob

        Update:
        I must be drunker than I thought. I finally found the ActiveState ppd files at http://ppm.activestate.com/PPMPackages/5.8-windows/ and, sure enough, the "IMPLEMENTATION" element includes a "PROVIDE NAME" child element (which I took to be the cause of the problem). I'm still unable to get to the ppd files at the uwinnipeg repository, but I was able to get to the bribes repository, so I (successfully) installed a ppm from there. Specifically, I (succesfully) ran:

        ppm install http://www.bribes.org/perl/ppm/Digest-Whirlpool.ppd

        That proves that it's the AS ppd files that are the cause of the problem ... right ??
        Nope ... I also tried:

        ppm install http://www.bribes.org/perl/ppm/DateTime.ppd

        but that produced a heap of warnings about the child element "PROVIDE", followed by the same fatal error that I got from the AS ppd files. Thing is, that if you go to http://www.bribes.org/perl/ppm/DateTime.ppd and view the source of that page, you'll plainly see that the string "PROVIDE" does not occur at all. At this point I'm unsure as to whether I need to drink more, or drink less. All I really know for sure is that I'm bloody glad I don't have to rely on PPM.
[reply]
[d/l]

In Section Meditations