Learning Perl Objects, References amp;amp; Modules [Electronic resources] نسخه متنی

13.5 Controlling the Distribution with Makefile.PL

The Perl
developers have chosen to rely on the standard Unix
make utility to build and install Perl itself, and
that same mechanism is used for additional modules.[9] If
you have a non-Unix system, a make-like utility
should also be available. On Windows, for example, you may have
dmake or another program. The command
perl -V:make will tell you the
name of your make utility program; if it says
make='nmake', simply use nmake
wherever you use make. In any case, you should
call the controlling file a Makefile, even though
its name may vary as well.

[9] The Module::Build module currently in
development may replace all of that some day but is only in a
pre-release form at the time of this writing.

However, crafting a Makefile is tricky but
repetitive. And what better way to accomplish a tricky but repetitive
task than with a program? Since you're talking about
Perl add-on modules, you know that Perl is available, so how about a
Perl program to generate the Makefile?

That's exactly what happens. The distribution is
required to contain a Makefile.PL, which is a Perl
program to build a Makefile. Then from there, you
use make (or something like it) to control all of
the remaining tasks.

The h2xs tool generates
a template Makefile.PL that you probably
won't even need to touch for single-module
distributions:

$ cat Makefile.PL
use 5.008;
use ExtUtils::MakeMaker;
# See lib/ExtUtils/MakeMaker.pm for details of how to influence
# the contents of the Makefile that is written.
WriteMakefile(
'NAME'                => 'Island::Plotting::Maps',
'VERSION_FROM'        => 'Maps.pm', # finds $VERSION
'PREREQ_PM'                => {  }, # e.g., Module::Name => 1.1
($] >= 5.005 ?    ## Add these new keywords supported since 5.005
(ABSTRACT_FROM => 'Maps.pm', # retrieve abstract from module
AUTHOR     => 'Ginger Grant <ginger@island.cocoanet>') : (  )),
);

Yes, this is
a Perl program. The WriteMakefile routine is
defined by the ExtUtils::MakeMaker module
(included with Perl) to generate a Makefile. As
the developer of the module, use this makefile to build and test your
module and prepare a distribution file:

$ perl Makefile.PL
Checking if your kit is complete...
Looks good
Writing Makefile for Island::Plotting::Maps

The ultimate user of your distribution will execute the identical
command at their site. However, the Makefile will
most likely be different, reflecting the differences in installation
locations, local policies, and even the C compiler and linking
instructions appropriate for their architecture.
It's a nice system that has worked quite well over
the years.

The creation of the Makefile.PL (and resulting
Makefile) is quite flexible. For example, you can
run code to ask the person installing your module about the locations
of other installed libraries or tools, or get options for variations
in activity.[10]

[10] Please keep the number of questions to a
minimum, however. Most people are irritated when asked a series of
questions, especially when they are just upgrading your module. If
possible, store the answers in a configuration module that you
install so that a later invocation of your installer can pull the
previous answers as defaults.

The PREREQ_PM
setting is important if your module depends on non-core Perl modules,
especially if you plan to upload your code to the CPAN. Proper use of
the prerequisites list can make installing your module nearly
painless, and your user community will thank you.