use ExtUtils::MakeMaker;
WriteMakefile(
NAME => "Foo::Bar",
VERSION_FROM => "lib/Foo/Bar.pm",
);
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.
As there are various Make programs with incompatible syntax, which use operating system shells, again with incompatible syntax, it is important for users of this module to know which flavour of Make a Makefile has been written for so they'll use the correct one and won't have to face the possibly bewildering errors resulting from using the wrong one.
On POSIX systems, that program will likely be GNU Make; on Microsoft Windows, it will be either Microsoft NMake, DMake or GNU Make. See the section on the ``MAKE'' parameter for details.
ExtUtils::MakeMaker (EUMM) 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().
All inputs to WriteMakefile are Unicode characters, not just octets. EUMM seeks to handle all of these correctly. It is currently still not possible to portably use Unicode characters in module names, because this requires Perl to handle Unicode filenames, which is not yet the case on Windows.
The long answer is the rest of the manpage :-)
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 INSTALL_BASE=~
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 also checks for any files matching glob(``t/*.t''). It will execute all matching files in alphabetical order via the Test::Harness module with the "-I" switches set correctly.
You can also organize your tests within subdirectories in the t/ directory. To do so, use the test directive in your Makefile.PL. For example, if you had tests in:
t/foo
t/foo/bar
You could tell make to run tests in both of those directories with the following directives:
test => {TESTS => 't/*/*.t t/*/*/*.t'}
test => {TESTS => 't/foo/*.t t/foo/bar/*.t'}
The first will run all test files in all first-level subdirectories and all subdirectories they contain. The second will run tests in only the t/foo and t/foo/bar.
If you'd like to see the raw output of your tests, set the "TEST_VERBOSE" variable to true.
make test TEST_VERBOSE=1
If you want to run particular test files, set the "TEST_FILES" variable. It is possible to use globbing with this mechanism.
make test TEST_FILES='t/foobar.t t/dagobah*.t'
Windows users who are using "nmake" should note that due to a bug in "nmake", when specifying "TEST_FILES" you must use back-slashes instead of forward-slashes.
nmake test TEST_FILES='t\foobar.t t\dagobah*.t'
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
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
PERLPREFIX SITEPREFIX VENDORPREFIX
INST_ARCHLIB INSTALLARCHLIB INSTALLSITEARCH INSTALLVENDORARCH
INST_LIB INSTALLPRIVLIB INSTALLSITELIB INSTALLVENDORLIB
INST_BIN INSTALLBIN INSTALLSITEBIN INSTALLVENDORBIN
INST_SCRIPT INSTALLSCRIPT INSTALLSITESCRIPT INSTALLVENDORSCRIPT
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'
Sometimes older versions of the module you're installing live in other directories in @INC. Because Perl loads the first version of a module it finds, not the newest, you might accidentally get one of these older versions even after installing a brand new version. To delete all other versions of the module you're installing (not simply older ones) set the "UNINST" variable.
make install UNINST=1
To have everything installed in your home directory, do the following.
# Unix users, INSTALL_BASE=~ works fine
perl Makefile.PL INSTALL_BASE=/path/to/your/home/dir
Like PREFIX, it sets several INSTALL* attributes at once. Unlike PREFIX it is easy to predict where the module will end up. The installation pattern looks like this:
INSTALLARCHLIB INSTALL_BASE/lib/perl5/$Config{archname}
INSTALLPRIVLIB INSTALL_BASE/lib/perl5
INSTALLBIN INSTALL_BASE/bin
INSTALLSCRIPT INSTALL_BASE/bin
INSTALLMAN1DIR INSTALL_BASE/man/man1
INSTALLMAN3DIR INSTALL_BASE/man/man3
INSTALL_BASE in MakeMaker and "--install_base" in Module::Build (as of 0.28) install to the same location. If you want MakeMaker and Module::Build to install to the same location simply set INSTALL_BASE and "--install_base" to the same location.
INSTALL_BASE was added in 6.31.
# Unix users, PREFIX=~ works fine
perl Makefile.PL PREFIX=/path/to/your/home/dir
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). How the exact location is determined is complicated and depends on how your Perl was configured. INSTALL_BASE works more like what other build systems call ``prefix'' than PREFIX and we recommend you use that instead.
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:
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 by 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.
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.
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 by 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
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.
MakeMaker gives you much more freedom than needed to configure internal variables and get different results. It is worth mentioning 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).
In order to maintain portability of attributes with older versions of MakeMaker you may want to use App::EUMM::Upgrade with your "Makefile.PL".
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.
A hash of modules that are needed to build your module but not run it.
This will go into the "build_requires" field of your META.yml and the "build" of the "prereqs" field of your META.json.
Defaults to "{ "ExtUtils::MakeMaker" => 0 }" if this attribute is not specified.
The format is the same as PREREQ_PM.
A hash of modules that are required to run Makefile.PL itself, but not to run your distribution.
This will go into the "configure_requires" field of your META.yml and the "configure" of the "prereqs" field of your META.json.
Defaults to "{ "ExtUtils::MakeMaker" => 0 }" if this attribute is not specified.
The format is the same as PREREQ_PM.
This is primarily of use for people who repackage Perl modules.
NOTE: Due to the nature of make, it is important that you put the trailing slash on your DESTDIR. ~/tmp/ not ~/tmp.
Defaults to NAME below but with :: replaced with -.
For example, Foo::Bar becomes Foo-Bar.
Defaults to DISTNAME-VERSION.
For example, version 1.04 of Foo::Bar becomes Foo-Bar-1.04.
On some OS's where . has special meaning VERSION_SYM may be used in place of VERSION.
DLEXT => 'unusual_ext', # Default value is $Config{so}
NOTE: When using this option to alter the extension of a module's loadable object, it is also necessary that the module's pm file specifies the same change:
local $DynaLoader::dl_dlext = 'unusual_ext';
{"$(NAME)" => ["boot_$(NAME)" ] }
e.g.
{"RPC" => [qw( boot_rpcb rpcb_gettime getnetconfigent )],
"NetconfigPtr" => [ 'DESTROY'] }
Please see the ExtUtils::Mksymlists 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'
If your executables start with something like #!perl or #!/usr/bin/perl MakeMaker will change this to the path of the perl 'Makefile.PL' was invoked with so the programs will be sure to run properly even if perl is not in /usr/bin/perl.
Defaults to 'Makefile' or 'Descrip.MMS' on VMS.
(Note: we couldn't use MAKEFILE because dmake uses this for something else).
It is only used on OS/2 and Win32.
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}.
Used by 'make install' which copies files from INST_SCRIPT to this directory if INSTALLDIRS=perl.
If set to 'none', no man pages will be installed.
If set to 'none', no man pages will be installed.
Used by 'make install' which copies files from INST_SCRIPT to this directory if INSTALLDIRS is set to vendor.
Defaults to $Config{ld}.
Defaults to $Config{lddlflags}.
'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.
The licensing terms of your distribution. Generally it's ``perl_5'' for the same license as Perl itself.
See CPAN::Meta::Spec for the list of options.
Defaults to ``unknown''.
When this is set to 1, "OBJECT" will be automagically derived from "O_FILES".
Variant of make you intend to run the generated Makefile with. This parameter lets Makefile.PL know what make quirks to account for when generating the Makefile.
MakeMaker also honors the MAKE environment variable. This parameter takes precedence.
Currently the only significant values are 'dmake' and 'nmake' for Windows users, instructing MakeMaker to generate a Makefile in the flavour of DMake (``Dennis Vadura's Make'') or Microsoft NMake respectively.
Defaults to $Config{make}, which may go looking for a Make program in your environment.
How are you supposed to know what flavour of Make a Makefile has been generated for if you didn't specify a value explicitly? Search the generated Makefile for the definition of the MAKE variable, which is used to recursively invoke the Make utility. That will tell you what Make you're supposed to invoke the Makefile with.
Defaults to $(FIRST_MAKEFILE).old or $(FIRST_MAKEFILE)_old on VMS.
This hash should map POD files (or scripts containing POD) to the man file names under the "blib/man1/" directory, as in the following example:
MAN1PODS => {
'doc/command.pod' => 'blib/man1/command.1',
'scripts/script.pl' => 'blib/man1/script.1',
}
Example similar to MAN1PODS.
A hashref of items to add to the CPAN Meta file (META.yml or META.json).
They differ in how they behave if they have the same key as the default metadata. META_ADD will override the default value with its own. META_MERGE will merge its value with the default.
Unless you want to override the defaults, prefer META_MERGE so as to get the advantage of any future defaults.
Where prereqs are concerned, if META_MERGE is used, prerequisites are merged with their counterpart "WriteMakefile()" argument (PREREQ_PM is merged into {prereqs}{runtime}{requires}, BUILD_REQUIRES into "{prereqs}{build}{requires}", CONFIGURE_REQUIRES into "{prereqs}{configure}{requires}", and TEST_REQUIRES into "{prereqs}{test}{requires})". When prereqs are specified with META_ADD, the only prerequisites added to the file come from the metadata, not "WriteMakefile()" arguments.
Note that these configuration options are only used for generating META.yml and META.json --- they are NOT used for MYMETA.yml and MYMETA.json. Therefore data in these fields should NOT be used for dynamic (user-side) configuration.
By default CPAN Meta specification 1.4 is used. In order to use CPAN Meta specification 2.0, indicate with "meta-spec" the version you want to use.
META_MERGE => {
"meta-spec" => { version => 2 },
resources => {
repository => {
type => 'git',
url => 'git://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker.git',
web => 'https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker',
},
},
},
The minimum required version of Perl for this distribution.
Either the 5.006001 or the 5.6.1 format is acceptable.
"NAME" must be a valid Perl package name and it must have an associated ".pm" file. For example, "Foo::Bar" is a valid "NAME" and there must exist Foo/Bar.pm. Any XS code should be in Bar.xs unless stated otherwise.
Your distribution must have a "NAME".
By setting it to an empty string you can generate a Makefile that prints all commands. Mainly used in debugging MakeMaker itself.
Defaults to "@".
Defaults to false.
When true, suppresses the generation of MYMETA.yml and MYMETA.json module meta-data files during 'perl Makefile.PL'.
Defaults to false.
When true, suppresses the writing of "packlist" files for installs.
Defaults to false.
When true, suppresses the appending of installations to "perllocal".
Defaults to false.
(Where BASEEXT is the last component of NAME, and OBJ_EXT is $Config{obj_ext}.)
# Perl executable lives in "C:/Program Files/Perl/bin" # Normally you don't need to set this yourself! $ perl Makefile.PL PERL='"C:/Program Files/Perl/bin/perl.exe" -w'
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).
NOTE. Neglecting to set this flag in any one of the 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.
Defaults to $Config{installprefixexp}, falling back to $Config{installprefix}, $Config{prefixexp} or $Config{prefix} should $Config{installprefixexp} not exist.
Overridden by PREFIX.
Desired permission for directories. Defaults to 755.
perl foo.PL foo
This behavior can be overridden by supplying your own set of files to search. PL_FILES accepts a hash ref, the key being the file to run and the value is passed in as the first argument when the PL file is run.
PL_FILES => {'bin/foobar.PL' => 'bin/foobar'}
PL_FILES => {'foo.PL' => 'foo.c'}
Would run bin/foobar.PL like this:
perl bin/foobar.PL bin/foobar
If multiple files from one program are desired an array ref can be used.
PL_FILES => {'bin/foobar.PL' => [qw(bin/foobar1 bin/foobar2)]}
In this case the program will be run multiple times using each target file.
perl bin/foobar.PL bin/foobar1
perl bin/foobar.PL bin/foobar2
PL files are normally run after pm_to_blib and include INST_LIB and INST_ARCH in their @INC, so the just built modules can be accessed... unless the PL file is making a module (or anything else in PM) in which case it is run before pm_to_blib and does not include INST_LIB and INST_ARCH in its @INC. This apparently odd behavior is there for backwards compatibility (and it's somewhat DWIM). The argument passed to the .PL is set up as a target to build in the Makefile. In other sections such as "postamble" you can specify a dependency on the filename/argument that the .PL is supposed (or will have, now that that is is a dependency) to generate. Note the file to be generated will still be generated and the .PL will still run even without an explicit dependency created by you, since the "all" target still depends on running all eligible to run.PL files.
{'name_of_file.pm' => '$(INST_LIB)/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.
(Where BASEEXT is the last component of NAME.)
PM_FILTER => 'perl -ne "print unless /^\\#/"',
to remove all the leading comments on the fly during the build. In order to be as portable as possible, please consider using a Perl one-liner rather than Unix (or other) utilities, as above. The # is escaped for the Makefile, since what is going to be generated will then be:
PM_FILTER = perl -ne "print unless /^\#/"
Without the \ before the #, we'd have the start of a Makefile comment, and the macro would be incorrectly defined.
You will almost certainly be better off using the "PL_FILES" system, instead. See above, or the ExtUtils::MakeMaker::FAQ entry.
perl Makefile.PL POLLUTE=1
Please inform the module author if this is necessary to successfully install a module under 5.6 or later.
Name of the executable used to run "PPM_UNINSTALL_SCRIPT" below. (e.g. perl)
Name of the script that gets executed by the Perl Package Manager before the removal of a package.
If you specify LIB or any INSTALL* variables they will not be affected by the PREFIX.
It is extremely rare to have to use "PREREQ_FATAL". Its use by module authors is strongly discouraged and should never be used lightly.
For dependencies that are required in order to run "Makefile.PL", see "CONFIGURE_REQUIRES".
Module installation tools have ways of resolving unmet dependencies but to do that they need a Makefile. Using "PREREQ_FATAL" breaks this. That's bad.
Assuming you have good test coverage, your tests should fail with missing dependencies informing the user more strongly that something is wrong. You can write a t/00compile.t test which will simply check that your code compiles and stop ``make test'' prematurely if it doesn't. See ``BAIL_OUT'' in Test::More for more details.
This will go into the "requires" field of your META.yml and the "runtime" of the "prereqs" field of your META.json.
PREREQ_PM => {
# Require Test::More at least 0.47
"Test::More" => "0.47",
# Require any version of Acme::Buffy
"Acme::Buffy" => 0,
}
$PREREQ_PM = {
'A::B' => Vers1,
'C::D' => Vers2,
...
};
If a distribution defines a minimal required perl version, this is added to the output as an additional line of the form:
$MIN_PERL_VERSION = '5.008001';
If BUILD_REQUIRES is not empty, it will be dumped as $BUILD_REQUIRES hashref.
perl(A::B)>=Vers1 perl(C::D)>=Vers2 ...
A minimal required perl version, if present, will look like this:
perl(perl)>=5.008001
Defaults to $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.
Overridable by PREFIX
When true, perform the generation and addition to the MANIFEST of the SIGNATURE file in the distdir during 'make distdir', via 'cpansign -s'.
Note that you need to install the Module::Signature module to perform this operation.
Defaults to false.
A hash of modules that are needed to test your module but not run or build it.
This will go into the "build_requires" field of your META.yml and the "test" of the "prereqs" field of your META.json.
The format is the same as PREREQ_PM.
Defaults to $Config{vendorprefixexp}.
Overridable by PREFIX
# Good
package Foo::Bar 1.23; # 1.23
$VERSION = '1.00'; # 1.00
*VERSION = \'1.01'; # 1.01
($VERSION) = q$Revision$ =~ /(\d+)/g; # The digits in $Revision$
$FOO::VERSION = '1.10'; # 1.10
*FOO::VERSION = \'1.11'; # 1.11
but these will fail:
# Bad
my $VERSION = '1.01';
local $VERSION = '1.02';
local $FOO::VERSION = '1.30';
(Putting "my" or "local" on the preceding line will work o.k.)
``Version strings'' are incompatible and should not be used.
# Bad
$VERSION = 1.2.3;
$VERSION = v1.2.3;
version objects are fine. As of MakeMaker 6.35 version.pm will be automatically loaded, but you must declare the dependency on version.pm. For compatibility with older MakeMaker you should load on the same line as $VERSION is declared.
# All on one line
use version; our $VERSION = qv(1.2.3);
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.
Hashref with options controlling the operation of "XSMULTI":
{
xs => {
all => {
# options applying to all .xs files for this distribution
},
'lib/Class/Name/File' => { # specifically for this file
DEFINE => '-Dfunktastic', # defines for only this file
INC => "-I$funkyliblocation", # include flags for only this file
# OBJECT => 'lib/Class/Name/File$(OBJ_EXT)', # default
LDFROM => "lib/Class/Name/File\$(OBJ_EXT) $otherfile\$(OBJ_EXT)", # what's linked
},
},
}
Note "xs" is the file-extension. More possibilities may arise in the future. Note that object names are specified without their XS extension.
"LDFROM" defaults to the same as "OBJECT". "OBJECT" defaults to, for "XSMULTI", just the XS filename with the extension replaced with the compiler-specific object-file extension.
The distinction between "OBJECT" and "LDFROM": "OBJECT" is the make target, so make will try to build it. However, "LDFROM" is what will actually be linked together to make the shared object or static library (SO/SL), so if you override it, make sure it includes what you want to make the final SO/SL, almost certainly including the XS basename with "$(OBJ_EXT)" appended.
When this is set to 1, multiple XS files may be placed under lib/ next to their corresponding "*.pm" files (this is essential for compiling with the correct "VERSION" values). This feature should be considered experimental, and details of it may change.
This feature was inspired by, and small portions of code copied from, ExtUtils::MakeMaker::BigHelper. Hopefully this feature will render that module mainly obsolete.
{FILES => "*.xyz foo"}
{ANY_TARGET => ANY_DEPENDENCY, ...}
(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'}
"RECURSIVE_TEST_FILES" can be used to include all directories recursively under "t" that contain ".t" files. It will be ignored if you provide your own "TESTS" attribute, defaults to false.
{RECURSIVE_TEST_FILES=>1}
This is supported since 6.76
{MAXLEN => 8}
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 ExtUtils::MM_Unix.
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
}
Some of the most common mistakes:
The correct code is "MAN3PODS => { }".
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'];
Additionally, it will create META.yml and META.json module meta-data file in the distdir and add this to the distdir's MANIFEST. You can shut this behavior off with the NO_META flag.
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(
...other options...
dist => {
COMPRESS => "bzip2",
SUFFIX => ".bz2"
}
);
The original format of CPAN Meta files was YAML and the corresponding file was called META.yml. In 2010, version 2 of the CPAN::Meta::Spec was released, which mandates JSON format for the metadata in order to overcome certain compatibility issues between YAML serializers and to avoid breaking older clients unable to handle a new version of the spec. The CPAN::Meta library is now standard for accessing old and new-style Meta files.
If CPAN::Meta is installed, MakeMaker will automatically generate META.json and META.yml files for you and add them to your MANIFEST as part of the 'distdir' target (and thus the 'dist' target). This is intended to seamlessly and rapidly populate CPAN with module meta-data. If you wish to shut this feature off, set the "NO_META" "WriteMakefile()" flag to true.
At the 2008 QA Hackathon in Oslo, Perl module toolchain maintainers agreed to use the CPAN Meta format to communicate post-configuration requirements between toolchain components. These files, MYMETA.json and MYMETA.yml, are generated when Makefile.PL generates a Makefile (if CPAN::Meta is installed). Clients like CPAN or CPANPLUS will read these files to see what prerequisites must be fulfilled before building or testing the distribution. If you wish to shut this feature off, set the "NO_MYMETA" "WriteMakeFile()" flag to true.
use ExtUtils::MakeMaker qw(WriteEmptyMakefile);
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).
my $value = prompt($message);
my $value = prompt($message, $default);
The "prompt()" function provides an easy way to request user input used to write a makefile. It displays the $message as a prompt for input. If a $default is provided it will be used as a default. The function returns the $value selected by the user.
If "prompt()" detects that it is not running interactively and there is nothing on STDIN or if the PERL_MM_USE_DEFAULT environment variable is set to true, the $default will be used without prompting. This prevents automated processes from blocking on user input.
If no $default is provided an empty string will be used instead.
os_unsupported(); os_unsupported if $^O eq 'MSWin32';
The "os_unsupported()" function provides a way to correctly exit your "Makefile.PL" before calling "WriteMakefile". It is essentially a "die" with the message ``OS unsupported''.
This is supported since 7.26
PERL_MM_OPT='CCFLAGS="-Wl,-rpath -Wl,/foo/bar/lib" LIBS="-lwibble -lwobble"'
Module::Install is a wrapper around MakeMaker which adds features not normally available.
ExtUtils::ModuleMaker and Module::Starter are both modules to help you setup your distribution.
CPAN::Meta and CPAN::Meta::Spec explain CPAN Meta files in detail.
File::ShareDir::Install makes it easy to install static, sometimes also referred to as 'shared' files. File::ShareDir helps accessing the shared files after installation.
Dist::Zilla makes it easy for the module author to create MakeMaker-based distributions with lots of bells and whistles.
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 <https://metacpan.org/release/ExtUtils-MakeMaker>.
Repository available at <https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker>.
See <http://www.perl.com/perl/misc/Artistic.html>