g77 was brought up in the past, but it just fell off the todo list. Alias is the Strawberry pumpking right now -- as soon as he gets newly refactored build tools updated on CPAN and documented, it should be easy to patch in g77.

I believe all the code is in Alias' open repository -- so contributing should be easy: http://svn.ali.as/cpan/trunk/Perl-Dist/

PPM is more of a philosophical issue, I think. The version of PPM on CPAN is way out of date, I believe. Also, since much of the impetus for Vanilla and Strawberry in the first place was frustrations with the limitations of PPM, it hasn't been a priority for any of the developers. For a recent view, see Alias' post on use.perl.org, ActivePerl PPM repository design flaw goes critical.

I also want to add that syphilis has provided excellent feedback and suggestions throughout our work on Vanilla and Strawberry. I heartily welcome it and appreciate his continued interest!

-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.

The version of PPM on CPAN is way out of date, I believe

It's certainly well behind in terms of features when compared to the version that ships with ActivePerl. But it's still such a handy thing to have at one's disposal - and it's the first thing I'll be installing on my 5.10 Strawberry Perl.

Sometimes I'm in the middle of something and I find I need a module - and it's a module that doesn't build easily. The last thing I want to be doing is heading off on a tangent trying to get that module to build, when I could quickly and easily ppm install it - and get back to the actual task at hand. It's in those types of situations that one really appreciates ppm.

Cheers,
Rob

Update: I've just installed ppm using the tarball that randyk provided - then reset BUILDDIR as per his suggestion by running  ppm set build C:\Users\Rob\AppData\Local\Temp

All works fine.

I think you should make a distinction between the current problems of a (popular) PPM repository and the PPM system as is (a distribution system for binary packages). Such systems may be very successful, think of Debian's dpkg/apt system.

Personally, I find the approach taken by *BSD most appealing: there's a system for binary packages (just called "packages" in FreeBSD) and a system for building from source ("ports" in FreeBSD). Both are connected: a "package" is built using a build file from the "ports". One would use the source path if the binary package is not available (for whatever reason, including legal reasons), or if one needs a specific configuration, or if a newer version exists which is not yet available as a binary package.

Translating this into perl's world:

• "package" = ppm
• "ports" = CPAN.pm

PPM was written by Activestate for their distribution of Perl. Are you sure that there are no licensing restrictions concerning its redistribution with other (non-Activestate) distributions?

As for a Fortran compiler... I can't imagine more than a few percent of Win32 Perl users requiring one. So for a broad majority of users, that will be unnecessary bloat, in a package that is already quite large.

Adam has put a fair amount of work into the build chain for Strawberry Perl, which opens up the possibility for you to create and distribute a Perl-Fortran distribution. You could call it Punched Card Perl (the initials can be read on two levels :)

Regarding Vista, for Strawberry Perl 5.8.8, Cosimo Streppone found that adding "c:\strawberry-perl\mingw\libexec\gcc\mingw32\3.4.5" to the PATH environment variable fixed compilation errors. I'm curious if a similar fix with the libexec paths for Strawberry Perl 5.10.0 would help (possibly for g77, too.)

Unfortunately, I don't have Vista handy to test.

Cosimo Streppone found that adding "c:\strawberry-perl\mingw\libexec\gcc\mingw32\3.4.5" to the PATH environment variable fixed compilation errors

I'd be surprised if the fix was as simple as that. Admittedly that will fix the cannot exec `cc1' error - but the errors don't end there. It's certainly not good enough when it comes to compiling basic C scripts:

C:\C>type try.c

#include <stdio.h>

int main(void) {
  printf("Hello World\n");
  return 0;
}

C:\C>gcc -o try.exe try.c
gcc: installation problem, cannot exec `cc1': No such file or director
+y

C:\C>set PATH=C:\strawberry\c\libexec\gcc\mingw32\3.4.5;%PATH%

C:\C>gcc -o try.exe try.c
try.c:1:19: no include path in which to search for stdio.h

C:\C>
[download]

And any compilation that includes perl.h fails, since the the standard C headers that perl.h includes aren't found.

I think that approach is a path to nowhere (though, admittedly, I haven't wandered very far down it). Each time one error is fixed, another pops up to replace it .... but if someone *does* have a solution for g77 (that avoids the need for a patched g77.exe) I'd be most grateful to hear it.

Cheers,
Rob

And any compilation that includes perl.h fails, since the the standard C headers that perl.h includes aren't found.

There have been problems getting the installer to set the LIB and INSTALL env variables properly (due to the new UAC in Vista). For example, on my WinXP, I have this:

INCLUDE=C:\strawberry\c\include;C:\strawberry\perl\lib\CORE;C:\Program
+ Files\GnuWin32\include
LIB=C:\strawberry\c\lib;C:\strawberry\perl\bin;C:\Program Files\GnuWin
+32\lib
[download]

(The GnuWin32 were my own addition -- the others are provided by Strawberry on installation.)

If you don't have those set, try setting them and compiling again.

-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.

PPM-2 is easily installable via CPAN, doesn't require anything special

doesn't require anything special

Except XML::Parser, which requires the Expat library, which does require at least a little something special to get it working.

-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.

  a) Why would Strawberry Perl *not* include the PPM utility ?

Because Strawberry perl is not ActivePerl

That said, I would hope a next release to have cpan to be a copy of cpan.bat, because when I have the Strawberry path in front of my $PATH in a Cygwin environment, cpan will start the Cygwin version, and bring me into trouble.

  b) Why would Strawberry Perl *not* include the g77 compiler ?

I've never had the need for any fortran linking with perl, and neither did the maintainers of Strawberry perl I guess.

PPM is not an ActivePerl-only thing, it can be used by any perl. But it seems that nobody outside of ActiveState is really using PPM.

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.

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.

-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.

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

That said, I would hope a next release to have cpan to be a copy of cpan.bat

This is not going to happen. If we were to implement some sort of environment munger, then instead of a one-off change it is more likely we would instead modify ALL of the .bat files, and the pl2bat generator, to fix this universally.

Today I noticed the absence of the DB_File CORE module, that I think should be available, as building it with cpan.bat is impossible.

The development environment is not available in /C/strawberry/c, and many of my programs/scripts depend on having DB_File available.

Does it hit the same problems as the devel env for expat?

Does it hit the same problems as the devel env for expat?

Biggest problem I can see with Berkeley DB is how to get hold of the source. I just wasted an hour of my life going around in circles trying to register on some maggot of a website so I could get hold of it ... to no avail. This is a totally different problem to the expat problem. (Never had any problem getting hold of the libexpat source.) The expat library builds straight out of the box on Windows in the MSYS shell using MinGW. Once libexpat is built and installed, XML::Parser builds and installs out of the box (as per the instructions in the README).

My hunch is that Berkeley DB is somewhat less trivial to build than libexpat - but if I can't get hold of the Berkeley DB source, I can't really find out. (There seems to be a Windows msi installer as well. Again you have to work out how to register before you can download it.)

Cheers,
Rob

BerkeleyDB - was SleepyCat - is now owned by Oracle. If you search on "SleepyCat", it's the first hits with Google. Download here, where I see no need to register. Found in a minute, posting this reply took much longer.


Enjoy, Have FUN! H.Merijn