What is the process to manually installing Perl modules on Windows XP? I've seen UNIX commands like
perl Makefile.PL
make
make install
but I can't find a comparable 'make' command in Windows commandline. I cannot use CPAN to install the modules, as firewall settings prevent the network accesses needed. Any help is greatly appreciated.
Strawberry Perl includes dmake which, to my knowledge, is essentially the same as make except it's built for a Windows environment. There are also other alternatives such as GNU make.
Nowadays Strawberry Perl includes gmake tool.
Trying to use dmake outputs DMAKE WARNING: Do not use dmake.exe utility as it is no longer part of Strawberry Perl, use gmake.exe instead!
Related
I have the following question in perl.
1) Is it possible to install multiple version of perl(example perl version: 5.6 and perl version 5.24) in windows system.
2) In case if the above question 1 is possible then how to call the perl file using version. For example, call the new version perl file from old version of perl file.
On Windows systems
You can use berrybrew
To get a list of available versions:
berrybrew available
Based on available versions you can install with following command:
berrybrew install 5.10.1_32
To switch the version:
berrybrew switch 5.10.1_32
On unixy systems
Using perlbrew, you can install different versions of Perl.
You can run a single command against a specific version of Perl using the following command:
perlbrew exec 5.27.11 myscript.pl
You don't need to do anything special. Strawberry Perl is the de-facto standard version of Perl for Windows, and its installer gives you the option of specifying to which directory you want to install it.
For example, I have
...
C:\progs\sp5280-x64 # Perl 5.28, 64-bit
C:\progs\sp5300-x64 # Perl 5.30, 64-bit
C:\progs\sp5302-x64 # Perl 5.32, 64-bit
Simply specify which Perl you want to use when you launch a program.
C:\progs\sp5302-x64\perl\bin\perl a.pl
By editing your PATH and the file association for .pl files, you can set the default perl used from the console and by double-clicking a .pl file.
I suck at Windows administration, but here goes my stupid suggestion anyway.
1)Install different versions of perl in different folders.
2)Include all folders in the %PATH% variable.
3)Rename the perl executables to its version:
perl.exe (5.4) --> perl5_4.exe
perl.exe (5.6) --> perl5_6.exe
4)When using the console to execute it, use
perl5_4 [file]
My honest recommendations are:
Use VirtualBox or any OS virtualization application, which is heavy in hardware requirements but works like wonders.
For any multi-version environment, always use Docker.
Just use Linux and install perlbrew
Simple Way to Do this use Virtual machine
and insall os in VIRTUAL BOX and Install old/new Version in Virtual machine.
Download Virtual BOx
This is my first day with Perl. I am confused with multiple versions of Perl on my system (Windows 7 32-bit). After installing DWIM Perl when I checked for a Perl installation using 'perl -v' it was showing
This is perl, v5.8.8 built for msys-64int
and after setting the path of System Variables to the E:\Dwimperl\perl\bin directory it is showing
This is perl 5, version 14, subversion 2 (v5.14.2) built for MSWin32-x86-multi-thread
Does Windows comes with Perl installed? And will overwriting PATH do any harm?
No, Windows doesn't have Perl installed by default. Someone before you has installed Perl 5.8.8
You probably won't do any harm adding a location to the PATH environment variable, but your question isn't clear. Have you changed it to just ...\Dwimperl\perl\bin, or have you added it to the end?
You really shouldn't use relative paths in the PATH list, if that is what you've done. Do you really have three dots in there? If so then I am surprised that it works at all.
I suggest you run appwiz.cpl and look to see what is installed there. Remove the older Perl if you are sure there is no need for it.
Also, I recommend that you use Strawberry Perl rather than the DWIM fork. The only real difference is that it has a lot of additional modules pre-installed that you may well not need, at the expense of being a couple of versions behind basic Strawberry Perl
I tried to install Perl 5.16 module 'Template-Toolkit' on windows 7 by using this command in cmd:
C:>ppm install Template-Toolkit
ppm install failed: Can't find any package that provides Template-Toolkit
All other modules I installed (AppConfig, DBI, DBD-mysql, MailTools, GD, Chart, GDGraph, ..) succeeded.
Following this webpage as a guide, they mention (under ActivateState Perl section) that you may not install Perl into a directory that contains a space (eg "C:\Program Files"), because it will break the Template-Toolkit installer. Since I installed Perl directly in 'C:\' -> 'C:\Perl64\', this could not be the case.
Is there a solution for this problem? Or should I use an older version of Perl, mentioned here?
The only errors in the error log are errors in the documentation (minor encoding issues).
The module could be installed safely. Just use cpan to do it. You'll just have to force the installation.
C:\>cpan
cpan> install Template
For me, that runs without issue. (The failing tests are skipped since they're dev-only tests.) If if fails for you and the only failures are the two errors from t/zz-pod-kwalitee.t, you can safely follow up with
cpan> force install Template
According to the ppm template-toolkit page, the build for ActiveState's Perl 5.16 failed (which is why it isn't available).
Your options seem to be:
Fix whatever bug is stopping it being built (it looks like it is just a couple of tests on the POD, so it could be an easy fix)
Use an older version of ActiveState Perl
Use a different distribution of Perl for Windows (such as Strawberry Perl)
Use a different operating system (e.g. Ubuntu in a virtual machine)
I got Warning and Error messages after these commands:
C:\>cpan
cpan> install Template
Please seen the screen shot below.
I haven't tried it myself but you can get Template::Alloy from the ActiveState PPM: http://metacpan.org/pod/Template::Alloy which claims it supports the TT2 syntax among others.
Module installation varies when compared to Windows and linux/Unix Operating system.
In Win32 we need to use a program called nmake and after we follow
1. C:\> perl Makefile.PL
2. C:\> nmake
3. C:\> nmake test
4. C:\> nmake install
and in Linux we follow
1. $ perl Makefile.PL
2. $ make
3. $ make test
4. $ make install
the process of installing would be same for both the operating systems, the only difference would be in the keyword used make and nmake. Could any one let me know what does the letter n represents and what is its specification in windows.
From Wikipedia,
Microsoft nmake, commonly available on Windows. It is fairly basic in
that it offers only a subset of the features of the other two versions
of Make (BSD and GNU ). Microsoft's nmake is not to be confused with
nmake from AT&T and Bell Labs for Unix.
Microsoft nmake is detailed here and GNU make is detailed here
Actually, module installation is usually done as follows on Windows and linux:
cpan Module::Name
On to your question.
Perl expects the same compiler suite that was used to build Perl to be used to build the module.
There are two primary tool chains on Windows. There is the one provided by Microsoft and there is a port of GNU's.
The make tool provided by Microsoft is named nmake.
The make tool provided by the MinGW port of GNU's tools is named dmake.
So,
If your Perl was built using MS's tools (e.g. Windows builds of Perl by ActiveState), you need to to use nmake.
If your Perl was built using GNU's tools (e.g. builds of Perl by Strawberry), you need to to use dmake.
Which brings us back to cpan Module::Name.
cpan will ask Perl what tools were used to build it, and use those tools.
Normally. That's not the case on Windows. cpan is actually far more flexible on Windows. cpan will first look the tool chain that was used to build Perl. If it's not found, cpan install the GNU tool chain for you and temporarily fool perl into believing it was built using GNU's tool chain.
That means you run cpan Module::Name it should work no matter what on ActivePerl. (And there's also ppm install Module::Name, although I'd run ppm with no arguments first to add repositories (e.g. bribes))
Building perl 5.14.2 on windows - getting error NMAKE : fatal error U1077: miniperl.exe' : return code '0x1' while the following command is invoked after running "nmake -logo" from win32 folder under perl source.
../miniperl.exe -I../lib ../make_ext.pl "MAKE=nmake -nologo" --dir=../cpan --dir=../dist --dir=../ext --nonxs
Did anybody face this problem before? Please let me know
Unlike Mac and Unix, Windows doesn't' come with a C compiler installed. Thus, it can be difficult to figure out exactly where things are going wrong without more information. For example, did you install the GCC compiler or another standard C compiler?
The easiest way to get the most recent and complete version of Perl on Windows is to use one of the two standard Windows distributions:
Straberry Perl
ActivePerl
Many people like Strawberry Perl because it's a duplicate of what you find on Unix. The same modules, the same libraries. Others prefer ActivePerl because it includes by default all of the special Windows modules that you probably want to use on Windows to do things like update the registry, talk to the Windows domain to check credentials, etc.
The truth is that both of these versions are more or less the same. The two main complaints of why you should use one over the other:
Strawberry Perl doesn't work with Win32
Active Perl uses PPM and not CPAN.
Are both not correct. You can install and download the Win32 modules in Strawberry Perl and it'll run about every script that ActivePerl does.
And, Active Perl can now install the same C compiler Strawberry Perl uses if you want to install a module that requires compilation. The directions are online. It works with almost all the CPAN modules.
So, unless you have a special reason to build Perl from scratch, I recommend you just download ActivePerl or Strawberry Perl -- especially if you are not really familiar with C/C++ and Make.