All the Perl that's Practical to Extract and Report

Subverting ActivePerl ;-P

somian on 2005-06-03T12:08:20

This is an informal account of what I have done to have full access to CPAN modules under ActiveState's Perl for Win32 distribution (binary build package).

Here are some pre-existing niceties I have set up on my systems

The cygwin BASH shell

Everyone has heard of Cygwin, I'd think (although most don't mispronounce it as I do: I say "Sigh-Gwin" but most say "Cig-Win" ;-). The BASH shell is just like that which comes standard on most any Linux. I use both Linux (and *BSD) and MS Windows. I fail to see, although some have tried to convince me otherwise, why I must shift mental gears, readjust to a wholly different (and grossly inferior) cli environment, just because I've switched for a moment to MS Windows.

Since Cygwin is a comprehensive collection of ports of GNU software to MS Windows systems (that is, by installing the core of Cygwin you can then run many different packages that might not otherwise be available to MS Windows users), it naturally includes Perl. However, I do not regard it as necessary to limit one's self to using only CygPerl from the Cygwin bash shell. It might seem unnatural to some, but this is only a result of drawing artificial barriers in one's mind between the different complexities of MS Windows. So I run the native Win32 Perl by invoking scripts from the BASH shell as freely as I might do with the CygPerl interpreter.

The MinGW GCC suite

Not as many people have heard of MinGW, although it is certainly mentioned in the Perl documentation. It isn't generally necessary to have MinGW if you have Cygwin; the two have overlap (some of what is provided by Cygwin is also provided by MinGW, or vice-versa). The gcc available with Cygwin can be "run in MinGW mode" so to speak (by which is meant "run in such a way that only Windows API and and Windows native C-runtime library functions are called; none of what's changed or added by Cygwin is"). Exclusion of cygwin functionality is accomplished by using the -mno-cygwin flag for the gcc invocation commandline. To be complete, here I'll mention flags related to the flexibility of the "cygming" gcc port in how it builds code: 

  • -mwin32
          bring in the Windows header defines (the "Windows realm") 
  • -mno-win32
       the converse of above — exclude Windows realm. 
  • -mconsole
        select the Console sub-system of MS Windows OS's. 
  • -mwindows
        select the GUI sub-system. 
  • -mcygwin
         select the Cygwin realm 
  • -mno-cygwin
      the converse of above — exclude the Cygwin realm
make

The next piece of software plays a key role in installing all modules that use the traditional ExtUtils::MakeMaker -generated Makefile to direct the steps required. There are 4 possible flavours of `make' utility that could be found on an MS Windows system; none of them will be found on a plain, out of the box Windows.

  • dmake
  • make from GNU, also (better, in this case) found as gmake
  • pmake, unfortunately named, could mean two things: either a "pure Perl make" implementation done by Nick Ing-Simmons (), or a BSD make, although whether any port of the BSD make to Windows has been done, I do not actually know.
  • nmake from MS which can come with MSVC++ / Visual Studio or be downloaded (for $0, gratis).

It's my opinion that it might be better for working with Perl on MS Windows to run GNU make under the name "gmake", or would be if new entries for this were made in some few key places in the Perl source files (reason: because it disambiguates which of the many possible `make's we have available).

The Config parameter for ActivePerl is of course to use the MS nmake (since ActivePerl is built using MS tools). This can, however, be changed (which will be covered in the next posting of this journal series).

I will be adding to this journal sequence at the earliest available opportunity.