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.
In reply to Re: Re: Re: nmake, CPAN and Modules not listed in PPM
by mojotoad
in thread nmake, CPAN and Modules not listed in PPM
by Flame
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |