I just mangaged to install the perl/Tk module after much struggle. I realise I don't understand what dmake or make etc is actually doing.
I am using strawberry perl installed at C:\strawberry.
Fisrt I unpacked the module to another directory and ran perl makefile.pl which worked fine. Then I tried dmake which did not work. I guess that will be obvious to people who know how this works.
When I placed the module as a sub-directory of C:\strawberry I could run perl makefile.pl, dmake, dmake test and dmake install.
My guess is that dmake install is adding some executable files to the interpreter and to work the module must be in a subdirectory. Is there any article anywhere that explains what it is doing in detail?
When you see a Makefile.PL file, that means it's a module who's install system is ExtUtils::MakeMaker.
EU::MM is the classic system for installing Perl modules dating back to the dawn of CPAN. It relied on the fact that the program make--a common, and powerful dependency tracking tool--was available on almost every unix system, as well as relying on all sorts of unixy patterns and behaviors.
Makefile.PL is a Perl script that the author of the module maintains. It reads information about your system from Perl itself, and uses that to create a Makefile. This Makefile instructs make on actions to perform. For more information on make, check out The Wikipedia page on Make. Essentially though, what make does is look at rules, that tell it what files to 'make'. It recursively looks at all the rules to create the 'target' (eg, when you typed make install, 'install' was the target) and then follows them until (a) it reaches the target or (b) it explodes horribly. We all hope for (a), but (b) is often the case as well. :)
Unfortunately, in Windows-land, we don't have make. Or a compiler. Usually, anyway.
dmake is a make program that happens to run pretty well on Windows. Strawberry Perl packages up all the things you need to actually build in a unix-like environment on Windows into a convenient package, making what you just did actually possible.
This may be taking your question too literally, but dmake has a -v option (for verbose)
dmake -v
dmake -v target
that will display information about exactly what dmake is doing during an installation.
Related
hi am trying to install perl module from cpan in my windows machine am getting below error after hitting two times yes .
Checking if your kit is complete...
Warning: the following files are missing in your kit:
README
Please inform the author.
Writing Makefile for Digest::Perl::MD5
'nmake' is not recognized as an internal or external command,
operable program or batch file.
nmake -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
Running make for D/DO/DOUGW/Spreadsheet-ParseExcel-0.65.tar.gz
Is already unwrapped into directory C:\Perl\cpan\build\Spreadsheet-ParseExcel
0.65
CPAN.pm: Going to build D/DO/DOUGW/Spreadsheet-ParseExcel-0.65.tar.gz
'nmake' is not recognized as an internal or external command,
operable program or batch file.
nmake -- NOT OK
Running make test
Can't test without successful make
Running make install
make had returned bad status, install seems impossible
>perl exceltoxml.pl
Can't locate Spreadsheet/ParseExcel.pm in #INC (#INC contains: C:/Perl/site/lib
C:/Perl/lib .) at exceltoxml.pl line 4.
BEGIN failed--compilation aborted at exceltoxml.pl line 4.
I have tried 5 times.
nmake' is not recognized as an internal or external command
Sinan Ünür is right. The error message is that you don't have nmake installed. This means you are attempting to compile code (probably C code) and there's no C compiler or Make program.
A while ago, I would tell people that ActiveState doesn't fully support cpan because it can't compile code. ActiveState uses it's own pre-compiled packages available via the Perl Package Manager (PPM) which can be used from the command line or from a GUI interface. If a package isn't available via the PPM and it requires compilation, you were just out of luck. I would usually recommend Strawberry Perl instead of ActivePerl for this very reason. Strawberry Perl comes with the complete MinGW environment needed for those compilable CPAN modules.
However, about a half a dozen years ago, ActiveState put together an installable PPM package for the MinGW environment. Once this is installed, ActivePerl can use CPAN.
So you have two solutions:
Install this PPM package as Sinan Ünür mentioned in his answer. Then, try Spreadsheet::ParseExcel again.
Install Strawberry Perl instead of ActiveState's Perl. Strawberry Perl seems to be more compatible with the version of Perl found on Unix/Mac/Linux systems. Then try installing the Spreadsheet::ParseExcel package.
Okay, three solutions: Install Cygwin which will give you the complete Linux Environment on your Windows machine. It can take about two hours to install, but it comes with all of the GNU utilities you've known and love, most other Unix/Linux utilities, and the BASH shell.
It's what a lot of Linux/Unix homeboys use when they get sick of that ol' C:\> prompt. Cygwin comes with the latest version of Perl and works with every single CPAN package I've tried. There are a few minor issues (Like Termcaps) where things don't quite work the way they're suppose to, but I'm generally happy with it. It even comes with X11 and allows you to run XWindow apps, and even use XWindow apps across systems -- just like a REAL operating system does!
There maybe a few instances where CPAN modules may still have issues on Windows. One has to do with archiving and unarchiving modules and the missing libz library. However, installing this MinGW package (or using Strawberry Perl or Cygwin) will solve about 95% of the cpan installation issues.
I have tried 5 times.
Computers are deterministic things. That means, unless you change the conditions under which a program runs, it will always do the same thing (except, maybe, if there is a solar flare or an EMP).
So, there is no difference between issuing the same command once versus five times. If it failed the first time, ceteris paribus, it fill fail all five times.
That said, it looks like you installed ActiveState Perl, but did not install the MinGW package which provides the gcc & dmake based build tools.
So,
C:\>ppm install MinGW
and then try to install packages.
You also have the option of building your own perl using the Community Edition of Microsoft Visual Studio 2013 tools, or any other supported compiler.
I am relatively new to Perl and I need some help with redistributing the non-core modules. Here's the whole story.
There are two non-core modules that were used in the Perl script: XML::Simple and SOAP::Lite. The version that I'm using (currently on Windows) is Strawberry Perl, so these two modules are already included. However, we don't know if the end users (Unix/Linux system) have these two modules as they might only have the standard version and so have only the core modules. My goal is to make the end users do as little configurations/installs as possible.
First, I tried to see if there's any core modules that's similar to XML::Simple and SOAP::Lite. Unfortunately, I didn't find any (Please correct me if I'm wrong).
So I guess now the only option is to redistribute the two modules. I checked and that these two modules allow redistribution. My problem right now is how to do it. I tried googling with keywords "perl redistribute" but didn't find anything useful. My guess is that we use the exporter tool to achieve this. but these two modules are rather complicated modules and they have several nested folders/pm files (and a whole bunch of other files like MAKE, pod, ini files) so I'm not sure what I should do. The examples I found using exporter are rather simple: They only have 1 pm file and 1 pl file and they are placed into one folder.
Also, I'm open to any other better ways to deal with the problem. The goal is just to make sure all end users can use my script with the least configuration/install efforts as we don't want them to run into a whole bunch of compatibility issues.
Any help would be appreciated. Thanks! =D
I want to elaborate a little bit on #ikegami said.
SOAP::Lite has a large number of CPAN dependencies, so the people installing your module are going to need CPAN access to get it to build, whether you provide it for them, or list it as a dependency. Otherwise, you'll need to provide your entire dependency tree, at which point, you end up using perlbrew, maybe carton, possibly local::lib, and then you might decide you need the next higher level and produce RPMs and DEBs.
Probably better to just provide your script, packaged as a CPAN module, list your dependencies within, and let the chips fall where they may.
Just state a dependency on the modules in your Makefile.PL or Build.PL, then give them the following installation instruction:
cpanm script.tar.gz
One of the best things about Perl is The CPAN, the Comprehensive Perl Archive Network. It's a mirroring service that since about the time Perl 5 originally came out has allowed people to share useful add-on modules, like XML::Simple or SOAP::Lite through a standard, common tool, the cpan client that comes with Perl. Almost all Perl distributions (such as Strawberry Perl and most Perl distributions that come with linux) have a CPAN client configured and included with them. This client lets people download and install modules from CPAN simply by knowing the name of the module.
Almost all module distributions on CPAN follow the exact same layout. They usually have a Makefile.PL file (if it uses ExtUtils::MakeMaker to generate the install script), Build.PL file (if it uses Module::Build to generate the install script), or both. These Perl scripts, once run, create a 'Makefile' or a 'Build' file that can let you install the module and verify that all prerequisites are met.
If you've never made a Perl distribution before, you can download any distribution you want from CPAN and take a look at how things are laid out. The folders and file locations are pretty intuitive once you've seen one. They are usually laid out with the install script and supporting files (like a readme) in the root directory, with the custom modules (modules you make) in the lib directory, and with unit tests in the t directory.
I'd recommend looking at the Build.PL based ones if you're a novice; these are pure Perl based install scripts. If you decide to make a Module.PL based distribution, it's really easy to specify that your module distribution needs XML::Simple and SOAP::Lite. First, create a basic Module::Build based install script. This looks something like:
use Module::Build;
my $build = Module::Build->new(
module_name => 'Foo::Bar',
license => 'perl',
requires => {
'perl' => '5.6.1',
'Some::Module' => '1.23',
'Other::Module' => '>= 1.2, != 1.5, < 2.0',
},
);
$build->create_build_script;
(This is taken right from the Module::Build::Authoring docs).
Then, specify the libraries you need and minimum versions of them. Zero (0) is an acceptable version if you don't care, but that means "anything" is good. I'd recommend specifying at least the version of the libraries installed on the machines you're testing with.
(Neat short cut: you can find out the version of any library that has a $VERSION package variable defined by doing:
perl -MSome::Lib -E "say Some::Lib->VERSION()"
.)
To install the module, the steps look something like this:
cd folder\where\my\lib\is
perl Build.PL
Build
Build test
Build install
This will create the install tool, prepare the folder for testing (usually just copying stuff to a build library area for simple modules), run all .t scripts in the t folder (the "tests", which usually use Test::More for unit testing of the module prior to install), and then finally, install your module to your PC's Perl site libraries.
The Build script, as part of the 'setting things up' phase, will look at your prerequisites, and warn you if you don't have them yet.
Then, as pointed out in ikegami's answer, if you use the cpanm client to install your library, the cpan client will automatically go out, download, test, and install your dependencies for you! Alternatively, Build.PL based installers also have the 'installdeps' option, which will do the same thing. Then any and all dependencies (and potentially recursive dependencies) are automatically downloaded, tested, and installed, even if they change in the future.
I'm a C/C++/Java/Unix geek by trade, but now I have to write a Perl program in Windows. So I've got Cygwin, Eclipse with EPIC installed, and simple test programs run. I do not have a Unix machine available to me that I can run Eclipse on.
But I need to use Net::TCP::Server and I can't figure out how to install it. It doesn't appear to be part of the Cygwin Perl install, and I don't want to spend 5 days learning the world of Perl and CPAN and Perl configuration. I just want to write my program.
Any simple ways of installing a Perl module in Cygwin? I'm thinking something like apt-get install would be nice, but I expect that's too much to hope for.
Thanks
$ perl -MCPAN -e shell
cpan shell -- CPAN exploration and modules installation (v1.9402)
Enter 'h' for help.
cpan[1]> install Net::TCP::Server
And it's instructive to list the configuration with the o conf command.
Seeing that some of the info here is a bit outdated and too complicated, I'd rather suggest the following. There are a few different Perl package managers in use. They are all installed with cpan (which is already part of the Cygwin Perl installation), like this:
# Install ppm (outdated)
cpan PPM
# Install cpanp (still used)
cpan CPANPLUS
# Install cpanm (most recent)
cpan App::cpanminus
Then you can install any Perl package you like, as for example in the OP, using cpanm:
cpanm Net::TCP::Server
Sometimes (as noted above) Cygwin may fail certain tests. For example, when using IPv6 on a machine only configured with IPv4, or when your windows firewall is blocking some tests, etc. To attempt to install anyway, try to use the force flag; -f.
cpanm -f Net::TCP::Server
I'm a C/C++/java unix geek by trade, but now I have to write a perl program in windows. So I've got cygwin, eclipse with EPIC installed, and simple test programs run. I do not have a unix machine available to me that I can run eclipse on.
You should be able to run Eclipse with EPIC right under Windows without Cygwin. I like Cygwin for many things, but it isn't exactly a very stable platform. Eclipse runs as a Java program, so all you have to do is make sure Java is installed on your PC. There is even a pre-built Eclipse package.
You can also get a decent Perl that runs right under Windows. Either ActivePerl or Strawberry Perl. Either one will work although many Unix heads prefer Strawberry Perl because it comes with the same MIGW environment that Cygwin has and many feel it's more compatible with the Unix Perl brethren. However, ActiveState Perl can use the Perl Package Manager (PPM) that contains pre-built modules. Unfortunately, the module you want isn't available via PPM.
But I need to use Net::TCP::Server and I can't figure out how to install it. It doesn't appear to be part of the cygwin perl install, and I don't want to spend 5 days learning the world of perl and cpan and perl configuration. I just want to write my program.
Installing from CPAN is really quite simple. The first time you run CPAN, it should pretty much configure itself. Then, to do an install, you run cpan install Net::TCP::Server and that should be it. However, I've tried on several Mac, Unix, and Linux machines, and I can't get it to work. So, this isn't a Windows problem as much as a problem with this module. It is fairly old, and might not work well in newer versions of Perl. You might have to force the install over test's objections.
Maybe you can use one of the already installed IO modules that come with Perl instead. That'll save you a boatload of trouble because the required modules are part of Perl's existing package.
Despite Cygwin's "problems," I use it regularly whenever I have to use Windows. I would recommend first installing a separate installation of Perl using perlbrew so that you won't interfere with Cygwin's copy of Perl in case something bad happens since Cygwin does not enforce root-user policy. In cygwin shell, type
\curl -L http://install.perlbrew.pl | bash
This should walk through the installation for perlbrew and set it up in one of your executable path. Next type
perlbrew init
perlbrew install --force stable
perlbrew switch stable
Wait a bit while a mint Perl is compiled. For unknown reason, Perl can only pass 99.23% of the core module tests on Cygwin (at least on my machine),hence the --force flag). My experience is that it mostly have something to do with handling of device files, like ports and pipes. I am unaware of people trying to resolve the issue as it seems like a Cygwin problem. Although it has not presented much problem for me with general system and web programming tasks. The module testing routines will fail if any problem exists so I am not fretting over it.
Next step is to install cpanm (cpanminus), type
perlbrew install-cpanm
From here on out, to install any library from CPAN, just type
cpanm [library::name1] [library::name2]
cpanm makes it trivial to install any Perl modules. You can even install from your local directory instead of CPAN.
Your mileage may vary, but I had a lot of trouble until I realized that Strawberry perl had a lot of bin folders in my PATH, and when I changed my .bashrc to export only a very simple PATH=/bin:/usr/bin:/usr/local/bin, Cygwin's perl installation's cpan started working beautifully. I used local:lib as Cygwin doesn't support sudo. Before it got into a bad loop saying "Press SPACE and ENTER to exit Patch" over and over.
I have software written in Perl, now I want to release it and I want it to be an installation package like the other GNU software, which can be installed by typing:
./configure; make; make install
I noticed that in autoconf's package, most of the code is written in Perl and the Perl scripts are generated by running "make". That's exactly what I want to do. How would I go about doing that?
===
Added
Thank you for your nice answer! But what I wrote is not a module, it's actually a set of scripts which will do something in a pipe, the only thing I need to setup is the locations of some program I used in the Perl scripts. Is there any suggestion on this?
The process used by ExtUtils::MakeMaker and Module::Install is very similar.
perl Makefile.PL
make
make test
make install
If you're set on using the specific command chain you posted, you can place the following in file configure:
#!/bin/sh
perl Makefile.PL
If you're not set on using the specific command chain you posted, there's also Module::Build.
perl Build.PL
./Build
./Build test
./Build install
I use Module::Build personally.
In the Makefile.am that's where your perl scripts reside, add the line
dist_bin_SCRIPTS = your_perl_program
I want to send emails using gmail's smtp servers and perl. I am trying to install Email::Send::Gmail, but it is not clear to me what are the steps to install it. It seems that it depends on other modules that I do not have installed.
This is partially dependent on which distribution of Perl you're using.
ActivePerl includes a utility called PPM (Perl Package Manager) for installing modules. It handles dependency resolution automatically. PPM is particularly nice for installing XS modules on Windows where a compiler isn't typically available. The downside to PPM is that it some CPAN modules aren't available (probably because they fail ActiveState's automated build process). You can run PPM from either the start menu or by typing ppm at a command prompt.
A more general option is to use the interactive CPAN shell. Note that you must have a compiler to install XS modules using this method. You can access the cpan shell by typing cpan at a command prompt.
The brute-force approach of last resort is to download tarballs from CPAN and manually install them one at a time. When an install aborts due to unsatisfied dependencies download and install them then go back to the first module and try again.
Type:
cpan Email::Send::Gmail
… at the command prompt.
It's probably a good idea to set up local::lib first.
Or see the Perl Foundation Wiki on installing CPAN modules or the same but without root access.
Or see the CPAN guide to installing modules.
If you are using ActivePerl, try the PPM (Perl Package Manager) tool that comes with ActivePerl first. When you tell it to install a module, it should handle all of the dependencies for you.
Note the dependency tree for Email::Send::Gmail. Some of those modules require additional installation of third party software, most notably OpenSSL, which cpan won't do for you.
You can probably install it with:
perl -MCPAN -e shell
install Email-Send-Gmail
Hope it helps,
/Klaus
If you can, CPAN. (ha! It rhymes ... what a crime. Oops, did it again! When will this end... :p) It's essentially the way to install modules for your system. It automatically detects dependencies, downloads, installs, and tests them all for you, and backs out if ever a build or test fails. It's a fantastic and reliable way of installing modules. This works great if you're using essentially any Perl distribution besides ActiveState's distribution, including Strawberry Perl. Generally, this is done with
cpan Module::Name
or, in an interactive mode,
$ cpan
cpan > install Module::Name
If you're using ActiveState Perl, then you probably want to use ActiveState's PPM (Perl Package Manager). It's similar to CPAN, except everything comes prebuilt for ActiveState Perl. ActiveState has a document on how to use their Perl Package Manager on their website, including a graphical example.
If the easy options fail, you are not out of luck. There's some more complex, but manual methods you can do to still install the module.
Most modules that you can download will have within them a bit of metadata in a .yaml file; this will help you figure out whether or not you have all your dependencies. CPAN and PPM automatically resolve and install all your dependencies, but doing it manually will not, leaving that task up to you.
Assuming you have all your dependencies, and you need to install it manually, look for one of two files: Makefile.PL or Build.PL. If you have a Makefile.PL, cd to the directory you extraced the module within a command prompt, and type:
perl Makefile.PL
make
make test
make install
You will need a 'make' program on your system. If it's ActiveState Perl, you may need to install the module manually (see a paragraph or two down.)
If it happens to have a Build.PL, then you need to do a slightly different set of steps:
perl Build.PL
Build
Build test
Build install
(Of course, you may want to consider not installing if make/Build test fails, but that's up to you.)
As a final alternative, if your module has no xs files (ie, code that needs to be compiled on install), and all dependencies are met, you can simply move the files in the lib folder to your perl installation's site\lib folder. If you're interested in just using it for one project, you can add a PERL5LIB environmental variable, pointing to a new, custom library directory (eg, /my/project/lib) and then before running your tool, make sure the environment is set up.
As a followup, see PerlFaq8 - How do I install a module from CPAN.
Also, see PerlFaq8 - How do I keep my own module/library directory?.
Mixing installation methods is asking for heartache and headaches you don't need.
Don't use CPAN with Active Perl. Use PPM.*
PPM download sources can be found at Randy Kobes' site.
If you can't find a PPM of a module you need, you can build your own PPMs easily with Mr. Kobes make_ppm.
You can download a distribution and simply run make_ppm to build a PPM, but I prefer to do the a more "normal" build process:
perl Makefile.PL
make
make test
make_ppm
*If you install your files outside of c:/perl/site/* then it's OK to use CPAN. Just don't co-mingle CPAN shell modules with PPM modules.