ExtUtils::MakeMaker - create an extension Makefile |
ExtUtils::MakeMaker - create an extension Makefile
use ExtUtils::MakeMaker;
WriteMakefile( ATTRIBUTE => VALUE [, ...] );
This utility is designed to write a Makefile for an extension module from a Makefile.PL. It is based on the Makefile.SH model provided by Andy Dougherty and the perl5-porters.
It splits the task of generating the Makefile into several subroutines that can be individually overridden. Each subroutine returns the text it wishes to have written to the Makefile.
MakeMaker is object oriented. Each directory below the current directory that contains a Makefile.PL is treated as a separate object. This makes it possible to write an unlimited number of Makefiles with a single invocation of WriteMakefile().
The short answer is: Don't.
Always begin with h2xs. Always begin with h2xs! ALWAYS BEGIN WITH H2XS!
even if you're not building around a header file, and even if you don't have an XS component.
Run h2xs(1)
before you start thinking about writing a module. For so
called pm-only modules that consist of *.pm
files only, h2xs has
the -X
switch. This will generate dummy files of all kinds that are
useful for the module developer.
The medium answer is:
use ExtUtils::MakeMaker; WriteMakefile( NAME => "Foo::Bar" );
The long answer is the rest of the manpage :-)
The generated Makefile enables the user of the extension to invoke
perl Makefile.PL # optionally "perl Makefile.PL verbose" make make test # optionally set TEST_VERBOSE=1 make install # See below
The Makefile to be produced may be altered by adding arguments of the
form KEY=VALUE
. E.g.
perl Makefile.PL PREFIX=/tmp/myperl5
Other interesting targets in the generated Makefile are
make config # to check if the Makefile is up-to-date make clean # delete local temp files (Makefile gets renamed) make realclean # delete derived files (including ./blib) make ci # check in all the files in the MANIFEST file make dist # see below the Distribution Support section
MakeMaker checks for the existence of a file named test.pl in the
current directory and if it exists it execute the script with the
proper set of perl -I
options.
MakeMaker also checks for any files matching glob(``t/*.t''). It will
execute all matching files in alphabetical order via the
the Test::Harness manpage module with the -I
switches set correctly.
If you'd like to see the raw output of your tests, set the
TEST_VERBOSE
variable to true.
make test TEST_VERBOSE=1
A useful variation of the above is the target testdb
. It runs the
test under the Perl debugger (see the perldebug manpage). If the file
test.pl exists in the current directory, it is used for the test.
If you want to debug some other testfile, set the TEST_FILE
variable
thusly:
make testdb TEST_FILE=t/mytest.t
By default the debugger is called using -d
option to perl. If you
want to specify some other option, set the TESTDB_SW
variable:
make testdb TESTDB_SW=-Dx
make alone puts all relevant files into directories that are named by the macros INST_LIB, INST_ARCHLIB, INST_SCRIPT, INST_MAN1DIR and INST_MAN3DIR. All these default to something below ./blib if you are not building below the perl source directory. If you are building below the perl source, INST_LIB and INST_ARCHLIB default to ../../lib, and INST_SCRIPT is not defined.
The install target of the generated Makefile copies the files found below each of the INST_* directories to their INSTALL* counterparts. Which counterparts are chosen depends on the setting of INSTALLDIRS according to the following table:
INSTALLDIRS set to perl site vendor
PREFIX SITEPREFIX VENDORPREFIX INST_ARCHLIB INSTALLARCHLIB INSTALLSITEARCH INSTALLVENDORARCH INST_LIB INSTALLPRIVLIB INSTALLSITELIB INSTALLVENDORLIB INST_BIN INSTALLBIN INSTALLSITEBIN INSTALLVENDORBIN INST_SCRIPT INSTALLSCRIPT INSTALLSCRIPT INSTALLSCRIPT INST_MAN1DIR INSTALLMAN1DIR INSTALLSITEMAN1DIR INSTALLVENDORMAN1DIR INST_MAN3DIR INSTALLMAN3DIR INSTALLSITEMAN3DIR INSTALLVENDORMAN3DIR
The INSTALL... macros in turn default to their %Config ($Config{installprivlib}, $Config{installarchlib}, etc.) counterparts.
You can check the values of these variables on your system with
perl '-V:install.*'
And to check the sequence in which the library directories are searched by perl, run
perl -le 'print join $/, @INC'
PREFIX and LIB can be used to set several INSTALL* attributes in one go. The quickest way to install a module in a non-standard place might be
perl Makefile.PL PREFIX=~
This will install all files in the module under your home directory, with man pages and libraries going into an appropriate place (usually ~/man and ~/lib).
Another way to specify many INSTALL directories with a single parameter is LIB.
perl Makefile.PL LIB=~/lib
This will install the module's architecture-independent files into ~/lib, the architecture-dependent files into ~/lib/$archname.
Note, that in both cases the tilde expansion is done by MakeMaker, not by perl by default, nor by make.
Conflicts between parameters LIB, PREFIX and the various INSTALL* arguments are resolved so that:
$Config{prefix}
part of those INSTALL* arguments, even if the latter are explicitly
set (but are set to still start with $Config{prefix}
).
If the user has superuser privileges, and is not working on AFS or relatives, then the defaults for INSTALLPRIVLIB, INSTALLARCHLIB, INSTALLSCRIPT, etc. will be appropriate, and this incantation will be the best:
perl Makefile.PL; make; make test make install
make install per default writes some documentation of what has been
done into the file $(INSTALLARCHLIB)/perllocal.pod
. This feature
can be bypassed by calling make pure_install.
will have to specify the installation directories as these most probably have changed since perl itself has been installed. They will have to do this by calling
perl Makefile.PL INSTALLSITELIB=/afs/here/today \ INSTALLSCRIPT=/afs/there/now INSTALLMAN3DIR=/afs/for/manpages make
Be careful to repeat this procedure every time you recompile an extension, unless you are sure the AFS installation directories are still valid.
An extension that is built with the above steps is ready to use on systems supporting dynamic loading. On systems that do not support dynamic loading, any newly created extension has to be linked together with the available resources. MakeMaker supports the linking process by creating appropriate targets in the Makefile whenever an extension is built. You can invoke the corresponding section of the makefile with
make perl
That produces a new perl binary in the current directory with all extensions linked in that can be found in INST_ARCHLIB, SITELIBEXP, and PERL_ARCHLIB. To do that, MakeMaker writes a new Makefile, on UNIX, this is called Makefile.aperl (may be system dependent). If you want to force the creation of a new perl, it is recommended, that you delete this Makefile.aperl, so the directories are searched-through for linkable libraries again.
The binary can be installed into the directory where perl normally resides on your machine with
make inst_perl
To produce a perl binary with a different name than perl
, either say
perl Makefile.PL MAP_TARGET=myperl make myperl make inst_perl
or say
perl Makefile.PL make myperl MAP_TARGET=myperl make inst_perl MAP_TARGET=myperl
In any case you will be prompted with the correct invocation of the
inst_perl
target that installs the new binary into INSTALLBIN.
make inst_perl per default writes some documentation of what has been
done into the file $(INSTALLARCHLIB)/perllocal.pod
. This
can be bypassed by calling make pure_inst_perl.
Warning: the inst_perl: target will most probably overwrite your existing perl binary. Use with care!
Sometimes you might want to build a statically linked perl although your system supports dynamic loading. In this case you may explicitly set the linktype with the invocation of the Makefile.PL or make:
perl Makefile.PL LINKTYPE=static # recommended
or
make LINKTYPE=static # works on most systems
MakeMaker needs to know, or to guess, where certain things are
located. Especially INST_LIB and INST_ARCHLIB (where to put the files
during the make(1)
run), PERL_LIB and PERL_ARCHLIB (where to read
existing modules from), and PERL_INC (header files and libperl*.*
).
Extensions may be built either using the contents of the perl source directory tree or from the installed perl library. The recommended way is to build extensions after you have run 'make install' on perl itself. You can do that in any directory on your hard disk that is not below the perl source tree. The support for extensions below the ext directory of the perl distribution is only good for the standard extensions that come with perl.
If an extension is being built below the ext/
directory of the perl
source then MakeMaker will set PERL_SRC automatically (e.g.,
../..
). If PERL_SRC is defined and the extension is recognized as
a standard extension, then other variables default to the following:
PERL_INC = PERL_SRC PERL_LIB = PERL_SRC/lib PERL_ARCHLIB = PERL_SRC/lib INST_LIB = PERL_LIB INST_ARCHLIB = PERL_ARCHLIB
If an extension is being built away from the perl source then MakeMaker will leave PERL_SRC undefined and default to using the installed copy of the perl library. The other variables default to the following:
PERL_INC = $archlibexp/CORE PERL_LIB = $privlibexp PERL_ARCHLIB = $archlibexp INST_LIB = ./blib/lib INST_ARCHLIB = ./blib/arch
If perl has not yet been installed then PERL_SRC can be defined on the command line as shown in the previous section.
If you don't want to keep the defaults for the INSTALL* macros, MakeMaker helps you to minimize the typing needed: the usual relationship between INSTALLPRIVLIB and INSTALLARCHLIB is determined by Configure at perl compilation time. MakeMaker supports the user who sets INSTALLPRIVLIB. If INSTALLPRIVLIB is set, but INSTALLARCHLIB not, then MakeMaker defaults the latter to be the same subdirectory of INSTALLPRIVLIB as Configure decided for the counterparts in %Config , otherwise it defaults to INSTALLPRIVLIB. The same relationship holds for INSTALLSITELIB and INSTALLSITEARCH.
MakeMaker gives you much more freedom than needed to configure
internal variables and get different results. It is worth to mention,
that make(1)
also lets you configure most of the variables that are
used in the Makefile. But in the majority of situations this will not
be necessary, and should only be done if the author of a package
recommends it (or you know what you're doing).
The following attributes may be specified as arguments to WriteMakefile()
or as NAME=VALUE pairs on the command line.
perl Makefile.PL BINARY_LOCATION=x86/Agent.tar.gz
builds a PPD package that references a binary of the Agent
package,
located in the x86
directory relative to the PPD itself.
"-DHAVE_UNISTD_H"
XS()
macro.
Defaults to
{"$(NAME)" => ["boot_$(NAME)" ] }
e.g.
{"RPC" => [qw( boot_rpcb rpcb_gettime getnetconfigent )], "NetconfigPtr" => [ 'DESTROY'] }
Please see the the ExtUtils::Mksymlists manpage documentation for more information about the DL_FUNCS, DL_VARS and FUNCLIST attributes.
This attribute may be most useful when specified as a string on the command line: perl Makefile.PL EXCLUDE_EXT='Socket Safe'
It is only used on OS/2 and Win32.
"-I/usr/5include -I/path/to/inc"
It is not necessary to mention DynaLoader or the current extension when filling in INCLUDE_EXT. If the INCLUDE_EXT is mentioned but is empty then only DynaLoader and the current extension will be included in the build.
This attribute may be most useful when specified as a string on the command line: perl Makefile.PL INCLUDE_EXT='POSIX Socket Devel::Peek'
If set to 'none', no man pages will be installed.
Defaults to $Config{installprivlib}.
If set to 'none', no man pages will be installed.
If set to 'none', no man pages will be installed.
Defaults to $Config{lddlflags}.
perl Makefile.PL
time but is allowed as a
MakeMaker argument. It has the effect of setting both INSTALLPRIVLIB
and INSTALLSITELIB to that value regardless any explicit setting of
those arguments (or of PREFIX). INSTALLARCHLIB and INSTALLSITEARCH
are set to the corresponding architecture subdirectory.
'LIBS' => ["-lgdbm", "-ldbm -lfoo", "-L/path -ldbm.nfs"]
Mind, that any element of the array contains a complete set of arguments for the ld command. So do not specify
'LIBS' => ["-ltcl", "-ltk", "-lX11"]
See ODBM_File/Makefile.PL for an example, where an array is needed. If you specify a scalar as in
'LIBS' => "-ltcl -ltk -lX11"
MakeMaker will turn it into an array with one element.
make
and will be installed during make install
.
@
. By setting it to an empty string you can generate a
Makefile that echos all commands. Mainly used in debugging MakeMaker
itself.
(Where BASEEXT is the last component of NAME, and OBJ_EXT is $Config{obj_ext}.)
-O
. Set it to -g
to turn debugging on. The flag is
passed to subdirectory makes.
Used only when MakeMaker is building the extensions of the Perl core distribution (because normally $(PERL_ARCHLIB) is automatically in @INC, and adding it would get in the way of PERL5LIB).
Used only when MakeMaker is building the extensions of the Perl core distribution (because normally $(PERL_LIB) is automatically in @INC, and adding it would get in the way of PERL5LIB).
malloc()
subsystem.
This should be applicable to most extensions with exceptions of those
sbrk()
and brk();
which rely on special alignment which is not provided by Perl's malloc().
NOTE. Negligence to set this flag in any one of loaded extension nullifies many advantages of Perl's malloc(), such as better usage of system resources, error detection, memory usage reporting, catchable failure of memory allocations, etc.
644
.
See also perm_rw in the MM_Unix manpage.
755
.
See also perm_rwx in the MM_Unix manpage.
{'foobar.PL' => 'foobar'}
The *.PL files are expected to produce output to the target files themselves. If multiple files can be generated from the same *.PL file then the value in the hash can be a reference to an array of target file names. E.g.
{'foobar.PL' => ['foobar1','foobar2']}
{'name_of_file.pm' => '$(INST_LIBDIR)/install_as.pm'}
By default this will include *.pm and *.pl and the files found in the PMLIBDIRS directories. Defining PM in the Makefile.PL will override PMLIBDIRS.
libscan()
method can be used to alter the behaviour.
Defining PM in the Makefile.PL will override PMLIBDIRS.
(Where BASEEXT is the last component of NAME.)
pm_to_blib()
phase). It is empty by default, meaning no filtering is done.
Great care is necessary when defining the command if quoting needs to be done. For instance, you would need to say:
{'PM_FILTER' => 'grep -v \\"^\\#\\"'}
to remove all the leading coments on the fly during the build. The extra \\ are necessary, unfortunately, because this variable is interpolated within the context of a Perl program built on the command line, and double quotes are what is used with the -e switch to build that command line. The # is escaped for the Makefile, since what is going to be generated will then be:
PM_FILTER = grep -v \"^\#\"
Without the \\ before the #, we'd have the start of a Makefile comment, and the macro would be incorrectly defined.
perl Makefile.PL POLLUTE=1
Please inform the module author if this is necessary to successfully install a module under 5.6 or later.
PPM_INSTALL_SCRIPT
below. (e.g. perl)
If you specify LIB or any INSTALL* variables they will not be effected by the PREFIX.
Defaults to $Config{installprefixexp}.
Note: see the Test::Harness manpage for a shortcut for stopping tests early if you are missing dependencies.
Do not use this parameter for simple requirements, which could be resolved at a later time, e.g. after an unsuccessful make test of your module.
It is extremely rare to have to use PREREQ_FATAL
at all!
$PREREQ_PM = { 'A::B' => Vers1, 'C::D' => Vers2, ... };
PREREQ_PRINT
. The output format is different, though:
perl(A::B)>=Vers1 perl(C::D)>=Vers2 ...
Defaults to PREFIX (if set) or $Config{siteprefixexp}. Perls prior to 5.6.0 didn't have an explicit siteprefix in the Config. In those cases $Config{installprefix} will be used.
Defaults to PREFIX (if set) or $Config{vendorprefixexp}
/([\$*])(([\w\:\']*)\bVERSION)\b.*\=/
will be evaluated with eval()
and the value of the named variable
after the eval()
will be assigned to the VERSION attribute of the
MakeMaker object. The following lines will be parsed o.k.:
$VERSION = '1.00'; *VERSION = \'1.01'; ( $VERSION ) = '$Revision: 1.63 $ ' =~ /\$Revision:\s+([^\s]+)/; $FOO::VERSION = '1.10'; *FOO::VERSION = \'1.11'; our $VERSION = 1.2.3; # new for perl5.6.0
but these will fail:
my $VERSION = '1.01'; local $VERSION = '1.02'; local $FOO::VERSION = '1.30';
The file named in VERSION_FROM is not added as a dependency to Makefile. This is not really correct, but it would be a major pain during development to have to rewrite the Makefile for any smallish change in that file. If you want to make sure that the Makefile contains the correct VERSION macro after any change of the file, you would have to do something like
depend => { Makefile => '$(VERSION_FROM)' }
See attribute depend
below.
{'name_of_file.xs' => 'name_of_file.c'}
The .c files will automatically be included in the list of files deleted by a make clean.
-C++
or
-extern
. Do not include typemaps here; the TYPEMAP parameter exists for
that purpose.
-prototypes
, or
-noprototypes
. See the xsubpp documentation for details. MakeMaker
defaults to the empty string.
can be used to pass parameters to the methods which implement that part of the Makefile.
{FILES => "*.xyz foo"}
{ANY_TARGET => ANY_DEPENDECY, ...}
(ANY_TARGET must not be given a double-colon rule by MakeMaker.)
{TARFLAGS => 'cvfF', COMPRESS => 'gzip', SUFFIX => '.gz', SHAR => 'shar -m', DIST_CP => 'ln', ZIP => '/bin/zip', ZIPFLAGS => '-rl', DIST_DEFAULT => 'private tardist' }
If you specify COMPRESS, then SUFFIX should also be altered, as it is needed to tell make the target file of the compression. Setting DIST_CP to ln can be useful, if you need to preserve the timestamps on your files. DIST_CP can take the values 'cp', which copies the file, 'ln', which links the file, and 'best' which copies symbolic links and links the rest. Default is 'best'.
{ARMAYBE => 'ar', OTHERLDFLAGS => '...', INST_DYNAMIC_DEP => '...'}
{LINKTYPE => 'static', 'dynamic' or ''}
NB: Extensions that have nothing but *.pm files had to say
{LINKTYPE => ''}
with Pre-5.0 MakeMakers. Since version 5.00 of MakeMaker such a line can be deleted safely. MakeMaker recognizes when there's nothing to be linked.
{ANY_MACRO => ANY_VALUE, ...}
{FILES => '$(INST_ARCHAUTODIR)/*.xyz'}
{TESTS => 't/*.t'}
{MAXLEN => 8}
If you cannot achieve the desired Makefile behaviour by specifying attributes you may define private subroutines in the Makefile.PL. Each subroutine returns the text it wishes to have written to the Makefile. To override a section of the Makefile you can either say:
sub MY::c_o { "new literal text" }
or you can edit the default by saying something like:
package MY; # so that "SUPER" works right sub c_o { my $inherited = shift->SUPER::c_o(@_); $inherited =~ s/old text/new text/; $inherited; }
If you are running experiments with embedding perl as a library into other applications, you might find MakeMaker is not sufficient. You'd better have a look at ExtUtils::Embed which is a collection of utilities for embedding.
If you still need a different solution, try to develop another subroutine that fits your needs and submit the diffs to makemaker@perl.org
For a complete description of all MakeMaker methods see the ExtUtils::MM_Unix manpage.
Here is a simple example of how to add a new target to the generated Makefile:
sub MY::postamble { return <<'MAKE_FRAG'; $(MYEXTLIB): sdbm/Makefile cd sdbm && $(MAKE) all
MAKE_FRAG }
WriteMakefile()
now does some basic sanity checks on its parameters to
protect against typos and malformatted values. This means some things
which happened to work in the past will now throw warnings and
possibly produce internal errors.
Some of the most common mistakes:
<MAN3PODS =
' '>>The correct code is <MAN3PODS =
{ }>>.
MakeMaker.pm uses the architecture specific information from
Config.pm. In addition it evaluates architecture specific hints files
in a hints/
directory. The hints files are expected to be named
like their counterparts in PERL_SRC/hints
, but with an .pl
file
name extension (eg. next_3_2.pl
). They are simply eval
ed by
MakeMaker within the WriteMakefile()
subroutine, and can be used to
execute commands as well as to include special variables. The rules
which hintsfile is chosen are the same as in Configure.
The hintsfile is eval()ed immediately after the arguments given to WriteMakefile are stuffed into a hash reference $self but before this reference becomes blessed. So if you want to do the equivalent to override or create an attribute you would say something like
$self->{LIBS} = ['-ldbm -lucb -lc'];
For authors of extensions MakeMaker provides several Makefile targets. Most of the support comes from the ExtUtils::Manifest module, where additional documentation can be found.
MANIFEST.SKIP
file (See ExtUtils::Manifest::skipcheck() for
details)
$(DISTNAME)-$(VERSION)
. If that directory
exists, it will be removed first.
perl Makefile.PL
, a make, and
a make test in that directory.
tar
on that directory into a tarfile and
deletes the directory. Finishes with a command $(POSTOP) which
defaults to a null command.
shar
on that directory into a sharfile and
deletes the intermediate directory again. Finishes with a command
$(POSTOP) which defaults to a null command. Note: For shdist to work
properly a shar
program that can handle directories is mandatory.
$(ZIP) $(ZIPFLAGS)
on that directory into a
zipfile. Then deletes that directory. Finishes with a command
$(POSTOP) which defaults to a null command.
Customization of the dist targets can be done by specifying a hash reference to the dist attribute of the WriteMakefile call. The following parameters are recognized:
CI ('ci -u') COMPRESS ('gzip --best') POSTOP ('@ :') PREOP ('@ :') TO_UNIX (depends on the system) RCS_LABEL ('rcs -q -Nv$(VERSION_SYM):') SHAR ('shar') SUFFIX ('.gz') TAR ('tar') TARFLAGS ('cvf') ZIP ('zip') ZIPFLAGS ('-r')
An example:
WriteMakefile( 'dist' => { COMPRESS=>"bzip2", SUFFIX=>".bz2" })
If some events detected in Makefile.PL imply that there is no way to create the Module, but this is a normal state of things, then you can create a Makefile which does nothing, but succeeds on all the ``usual'' build targets. To do so, use
ExtUtils::MakeMaker::WriteEmptyMakefile();
instead of WriteMakefile().
This may be useful if other modules expect this module to be built OK, as opposed to work OK (say, this system-dependent module builds in a subdirectory of some other distribution, or is listed as a dependency in a CPAN::Bundle, but the functionality is supported by different means on the current architecture).
MakeMaker->new()
, and thus by
WriteMakefile()
. The string is split on whitespace, and the result
is processed before any actual command line arguments are processed.
ExtUtils::MM_Unix, ExtUtils::Manifest ExtUtils::Install, ExtUtils::Embed
Andy Dougherty <doughera@lafayette.edu>, Andreas König <andreas.koenig@mind.de>, Tim Bunce <timb@cpan.org>. VMS support by Charles Bailey <bailey@newman.upenn.edu>. OS/2 support by Ilya Zakharevich <ilya@math.ohio-state.edu>.
Currently maintained by Michael G Schwern <schwern@pobox.com>
Send patches and ideas to <makemaker@perl.org>.
Send bug reports via http://rt.cpan.org/. Please send your generated Makefile along with your report.
For more up-to-date information, see http://www.makemaker.org.
ExtUtils::MakeMaker - create an extension Makefile |