in reply to nmake, CPAN and Modules not listed in PPM

Rather than deal with the ActiveState mess and compiling on Windows, I resorted to cygwin, a suite that provides a unix emulation library. The shell works like a unix shell and I've had no problems using CPAN installs. If you do install it, make sure and include the developement packages.

Not to mention the shell saves on point-n-clickitis.

It is a bit slower due to the extra layer, supposedly, but this has not been a problem for everyday uses not involving massive number crunching.

Matt

  • Comment on Re: nmake, CPAN and Modules not listed in PPM

Replies are listed 'Best First'.
Re: Re: nmake, CPAN and Modules not listed in PPM
by Dr. Mu (Hermit) on Oct 17, 2002 at 06:46 UTC
    This thread mirrors my own frustrations trying to compile modules for ActivePerl. I've mostly just given up in disgust. But, given that cygwin is a potential solution, a couple followup questions come to mind:
    I've ported several ActivePerl programs to Windows machines lacking Perl using perl2exe. Just one executable and maybe a dll are all that need to be transferred. It's a simple, nearly flawless procedure. I've also ported Tcl programs written for cygwin to other Windows machines, and the process was very messy by contrast, requiring an installation of cygwin and numerous other files. How would this play out with Perl/cygwin? Could I still use perl2exe, or would I have to install Perl/cygwin on the target machine?
      By using perl2exe, the interpreter and associated libraries are bundled into the executable. It's a trade off, the executable is larger than it would be if all dependencies were met on the system in the first place. But it's a straightforward process.

      Tcl relies on libraries that must be present on the target system; hence more complexity in porting due to the extra compilation and installation of libraries -- much the same problem as with installing CPAN modules in ActiveState installations.

      cygwin, at its core, is nothing more than a library that handles system calls (think libstd.o) and maps them to associated sequences of calls in native Windows. It's an emulation layer, of sorts. As it turns out, the perl interpreter does much of this also -- so ActiveState perl can handle library calls normally associated with any other version of perl. The only requirement in moving a perl program or module from cygwin into the regular windows environment is that all Perl module dependencies are met -- that is, ActiveState perl must have the same modules installed as the perl installation in the cygwin environment.

      But therein lies the rub. Many modules require compilation using make and a C compiler. This is where most people run into trouble trying to install modules using CPAN on their ActiveState installations.

      This is where cygwin helps out -- this compilation and installation process for modules on CPAN. If it weren't for the complications arising from this step (namely the reliable presence of a compiler and version of make), moving Perl modules and programs back and forth from cygwin, unix, and Windows would be no problem.*

      Matt

      * This assumes programs that do not rely on OS-specific commands in system(), exec(), or backtick calls.