|
Helping ordinary people create extraordinary websites! |
Building Perl projects with MakeMakerBy Sean Dague2005-05-01
Installation (make install) Now the project is ready to build. I will go through the standard build process and look at each of the steps that occur. perl Makefile.PL The first step is running perl Makefile.PL. This will generate the Makefile for the project. On my workstation I have installed perl 5.6.1 into /usr/bin/perl. As I did not specify PREFIX in my Makefile.PL, this variable will be gathered from my perl interpreter. PREFIX will be set to /usr in this case. The pingwww program will thus be installed as /usr/bin/pingwww, and the Net::Ping::HTTP module will be installed as /usr/lib/perl5/site_perl/5.6.1/Net/Ping/HTTP.pm. The PREFIX variable, as well as many other MakeMaker variables can be overridden both in the Makefile.PL as well as on the command line. The command line syntax for such variable assignment is perl Makefile.PL VARIABLE=VALUE. For instance, if you wished pingwww to install as /usr/local/bin/pingwww, you could override PREFIX as such: Command line arguments to Makefile.PL perl Makefile.PL PREFIX=/usr/localThis would put the binaries in /usr/local/bin, and the modules in /usr/local/lib/perl5/site_perl/5.6.1. Although /usr/local/bin is probably in your path, /usr/local/lib/perl5/site_perl/5.6.1 may not be in your Perl include path (unless perl is really in /usr/local/bin), so changing PREFIX indiscriminately is not advised. Here is the expected output of perl Makefile.PL: perl Makefile.PL output rigel:~/NetPingHTTP> perl Makefile.PLMakeMaker has checked to make sure that you have all the files that MANIFEST says you should have, and that it can find all the modules that you have listed in PREREQ_PM. make The next thing to do is run make. This will build all of the perl binaries and libraries into a temporary blib directory. From there, test and installation will occur. If you have taken the time to write proper POD documentation in your binaries and modules, you will gain the benefit of automatic documentation generation. On a UNIX machine, the make process will automatically generate man pages for all the binaries and modules that have POD markup in them. As I said before, this lets you embed all your documentation next to the code that it describes, and maintain only one file. As of perl 5.6.0 you can have MakeMaker build HTML documents for your modules as well. If you define INSTALLHTMLSITELIBDIR either on the perl Makefile.PL command line, or in Makefile.PL, HTML documents will be installed in that directory during installation. I would like HTML documentation generated for me, so I will rerun perl Makefile.PL as follows: Generating HTML documentation perl Makefile.PL INSTALLHTMLSITELIBDIR=~/public_htmlThis will build the HTML docs in my personal Web directory. Another useful thing that MakeMaker does during build is fix the shebang line in all of your perl binaries to whatever is appropriate in your environment. This means I don't have to worry that whoever is installing my code might have perl located in /opt/fromsource/bin/perl or some other odd location, and because of that the program will not run. Running make produces the following output: make output rigel:~/NetPingHTTP> makeOne warning was generated during the make. This is because I used the LE<lt>E<gt> syntax in my POD documentation, which specifies a reference to an external entity. Pod::HTML has some problems generating arbitrary external links, so you will often see warnings at this stage. In general you need not worry about any errors generated by pod2html, as they have little impact on your project. make test The next stepp is executing the test phase of the project. You should expect output as follows: make test output rigel:~/NetPingHTTP> make testI did not have apache running on my machine when I ran the tests, so one test, test number 5, was skipped. You can see that Test::Harness also runs timing code during the test process. It keeps track of both "wallclock secs", which is the elapsed time from the start to the end of the tests, and CPU time, which is the total processing time on the CPU. The reason the wallclock time for these tests was 20 seconds, when the CPU time was less than one second, is that in my environment there is a firewall between my workstation and www.ibm.com and www.yahoo.com. The LWP::UserAgent that is instantiated by Net::Ping::HTTP was created with a 10-second timeout, and hence had 2 timeouts before it moved on. Because I specified tests 6 and 7 as todo tests, no errors were generated due to these failures. To illustrate, let's run make test without asserting that tests 6 and 7 are todo tests. This will generate failures in my environment. As you first begin to use test cases, you will see more failures than successes, so it is good to know how to interpret them: make test failure output rigel:~/NetPingHTTP> make testThe output is slightly busy, but the meaning is clear. The pingpm test script failed tests 6 and 7. This fact is presented in multiple places in the output. The results also provide statistical analysis of the number of tests that succeeded and failed. If you had created multiple test scripts, the final "Failed" line would tell you how many of your test scripts were not 100% successful, as well as how many total test cases failed. make install The last part of building the project is running make install. If you are installing into privileged directories (like /usr), you will need to be root to do the install. At this point all binaries, modules, man pages, and Web pages will be installed. make install output [root@rigel]# make installNow the code is installed, and the build process is completed. Tutorial Pages: » The Module that Makes Makefiles and Much More » Programming Products vs. Programs » Anatomy of a MakeMaker Project » Your First MakeMaker Project (make) » Building Test Cases (make test) » Installation (make install) » Distributing Your Code (make dist) » Conclusion » Resources First published by IBM DeveloperWorks
|
|