ExtUtil...akeMaker(3)

๐Ÿ“ฆ version 7.70, in opensuse-leap 16.0

๐Ÿ’– ExtUtils::MakeMaker(3) ๐Ÿ’–

okay bestie, this is the ExtUtils::MakeMaker(3) page from the User Contributed Perl Documentation zone, and it is a whole mood. weโ€™re making Makefiles for Perl extension modules out of a Makefile.PL, and yes, itโ€™s giving build-system main character energy. ๐ŸŽ€


๐ŸŒธ NAME ๐ŸŒธ

ExtUtils::MakeMaker โ€” Create a module Makefile

๐Ÿ“œ SYNOPSIS ๐Ÿ“œ

use ExtUtils::MakeMaker;

WriteMakefile(
    NAME              => "Foo::Bar",
    VERSION_FROM      => "lib/Foo/Bar.pm",
);

๐ŸŒˆ DESCRIPTION ๐ŸŒˆ

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. heritage moment. โœจ

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. very modular, very demure.

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. fr fr, wrong Make = chaos. ๐Ÿ˜ญ

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(). unlimited Makefiles, one call, iconic. ๐Ÿ‘‘

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. weโ€™re getting there, but not yet. ๐Ÿซถ

See ExtUtils::MakeMaker::FAQ for details of the design and usage.

๐Ÿ› ๏ธ How To Write A Makefile.PL ๐Ÿ› ๏ธ

See ExtUtils::MakeMaker::Tutorial.

The long answer is the rest of the manpage :-)

๐Ÿš€ Default Makefile Behaviour ๐Ÿš€

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 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

๐Ÿงช make test ๐Ÿงช

MakeMaker checks for the existence of a file named test.pl in the current directory, and if it exists it executes 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 Test::Harness module with the -I switches set correctly. alphabetical order, because chaos is not the vibe. โœจ

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. choose your fighter. ๐Ÿฆ‹

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. not a drill, the backslashes matter. ๐Ÿ’…

nmake test TEST_FILES='t\foobar.t t\dagobah*.t'

๐Ÿž make testdb ๐Ÿž

A useful variation of the above is the target "testdb". It runs the test under the Perl debugger (see perldebug). 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 install ๐Ÿ“ฆ

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. location lore. ๐Ÿ—‚๏ธ

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. the audacity ๐Ÿ˜ญ. To delete all other versions of the module youโ€™re installing (not simply older ones) set the "UNINST" variable.

make install UNINST=1

๐Ÿ  INSTALL_BASE ๐Ÿ 

INSTALL_BASE can be passed into Makefile.PL to change where your module will be installed. INSTALL_BASE is more like what everyone else calls "prefix" than PREFIX is. naming is hard, okay. ๐Ÿ’…

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. matching locations, matching energies. ๐Ÿซถ

INSTALL_BASE was added in 6.31.

๐Ÿงญ PREFIX and LIB attribute ๐Ÿงญ

PREFIX and LIB can be used to set several INSTALL* attributes in one go. Hereโ€™s an example for installing into your home directory.

# 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. trust, use INSTALL_BASE. โœจ

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. tilde plot twist. ๐ŸŒ€

Conflicts between parameters LIB, PREFIX and the various INSTALL* arguments are resolved so that:

  • setting LIB overrides any setting of INSTALLPRIVLIB, INSTALLARCHLIB, INSTALLSITELIB, INSTALLSITEARCH (and they are not affected by PREFIX);
  • without LIB, setting PREFIX replaces the initial $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 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. no perllocal.pod, no problem. ๐ŸŽ€

๐Ÿ—‚๏ธ AFS users ๐Ÿ—‚๏ธ

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. AFS said โ€œwhat is permanent, anywayโ€. ๐Ÿ˜ญ

๐Ÿ”— Static Linking of a new Perl Binary ๐Ÿ”—

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, bestie, don't @ me). 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. No cap, it literally tells you what to do ๐Ÿซถ

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. Iconic behaviour honestly.

โš ๏ธ Warning: the inst_perl: target will most probably overwrite your existing perl binary. Use with care! Like, actually with care. This is not a drill ๐Ÿ’€

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

๐Ÿฆ‹ Determination of Perl Library and Installation Locations ๐Ÿฆ‹

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 โ€” iykyk, that path is a whole vibe reserved for the built-ins.

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. Slay.

๐ŸŽ€ Which architecture dependent directory? ๐ŸŽ€

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. Bestie it's just matching energy, fr fr ๐Ÿงš

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). Lowkey the whole "or you know what you're doing" clause is doing so much heavy lifting here ๐Ÿ˜ญ

โœจ Using Attributes and Parameters โœจ

The following attributes may be specified as arguments to WriteMakefile() or as NAME=VALUE pairs on the command line. Attributes that became available with later versions of MakeMaker are indicated.

In order to maintain portability of attributes with older versions of MakeMaker you may want to use App::EUMM::Upgrade with your "Makefile.PL". Considerate queen behaviour ๐Ÿ’œ

๐Ÿ’– ABSTRACT ๐Ÿ’–

One line description of the module. Will be included in PPD file.

๐Ÿ’– ABSTRACT_FROM ๐Ÿ’–

Name of the file that contains the package description. MakeMaker looks for a line in the POD matching /^($package\s-\s)(.*)/. This is typically the first line in the "=head1 NAME" section. $2 becomes the abstract.

๐Ÿ’– AUTHOR ๐Ÿ’–

Array of strings containing name (and email address) of package author(s). Is used in CPAN Meta files (META.yml or META.json) and PPD (Perl Package Description) files for PPM (Perl Package Manager).

๐Ÿ’– BINARY_LOCATION ๐Ÿ’–

Used when creating PPD files for binary packages. It can be set to a full or relative path or URL to the binary archive for a particular architecture. For example:

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.

๐Ÿ’– BUILD_REQUIRES ๐Ÿ’–

Available in version 6.55_03 and above.

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.

๐Ÿ’– C ๐Ÿ’–

Ref to array of *.c file names. Initialised from a directory scan and the values portion of the XS attribute hash. This is not currently used by MakeMaker but may be handy in Makefile.PLs. (It's giving "just vibes, but keep it around" ๐Ÿ“)

๐Ÿ’– CCFLAGS ๐Ÿ’–

String that will be included in the compiler call command line between the arguments INC and OPTIMIZE. Note that setting this will overwrite its default value ($Config::Config{ccflags}); to preserve that, include the default value directly, e.g.:

CCFLAGS => "$Config::Config{ccflags} ..."

๐Ÿ’– CONFIG ๐Ÿ’–

Arrayref. E.g. [qw(archname manext)] defines ARCHNAME & MANEXT from config.sh. MakeMaker will add to CONFIG the following values anyway: ar cc cccdlflags ccdlflags cpprun dlext dlsrc ld lddlflags ldflags libc lib_ext obj_ext ranlib sitelibexp sitearchexp so

๐Ÿ’– CONFIGURE ๐Ÿ’–

CODE reference. The subroutine should return a hash reference. The hash may contain further attributes, e.g. {LIBS => ...}, that have to be determined by some evaluation method.

๐Ÿ’– CONFIGURE_REQUIRES ๐Ÿ’–

Available in version 6.52 and above.

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.

๐Ÿ’– DEFINE ๐Ÿ’–

Something like "-DHAVE_UNISTD_H"

๐Ÿ’– DESTDIR ๐Ÿ’–

This is the root directory into which the code will be installed. It prepends itself to the normal prefix. For example, if your code would normally go into /usr/local/lib/perl you could set DESTDIR=~/tmp/ and installation would go into ~/tmp/usr/local/lib/perl.

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. The slash is not decorative, bestie, it's load-bearing ๐Ÿ™ˆ

๐Ÿ’– DIR ๐Ÿ’–

Ref to array of subdirectories containing Makefile.PLs e.g. ['sdbm'] in ext/SDBM_File

๐Ÿ’– DISTNAME ๐Ÿ’–

A safe filename for the package.

Defaults to NAME below but with :: replaced with -.

For example, Foo::Bar becomes Foo-Bar.

๐Ÿ’– DISTVNAME ๐Ÿ’–

Your name for distributing the package with the version number included. This is used by 'make dist' to name the resulting archive file.

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 ๐Ÿ’–

Specifies the extension of the module's loadable object. For example:

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';

๐Ÿ’– DL_FUNCS ๐Ÿ’–

Hashref of symbol names for routines to be made available as universal symbols. Each key/value pair consists of the package name and an array of routine names in that package. Used only under AIX, OS/2, VMS and Win32 at present. The routine names supplied will be expanded in the same way as XSUB names are expanded by the XS() macro. Defaults to

{"$(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.

๐Ÿ’– DL_VARS ๐Ÿ’–

Array of symbol names for variables to be made available as universal symbols. Used only under AIX, OS/2, VMS and Win32 at present. Defaults to []. (e.g. [ qw(Foo_version Foo_numstreams Foo_tree ) ])

๐Ÿ’– EXCLUDE_EXT ๐Ÿ’–

Array of extension names to exclude when doing a static build. This is ignored if INCLUDE_EXT is present. Consult INCLUDE_EXT for more details. (e.g. [ qw( Socket POSIX ) ])

This attribute may be most useful when specified as a string on the command line: perl Makefile.PL EXCLUDE_EXT='Socket Safe'

๐Ÿ’– EXE_FILES ๐Ÿ’–

Ref to array of executable files. The files will be copied to the INST_SCRIPT directory. Make realclean will delete them from there again.

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. So thoughtful honestly ๐ŸŒˆ

๐Ÿ’– FIRST_MAKEFILE ๐Ÿ’–

The name of the Makefile to be produced. This is used for the second Makefile that will be produced for the MAP_TARGET.

Defaults to 'Makefile' or 'Descrip.MMS' on VMS.

๐Ÿ’ญ tiny aside rolling over from before: (Note: we couldn't use MAKEFILE because dmake uses this for something else).

FULLPERL

The Perl binary that's actually capable of running this extension โ€” like, loading XS modules and all that jazz. The whole "yes this one can do the heavy lifting" energy. ๏ฟฝ๏ฟฝ

FULLPERLRUN

Literally the same as PERLRUN, except it rolls with FULLPERL instead. โœจ

FULLPERLRUNINST

Same deal as PERLRUNINST, but powered by FULLPERL. ๐Ÿซถ

FUNCLIST

This is your backup plan for naming the functions you want exported from the extension. Its value is a reference to an array of function names to be exported by the extension. Those names get passed through to the linker options file completely unaltered โ€” no edits, no glow-ups, nothing. ๐Ÿ”ฅ

H

Ref to array of *.h file names. Basically the same vibe as C. ๐Ÿ’…

IMPORTS

This attribute is for specifying names to import into the extension. Takes a hash ref.

Heads up: it's only used on OS/2 and Win32. ๐Ÿ™ˆ

INC

Include file dirs, like so: "-I/usr/5include -I/path/to/inc" ๐ŸŽ€

INCLUDE_EXT

An array of extension names to include when you're doing a static build. Normally MakeMaker builds with all the installed extensions when doing a static build โ€” and tbh that's usually exactly what you want. But if INCLUDE_EXT is present, MakeMaker builds only with the extensions you explicitly mention. (e.g. [ qw( Socket POSIX ) ])

It is not necessary to mention DynaLoader or the current extension when you're filling in INCLUDE_EXT. And if INCLUDE_EXT is mentioned but is empty, then only DynaLoader and the current extension get included in the build. โœจ

This attribute is probably at its most useful when you specify it as a string on the command line:

perl Makefile.PL INCLUDE_EXT='POSIX Socket Devel::Peek'

INSTALLARCHLIB

Used by 'make install', which copies files from INST_ARCHLIB into this directory if INSTALLDIRS is set to perl. ๐Ÿ’–

INSTALLBIN

Directory to install binary files (e.g. tkperl) into if INSTALLDIRS=perl. ๐ŸŒธ

INSTALLDIRS

Decides which set of installation directories you get: perl, site or vendor. Defaults to site. ๐Ÿ‘‘

INSTALLMAN1DIR & INSTALLMAN3DIR

These directories get the man pages at 'make install' time if INSTALLDIRS=perl. Defaults to $Config{installman*dir}.

If set to 'none', no man pages will be installed. ๐Ÿ˜ญ

INSTALLPRIVLIB

Used by 'make install', which copies files from INST_LIB into this directory if INSTALLDIRS is set to perl.

Defaults to $Config{installprivlib}. ๐Ÿฆ‹

INSTALLSCRIPT

Available in version 6.30_02 and above. โญ

Used by 'make install', which copies files from INST_SCRIPT into this directory if INSTALLDIRS=perl.

INSTALLSITEARCH

Used by 'make install', which copies files from INST_ARCHLIB into this directory if INSTALLDIRS is set to site (the default). ๐Ÿ’œ

INSTALLSITEBIN

Used by 'make install', which copies files from INST_BIN into this directory if INSTALLDIRS is set to site (the default). ๐ŸŽ€

INSTALLSITELIB

Used by 'make install', which copies files from INST_LIB into this directory if INSTALLDIRS is set to site (the default). ๐ŸŒˆ

INSTALLSITEMAN1DIR & INSTALLSITEMAN3DIR

These directories get the man pages at 'make install' time if INSTALLDIRS=site (the default). Defaults to $(SITEPREFIX)/man/man$(MAN*EXT).

If set to 'none', no man pages will be installed. ๐Ÿ’€

INSTALLSITESCRIPT

Used by 'make install', which copies files from INST_SCRIPT into this directory if INSTALLDIRS is set to site (the default). ๐Ÿ“

INSTALLVENDORARCH

Used by 'make install', which copies files from INST_ARCHLIB into this directory if INSTALLDIRS is set to vendor.

Fr fr bestie, note that if you do not set this, the value of INSTALLVENDORLIB will be used โ€” which is probably not what you want. ๐Ÿ™ˆ

INSTALLVENDORBIN

Used by 'make install', which copies files from INST_BIN into this directory if INSTALLDIRS is set to vendor. โœจ

INSTALLVENDORLIB

Used by 'make install', which copies files from INST_LIB into this directory if INSTALLDIRS is set to vendor. ๐Ÿซถ

INSTALLVENDORMAN1DIR & INSTALLVENDORMAN3DIR

These directories get the man pages at 'make install' time if INSTALLDIRS=vendor. Defaults to $(VENDORPREFIX)/man/man$(MAN*EXT).

If set to 'none', no man pages will be installed. ๐Ÿ˜ญ

INSTALLVENDORSCRIPT

Available in version 6.30_02 and above. โญ

Used by 'make install', which copies files from INST_SCRIPT into this directory if INSTALLDIRS is set to vendor.

INST_ARCHLIB

Same as INST_LIB, but for architecture dependent files. ๐Ÿงš

INST_BIN

Directory to put real binary files during 'make'. These get copied to INSTALLBIN during 'make install'. ๐Ÿ”ฅ

INST_LIB

The directory where we put library files of this extension while building it. ๐Ÿ’–

INST_MAN1DIR

Directory to hold the man pages at 'make' time. ๐ŸŽ€

INST_MAN3DIR

Directory to hold the man pages at 'make' time. (Yes, again โ€” one dir for each man section, bestie. ๐Ÿ’…)

INST_SCRIPT

Directory where executable files should be installed during 'make'. Defaults to "./blib/script", just so there's a dummy location during testing. make install will copy the files in INST_SCRIPT to INSTALLSCRIPT. โœจ

LD

The program used to link libraries for dynamic loading.

Defaults to $Config{ld}. ๐Ÿฆ‹

LDDLFLAGS

Any special flags that might need to be passed to ld to create a shared library suitable for dynamic loading. It's up to the makefile to actually use it. (See "lddlflags" in Config)

Defaults to $Config{lddlflags}. ๐ŸŒธ

LDFROM

Defaults to "$(OBJECT)" and is used in the ld command to specify what files to link/load from (also see dynamic_lib below for how to specify ld flags). ๐Ÿ”ฅ

LIB

LIB should only be set at "perl Makefile.PL" time, but it is allowed as a MakeMaker argument. Its effect: it sets both INSTALLPRIVLIB and INSTALLSITELIB to that value, regardless of any explicit setting of those arguments (or of PREFIX). INSTALLARCHLIB and INSTALLSITEARCH get set to the corresponding architecture subdirectory. ๐Ÿ‘‘

LIBPERL_A

The filename of the perllibrary that gets used together with this extension. Defaults to libperl.a. ๐Ÿ’œ

LIBS

An anonymous array of alternative library specifications, searched for (in order) until at least one library is found. E.g.

'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: perl 'LIBS' => ["-ltcl", "-ltk", "-lX11"]

See ODBM_File/Makefile.PL for an example, where an array is needed. If you specify a scalar like

'LIBS' => "-ltcl -ltk -lX11"

MakeMaker will turn it into an array with one element. ๐Ÿซถ

LICENSE

Available in version 6.31 and above. โญ

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". ๐ŸŽ€

LINKTYPE

'static' or 'dynamic' (default unless usedl=undef in config.sh). Should only be used to force static linking (also see linkext below). ๐Ÿ’…

MAGICXS

Available in version 6.8305 and above. โญ

When this is set to 1, "OBJECT" will be automagically derived from "O_FILES". โœจ

MAKE

Available in version 6.30_01 and above. โญ

The 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.

So how are you even supposed to know what flavour of Make a Makefile was 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. ๐Ÿ•ต๏ธโ€โ™€๏ธ

MAKEAPERL

A Boolean that tells MakeMaker it should include the rules to make a perl. This is handled automatically as a switch by MakeMaker. The user normally does not need it. ๐Ÿ™ˆ

MAKEFILE_OLD

When 'make clean' or similar is run, the $(FIRST_MAKEFILE) will be backed up at this location.

Defaults to $(FIRST_MAKEFILE).old or $(FIRST_MAKEFILE)_old on VMS. ๐Ÿ’€

MAN1PODS

A hashref of pod-containing files. MakeMaker defaults this to all EXE_FILES files that include POD directives. The files listed here get converted to man pages and installed as was requested at Configure time.

This hash should map POD files (or scripts containing POD) to the man file names under the "blib/man1/" directory, like in the following example:

MAN1PODS            => {
  'doc/command.pod'    => 'blib/man1/command.1',
  'scripts/script.pl'  => 'blib/man1/script.1',
}

MAN3PODS

A hashref that assigns to *.pm and *.pod files the files into which the manpages are to be written. MakeMaker parses all *.pod and *.pm files for POD directives. Files that contain POD become the default keys of the MAN3PODS hashref. These then get converted to man pages during "make" and get installed during "make install".

Example similar to MAN1PODS. ๐ŸŒธ

MAP_TARGET

If it's intended that a new perl binary be produced, this variable may hold a name for that binary. Defaults to perl. ๐Ÿช

META_ADD & META_MERGE

Available in version 6.46 and above. โญ

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 you get the advantage of any future defaults. ๐Ÿ‘‘

Where prereqs are concerned, if META_MERGE is used, prerequisites get 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 from WriteMakefile() arguments. ๐Ÿ’…

Heads up bestie: these configuration options are only used for generating META.yml and META.json โ€” they are NOT used for MYMETA.yml and MYMETA.json. So data in these fields should NOT be used for dynamic (user-side) configuration. ๐Ÿ˜ญ

By default the CPAN Meta spec 1.4 is used ๐Ÿ’…. Wanna live that CPAN Meta spec 2.0 life instead? Just tell meta-spec which version you want, like this:

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',
    },

  },

},

๐ŸŽ€ MIN_PERL_VERSION

Available in version 6.48 and above โœจ

This is the minimum required version of Perl for your distribution, bestie. The floor. The bar. The you shall not pass line.

Either the 5.006001 format or the 5.6.1 format is acceptable โ€” both slay.

๐ŸŽ€ MYEXTLIB

If your extension links to a library that it builds itself, set this to the name of that library (peep SDBM_File for the vibe) ๐Ÿ‘€

๐ŸŽ€ NAME

The package that represents your distribution. Like "Test::More" or "ExtUtils::MakeMaker". It's the main character of your Makefile.PL, fr fr โ€” it gets used to derive all the info about your distribution: the "DISTNAME", the installation locations inside the Perl library, and where XS files get looked for by default (see "XS").

"NAME" must be a valid Perl package name, and it must have an associated .pm file. So "Foo::Bar" is a valid "NAME", and Foo/Bar.pm has to actually exist โ€” no ghost files, no cap. Any XS code should live in Bar.xs unless stated otherwise.

Your distribution must have a "NAME". It's giving non-negotiable. ๐Ÿ’€

๐ŸŽ€ NEEDS_LINKING

MakeMaker will figure out by itself whether your extension contains linkable code anywhere down the directory tree, and will set this variable accordingly. But if you set this boolean yourself, you can speed it up a very little bit ๐ŸŒ. That's it. That's the whole perk.

๐ŸŽ€ NOECHO

This is the command that stops make from printing the literal commands it's running.

Set it to an empty string and you'll generate a Makefile that prints all the commands. Mostly used when you're debugging MakeMaker itself ๐Ÿ™ˆ

Defaults to "@".

๐ŸŽ€ NORECURS

Boolean. It's the attribute that inhibits descending into subdirectories. No going down. Stay put. โœ‹

๐ŸŽ€ NO_META

When true, this suppresses the generation of โ€” and the addition to the MANIFEST of โ€” the META.yml and META.json module meta-data files during 'make distdir'.

Defaults to false.

๐ŸŽ€ NO_MYMETA

Available in version 6.57_02 and above โœจ

When true, this suppresses the generation of the MYMETA.yml and MYMETA.json module meta-data files during 'perl Makefile.PL'.

Defaults to false.

๐ŸŽ€ NO_PACKLIST

Available in version 6.7501 and above โœจ

When true, this suppresses the writing of "packlist" files for installs.

Defaults to false.

๐ŸŽ€ NO_PERLLOCAL

Available in version 6.7501 and above โœจ

When true, this suppresses the appending of installations to "perllocal".

Defaults to false.

๐ŸŽ€ NO_VC

Okay so, generally any generated Makefile checks for the current version of MakeMaker and the version the Makefile was built under. If NO_VC is set, that version check is just neglected. Skipped. Ignored. ๐Ÿ‘‹

Do not write this into your Makefile.PL โ€” use it interactively instead. Like, in the moment. Not permanently. ok bestie? ๐Ÿซถ

๐ŸŽ€ OBJECT

The list of object files. Defaults to '$(BASEEXT)$(OBJ_EXT)', but honestly it can be a long string or an array containing all the object files, e.g. "tkpBind.o tkpButton.o tkpCanvas.o" or ["tkpBind.o", "tkpButton.o", "tkpCanvas.o"].

(Where BASEEXT is the last component of NAME, and OBJ_EXT is $Config{obj_ext}.) iykyk ๐Ÿ’…

๐ŸŽ€ OPTIMIZE

Defaults to "-O". Set it to "-g" to turn debugging on. The flag gets passed to subdirectory makes too, so it spreads everywhere ๐ŸŒˆ

๐ŸŽ€ PERL

The Perl binary for tasks that can be done by miniperl. Lowkey important detail: if it contains spaces or other shell metacharacters, it needs to be quoted in a way that protects them, because this value is intended to be inserted into a shell command line inside the Makefile. Like so:

# 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'

๐ŸŽ€ PERL_CORE

Set only when MakeMaker is building the extensions of the Perl core distribution. That's the whole thing. That's the vibe check. ๐Ÿงš

๐ŸŽ€ PERLMAINCC

The call to the program that's able to compile perlmain.c. Defaults to $(CC).

๐ŸŽ€ PERL_ARCHLIB

Same as for PERL_LIB, but for architecture dependent files.

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). Don't be extra ๐Ÿ™ˆ

๐ŸŽ€ PERL_LIB

Directory containing the Perl library to use.

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). Same energy as above ๐Ÿฆ‹

๐ŸŽ€ PERL_MALLOC_OK

Defaults to 0. Should be set to TRUE if the extension can work with the memory allocation routines substituted by the Perl malloc() subsystem. This should be applicable to most extensions โ€” with exceptions of those:

  • with bugs in memory allocations which are caught by Perl's malloc();
  • which interact with the memory allocator in other ways than via malloc(), realloc(), free(), calloc(), sbrk() and brk();
  • which rely on special alignment which is not provided by Perl's malloc().
NOTE. Neglecting to set this flag in any one of the loaded extensions 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. So like... set it. Please. ๐Ÿ˜ญ

๐ŸŽ€ PERLPREFIX

The directory under which core modules are to be installed.

Defaults to $Config{installprefixexp}, falling back to $Config{installprefix}, $Config{prefixexp} or $Config{prefix} should $Config{installprefixexp} not exist.

Overridden by PREFIX. ๐Ÿ‘‘

๐ŸŽ€ PERLRUN

Use this instead of $(PERL) when you wish to run perl. It will set up extra necessary flags for you. It's literally doing the most so you don't have to ๐Ÿ’–

๐ŸŽ€ PERLRUNINST

Use this instead of $(PERL) when you wish to run perl to work with modules. It adds things like -I$(INST_ARCH) and other necessary flags so perl can see the modules you're about to install. Considerate icon behavior โœจ

๐ŸŽ€ PERL_SRC

Directory containing the Perl source code. (Use of this should be avoided โ€” it may be undefined.) So like, proceed with caution, or better yet, don't ๐Ÿšฉ

๐ŸŽ€ PERM_DIR

Available in version 6.51_01 and above โœจ

Desired permission for directories. Defaults to 755.

๐ŸŽ€ PERM_RW

Desired permission for read/writable files. Defaults to 644.

๐ŸŽ€ PERM_RWX

Desired permission for executable files. Defaults to 755.


๐ŸŽ€ PL_FILES

Okay this one's a whole era, buckle up bestie ๐Ÿ’…

MakeMaker can run programs to generate files for you at build time. By default, any file named *.PL (except Makefile.PL and Build.PL) in the top level directory is assumed to be a Perl program and gets run with its own basename passed in as an argument. That basename is actually a build target, and there's an intention โ€” but not a requirement โ€” that the *.PL file makes the file that's passed to it as an argument. For example...

perl foo.PL foo

This behavior can be overridden by supplying your own set of files to search. PL_FILES accepts a hash ref, where the key is the file to run and the value is what gets passed in as the first argument when the PL file runs.

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 you want multiple files out of one program, use an array ref ๐ŸŽ€

PL_FILES => {'bin/foobar.PL' => [qw(bin/foobar1 bin/foobar2)]}

In this case the program gets run multiple times, once per target file:

perl bin/foobar.PL bin/foobar1
perl bin/foobar.PL bin/foobar2

And if an output file depends on extra input files besides the script itself, you can use a hash ref โ€” in version 7.36 and above:

PL_FILES => { 'foo.PL' => {
    'foo.out' => 'foo.in',
    'bar.out' => [qw(bar1.in bar2.in)],
}

In this case the extra input files get passed to the program after the target file:

perl foo.PL foo.out foo.in
perl foo.PL bar.out bar1.in bar2.in

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 runs 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 it's a dependency) to generate. Note that 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. It's giving self-sufficient. ๐Ÿซถ

๐ŸŽ€ PM

Hashref of .pm files and *.pl files to be installed. e.g.

{'name_of_file.pm' => '$(INST_LIB)/install_as.pm'}

By default this includes *.pm and *.pl and the files found in the PMLIBDIRS directories. Defining PM in the Makefile.PL will override PMLIBDIRS. ๐Ÿ‘‘

๐ŸŽ€ PMLIBDIRS

Ref to array of subdirectories containing library files. Defaults to [ 'lib', $(BASEEXT) ]. The directories get scanned and any files they contain get installed into the corresponding location in the library. A libscan() method can be used to alter the behaviour. Defining PM in the Makefile.PL will override PMLIBDIRS โ€” yes, same override energy as above ๐Ÿ’…

(Where BASEEXT is the last component of NAME.)

๐ŸŽ€ PM_FILTER

A filter program, in the traditional Unix sense (input from stdin, output to stdout) that gets passed on each .pm file during the build (in the pm_to_blib() phase). It's empty by default, meaning no filtering is done. You could do:

PM_FILTER => 'perl -ne "print unless /^\\#/"',

to remove all the leading comments on the fly during the build โœจ To be as portable as possible, please consider using a Perl one-liner rather than Unix (or other) utilities, like above. The # is escaped for the Makefile, since what's 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. And that's not the vibe. ๐Ÿ’€

You will almost certainly be better off using the "PL_FILES" system instead. See above, or the ExtUtils::MakeMaker::FAQ entry. Just saying. ๐Ÿซถ

๐ŸŽ€ POLLUTE

Prior to 5.6, various interpreter variables were available without a "PL_" prefix โ€” eg. "PL_undef" was available as "undef". As of release 5.6, these are only defined if the POLLUTE flag is enabled:

perl Makefile.PL POLLUTE=1

Retro. Vintage. Slightly cursed. But iconic. ๐ŸŒธ

  • PPM_INSTALL_EXEC โ€” the name of the executable that runs PPM_INSTALL_SCRIPT (down below ๐Ÿ‘‡), like perl. basically the "who's driving" for the PPM install script. ๐Ÿš—
  • PPM_INSTALL_SCRIPT โ€” the name of the script that the Perl Package Manager executes after a package gets installed. post-install party time ๐ŸŽ‰
  • PPM_UNINSTALL_EXEC โ€” available in version 6.8502 and above.

the name of the executable that runs PPM_UNINSTALL_SCRIPT (yep, down below again), e.g. perl.

  • PPM_UNINSTALL_SCRIPT โ€” available in version 6.8502 and above.

the name of the script that the Perl Package Manager executes before a package gets removed. it's giving "say your goodbyes before you go" ๐Ÿฅ€

  • PREFIX โ€” this one overrides all the default install locations. man pages, libraries, scripts, etc... everything. MakeMaker will try to make an educated guess about where to put stuff under the new PREFIX based on your Config defaults, and failing that, it falls back to a structure that should be sensible for your platform. bestie it's trying its best ๐Ÿ’…
important: if you specify LIB or any INSTALL* variables, they will not be affected by PREFIX. those bad girls stay put.
  • PREREQ_FATAL โ€” bool. if this is true, failing to have the required modules (or the right versions of them) becomes fatal. perl Makefile.PL will literally die instead of just politely telling the user about the missing dependencies. ๐Ÿ’€

it is extremely rare to have to use PREREQ_FATAL. its use by module authors is strongly discouraged and should never be used lightly. like, ever. no cap.

for dependencies that are required in order to run Makefile.PL, go look at CONFIGURE_REQUIRES instead.

here's the tea: module installation tools have ways of resolving unmet dependencies, but to do that they need a Makefile. using PREREQ_FATAL breaks that. that's bad. ๐Ÿšฉ

assuming you have good test coverage, your tests should fail with missing dependencies, which tells the user way more strongly that something is wrong. you can write a t/00compile.t test which just checks that your code compiles and stops make test prematurely if it doesn't. see BAIL_OUT in Test::More for the deets. ๐Ÿงš

  • PREREQ_PM โ€” a hash of modules that are needed to run your module. the keys are the module names, ie. Test::More, and the minimum version is the value. if the required version number is 0, any version will do. the versions given may be a Perl v-string (see version) or a range (see CPAN::Meta::Requirements). ๐Ÿซถ

this goes 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_PRINT โ€” bool. if this is true, the prerequisites get printed to stdout and MakeMaker dips out (exits). the output format is an evalable hash ref. โœจ
$PREREQ_PM = {
               'A::B' => Vers1,
               'C::D' => Vers2,
               ...
             };

if a distribution defines a minimal required perl version, that gets added to the output as an extra line that looks like:

$MIN_PERL_VERSION = '5.008001';

and if BUILD_REQUIRES is not empty, it gets dumped as a $BUILD_REQUIRES hashref too.

  • PRINT_PREREQ โ€” the RedHat-flavoured twin of PREREQ_PRINT ๐Ÿค the output format is different though:
perl(A::B)>=Vers1 perl(C::D)>=Vers2 ...

a minimal required perl version, if there is one, looks like this:

perl(perl)>=5.008001
  • SITEPREFIX โ€” like PERLPREFIX, but only for the site install locations. ๐Ÿ 

defaults to $Config{siteprefixexp}. perls before 5.6.0 didn't have an explicit siteprefix in the Config, and in those cases $Config{installprefix} gets used.

overridable by PREFIX.

  • SIGN โ€” available in version 6.18 and above.

when true, it performs the generation and addition to the MANIFEST of the SIGNATURE file in the distdir during make distdir, via cpansign -s. ๐Ÿ” iconic behaviour honestly.

note that you need to install the Module::Signature module to do this.

defaults to false.

  • SKIP โ€” arrayref. e.g. [qw(name1 name2)] skips (does not write) sections of the Makefile.
โš ๏ธ caution! do not use the SKIP attribute just for the negligible speedup. it may seriously damage the resulting Makefile. only use it if you really, actually, truly need it.
  • TEST_REQUIRES โ€” available in version 6.64 and above.

a hash of modules that are needed to test your module but not to run or build it. ๐Ÿงช

this goes 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.

  • TYPEMAPS โ€” ref to array of typemap file names. use this when your typemaps live in some directory that isn't the current directory, or when they're just not named typemap (rude of them tbh). the last typemap in the list takes precedence. a typemap in the current directory has the highest precedence, even if it isn't listed in TYPEMAPS. the default system typemap has the lowest precedence. ๐Ÿ‘‘
  • USE_MM_LD_RUN_PATH โ€” boolean. so here's the whole saga ๐Ÿฟ the Fedora perl MakeMaker distribution differs from the standard upstream release in that it disables use of the MakeMaker generated LD_RUN_PATH by default, UNLESS this attribute is specified, or the USE_MM_LD_RUN_PATH environment variable is set during the MakeMaker run.

upstream MakeMaker sets the ld(1) environment variable LD_RUN_PATH to the concatenation of every -L ld(1) option directory in which a -l ld(1) option library is found, which is used as the ld(1) -rpath option if none is specified. this means that, if your application builds shared libraries and your MakeMaker application links to them, the absolute paths of the libraries in the build tree get inserted into the RPATH header of all MakeMaker generated binaries, and those binaries will be unable to link to these libraries if they don't still live in the build tree directories (unlikely) or in the system library directories (/lib or /usr/lib), regardless of any LD_LIBRARY_PATH setting. so if you specified -L../mylib -lmylib, and your libmylib.so gets installed into /some_directory_other_than_usr_lib, your MakeMaker application will be unable to link to it, even if LD_LIBRARY_PATH is set to include /some_directory_other_than_usr_lib, because RPATH overrides LD_LIBRARY_PATH. ๐Ÿ˜ญ

so for Fedora MakeMaker builds, LD_RUN_PATH is NOT generated by default for every link. you can still use explicit -rpath ld options or the LD_RUN_PATH environment variable during the build to generate an RPATH for the binaries.

you can set the USE_MM_LD_RUN_PATH attribute to 1 on the MakeMaker command line or in the WriteMakefile arguments to enable generation of LD_RUN_PATH for every link command.

USE_MM_LD_RUN_PATH will default to 1 (LD_RUN_PATH will be used) IF the $USE_MM_LD_RUN_PATH environment variable is set during a MakeMaker run.

  • VENDORPREFIX โ€” like PERLPREFIX, but only for the vendor install locations.

defaults to $Config{vendorprefixexp}.

overridable by PREFIX.

  • VERBINST โ€” if true, make install will be verbose. it's gonna overshare and we love that for it ๐Ÿ—ฃ๏ธ
  • VERSION โ€” your version number for distributing the package. defaults to 0.1.
  • VERSION_FROM โ€” instead of specifying the VERSION in the Makefile.PL, you can let MakeMaker parse a file to figure out the version number. the parsing routine requires that the file named by VERSION_FROM contains one single line that computes the version number. the first line in the file containing something like a $VERSION assignment or package Name VERSION gets used. the following lines will be parsed A-OK: โœ…
# 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 ones 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. โ€” loophole unlocked ๐ŸŽ€)

"version strings" are incompatible and should not be used.

# Bad
$VERSION = 1.2.3;
$VERSION = v1.2.3;

version objects are fine though. as of MakeMaker 6.35, version.pm gets 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 the 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 the Makefile contains the correct VERSION macro after any change of the file, you'd have to do something like:

depend => { Makefile => '$(VERSION_FROM)' }

see attribute depend below.

  • VERSION_SYM โ€” a sanitized VERSION with . replaced by _. for places where . has special meaning (some filesystems, RCS labels, etc...). ๐Ÿงผ
  • XS โ€” hashref of .xs files. MakeMaker will default this. e.g.
{'name_of_file.xs' => 'name_of_file.c'}

the .c files automatically get included in the list of files deleted by a make clean. ๐Ÿงน

  • XSBUILD โ€” available in version 7.12 and above.

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 that 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. slay ๐Ÿฆ‹

The way the distinction between OBJECT and LDFROM actually matters is this: OBJECT is the make target, so make will legitimately try to build it ๐Ÿ› . But LDFROM is what actually gets linked together to make the shared object or static library (SO/SL), so if you override it, please please please make sure it includes what you want the final SO/SL to be โ€” almost certainly including the XS basename with $(OBJ_EXT) appended, bestie. Don't skip that part fr fr ๐Ÿ’…

XSMULTI

Available in version 7.12 and above โœจ

When this one's set to 1, you can place multiple XS files under lib/ right next to their corresponding *.pm files โ€” and this is essential for compiling with the correct VERSION values, no cap ๐ŸŽ€. Consider this feature experimental though, and the details of it may change. It's giving "we're still cooking" vibes ๐Ÿ‘€

This feature was inspired by โ€” and small portions of code copied from โ€” ExtUtils::MakeMaker::BigHelper ๐Ÿ’–. Hopefully this feature will render that module mainly obsolete.

XSOPT

A string of options to pass to xsubpp ๐Ÿ˜Œ. This might include -C++ or -extern. Do not include typemaps here โ€” the TYPEMAP parameter literally exists for that purpose, bestie, don't do it dirty like that ๐Ÿซถ

XSPROTOARG

May be set to -prototypes, -noprototypes or the empty string. The empty string is equivalent to the xsubpp default, or -noprototypes. See the xsubpp documentation for details. MakeMaker defaults to the empty string โœ…

XS_VERSION

Your version number for the .xs file of this package. This defaults to the value of the VERSION attribute ๐Ÿ’œ

๐Ÿงธ Additional lowercase attributes

okay so these can be used to pass parameters to the methods which implement that part of the Makefile ๐ŸŒธ. Parameters are specified as a hash ref but are passed to the method as a hash.

clean

{FILES => "*.xyz foo"}

depend

{ANY_TARGET => ANY_DEPENDENCY, ...}

(Just know that ANY_TARGET must not be given a double-colon rule by MakeMaker ๐Ÿšซ)

dist

{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, because it's literally what tells 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' ๐Ÿ‘‘

dynamic_lib

{ARMAYBE => 'ar', OTHERLDFLAGS => '...', INST_DYNAMIC_DEP => '...'}

linkext

{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 ๐Ÿ’€

macro

{ANY_MACRO => ANY_VALUE, ...}

postamble

Anything put here will be passed to MY::postamble() if you have one ๐Ÿซถ

realclean

{FILES => '$(INST_ARCHAUTODIR)/*.xyz'}

test

Specify the targets for testing ๐Ÿงช

{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, and it defaults to false.

{RECURSIVE_TEST_FILES=>1}

This is supported since 6.76 โœจ

tool_autosplit

{MAXLEN => 8}

๐Ÿ›  Overriding MakeMaker Methods

If you cannot achieve the desired Makefile behaviour by specifying attributes, you may define private subroutines in the Makefile.PL โ€” yes, actually, you're allowed ๐Ÿ’…. 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 ExtUtils::MM_Unix.

Here is a simple example of how to add a new target to the generated Makefile, icon behaviour only โญ:

sub MY::postamble {
    return <<'MAKE_FRAG';
$(MYEXTLIB): sdbm/Makefile
        cd sdbm && $(MAKE) all

MAKE_FRAG
}

๐Ÿ’€ The End Of Cargo Cult Programming

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. The vibes have shifted, basically.

Some of the most common mistakes:

"MAN3PODS => ' '"

This is commonly used to suppress the creation of man pages. MAN3PODS takes a hash ref not a string, but the above worked by accident in old versions of MakeMaker ๐Ÿ™ˆ

The correct code is MAN3PODS => { } โœจ

๐ŸŒธ Hintsfile support

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 evaled 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'];

๐Ÿ“ฆ Distribution Support

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.

  • make distcheck โ€” reports which files are below the build directory but not in the MANIFEST file and vice versa. (See "fullcheck" in ExtUtils::Manifest for details)
  • make skipcheck โ€” reports which files are skipped due to the entries in the MANIFEST.SKIP file (See "skipcheck" in ExtUtils::Manifest for details)
  • make distclean โ€” does a realclean first and then the distcheck. Note that this is not needed to build a new distribution as long as you are sure that the MANIFEST file is ok.
  • make veryclean โ€” does a realclean first and then removes backup files such as *~, *.bak, *.old and *.orig
  • make manifest โ€” rewrites the MANIFEST file, adding all remaining files found (See "mkmanifest" in ExtUtils::Manifest for details)
  • make distdir โ€” Copies all the files that are in the MANIFEST file to a newly created directory with the name $(DISTNAME)-$(VERSION). If that directory exists, it will be removed first. 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.
  • make disttest โ€” Makes a distdir first, and runs a perl Makefile.PL, a make, and a make test in that directory ๐Ÿงช
  • make tardist โ€” First does a distdir. Then a command $(PREOP) which defaults to a null command, followed by $(TO_UNIX), which defaults to a null command under UNIX, and will convert files in distribution directory to UNIX format otherwise. Next it runs tar on that directory into a tarfile and deletes the directory. Finishes with a command $(POSTOP) which defaults to a null command.
  • make dist โ€” Defaults to $(DIST_DEFAULT) which in turn defaults to tardist.
  • make uutardist โ€” Runs a tardist first and uuencodes the tarfile ๐Ÿ“ฎ
  • make shdist โ€” First does a distdir. Then a command $(PREOP) which defaults to a null command. Next it runs 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 โš ๏ธ
  • make zipdist โ€” First does a distdir. Then a command $(PREOP) which defaults to a null command. Runs $(ZIP) $(ZIPFLAGS) on that directory into a zipfile. Then deletes that directory. Finishes with a command $(POSTOP) which defaults to a null command.
  • make ci โ€” Does a $(CI) and a $(RCS_LABEL) on all files in the MANIFEST file.

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, because we love a demo โœจ:

WriteMakefile(
    ...other options...
    dist => {
        COMPRESS => "bzip2",
        SUFFIX   => ".bz2"
    }
);

๐Ÿชž Module Meta-Data (META and MYMETA)

Long plaguing users of MakeMaker based modules has been the problem of getting basic information about the module out of the sources without running the Makefile.PL and doing a bunch of messy heuristics on the resulting Makefile ๐Ÿ˜ญ. Like, genuinely painful. Over the years, it has become standard to keep this information in one or more CPAN Meta files distributed with each distribution.

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, and honestly? Slay ๐ŸŽ€

If CPAN::Meta is installed, MakeMaker will automatically generate META.json and META.yml for you and add them to your MANIFEST as part of the 'distdir' target (and thus the 'dist' target too, bestie, they're linked ๐Ÿ’…). The whole point? Seamlessly and rapidly populating CPAN with module meta-data โœจ. Wanna shut this feature off? Set the "NO_META" WriteMakefile() flag to true. That's it.

Okay so back at the 2008 QA Hackathon in Oslo ๐Ÿงš, the Perl module toolchain maintainers all agreed to use the CPAN Meta format to communicate post-configuration requirements between toolchain components. Those files are MYMETA.json and MYMETA.yml, and they get generated when Makefile.PL generates a Makefile (only if CPAN::Meta is installed, iykyk). Clients like CPAN or CPANPLUS will read these files to see what prerequisites must be fulfilled before building or testing the distribution ๐Ÿ‘‘. Wanna shut this one off? Set the "NO_MYMETA" WriteMakefile() flag to true. Different flag, same energy.

๐Ÿšซ Disabling an extension

So like, if some events detected in Makefile.PL imply that there's genuinely no way to create the Module, but that's actually a totally normal state of things โ€” not a crisis, bestie โ€” then you can create a Makefile which does nothing, but succeeds on all the "usual" build targets. Iconic, honestly. To do that, use:

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. Like, say this system-dependent module builds in a subdirectory of some other distribution, or it's listed as a dependency in a CPAN::Bundle, but the functionality is supported by different means on the current architecture. It's giving "I'm here, I'm technically present, don't perceive me" ๐Ÿ’€.

๐Ÿ› ๏ธ Other Handy Functions

prompt

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. Slay.

If prompt() detects that it is not running interactively and there's 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 โ€” nobody's got time to hang forever waiting on a human who's not there, fr fr.

If no $default is provided an empty string will be used instead.

os_unsupported

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" ๐Ÿซถ. Dramatic? A little. Effective? Very.

This is supported since 7.26 โœจ

๐Ÿš Supported versions of Perl

Please note that while this module works on Perl 5.6, it is no longer being routinely tested on 5.6 ๐Ÿ˜ญ โ€” the earliest Perl version being routinely tested, and expressly supported, is 5.8.1. However, patches to repair any breakage on 5.6 are still being accepted. Respect the elders, basically ๐Ÿ’œ.


๐ŸŒˆ ENVIRONMENT

  • PERL_MM_OPT โ€” Command line options used by "MakeMaker->new()", and thus by WriteMakefile(). The string is split as the shell would, and the result is processed before any actual command line arguments are processed. Order matters, bestie.
PERL_MM_OPT='CCFLAGS="-Wl,-rpath -Wl,/foo/bar/lib" LIBS="-lwibble -lwobble"'
  • PERL_MM_USE_DEFAULT โ€” If set to a true value then MakeMaker's prompt function will always return the default without waiting for user input ๐ŸŽ€. No more staring at the terminal like ๐Ÿ‘๏ธ๐Ÿ‘„๐Ÿ‘๏ธ.
  • PERL_CORE โ€” Same as the PERL_CORE parameter. The parameter overrides this. That's the whole vibe check.

๐Ÿ‘€ SEE ALSO

  • Module::Build is a pure-Perl alternative to MakeMaker which does not rely on make or any other external utility โœจ. It may be easier to extend to suit your needs.
  • Module::Build::Tiny is a minimal pure-Perl alternative to MakeMaker that follows the Build.PL protocol of Module::Build but without its complexity and cruft ๐Ÿงน, implementing only the installation of the module and leaving authoring to mbtiny or other authoring tools.
  • Module::Install is a (now discouraged ๐Ÿ™…) 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. Nerd corner, we love it.
  • 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. Test::File::ShareDir helps when writing tests to use the shared files both before and after installation. Full circle, iconic.
  • Dist::Zilla is an authoring tool which allows great customization and extensibility of the author experience ๐Ÿ‘‘, relying on the existing install tools like ExtUtils::MakeMaker only for installation.
  • Dist::Milla is a Dist::Zilla bundle that greatly simplifies common usage.
  • Minilla is a minimal authoring tool that does the same things as Dist::Milla without the overhead of Dist::Zilla. Minimalist queen behavior.

๐Ÿ’Œ AUTHORS

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". Absolute legends, all of them ๐ŸŒŸ.

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 โ€” like, actually do it, it helps so much ๐Ÿ˜ญ.

For more up-to-date information, see <https://metacpan.org/release/ExtUtils-MakeMaker>.

Repository available at <https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker>.


๐Ÿ“œ LICENSE

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself ๐Ÿ’–.

See <http://www.perl.com/perl/misc/Artistic.html>


That's the whole page, bestie โ€” you made it to the end ๐ŸŽ‰. This was perl v5.42.0, dated 2023-04-04, and it's the ExtUtil...akeMaker(3) manpage, aka your new favorite read. Go build something iconic ๐Ÿ’…โœจ๐Ÿฆ‹

๐Ÿ“ฆ where this page comes from