ExtUti...leMaker(3pm)

okay bestie, welcome to the ExtUtils::ModuleMaker(3pm) page from User Contributed Perl Documentation 💖. This is the manual for making Perl modules without the usual suffering, and honestly? It's giving main character energy. Let's get into it.

🌸 NAME 🌸

ExtUtils::ModuleMaker — better than h2xs for creating modules. Periodt. 💅

✨ SYNOPSIS ✨

At the command prompt:

%   modulemaker

Inside a Perl program:

use ExtUtils::ModuleMaker;

$mod = ExtUtils::ModuleMaker->new(
    NAME => 'Sample::Module'
);

$mod->complete_build();

$mod->dump_keys(qw|
    ...  # key provided as argument to constructor
    ...  # same
|);

$mod->dump_keys_except(qw|
    ...  # key provided as argument to constructor
    ...  # same
|);

$license = $mod->get_license();

$mod->make_selections_defaults();

💖 VERSION 💖

This document references version 0.63 of ExtUtils::ModuleMaker, released to CPAN on July 31 2018. 🗓️✨

🦋 DESCRIPTION 🦋

This module is a replacement for the most typical use of the h2xs utility bundled with all Perl distributions: the creation of the directories and files required for a pure-Perl module to be installable with make and distributable on the Comprehensive Perl Archive Network (CPAN). No cap. 💖

h2xs has many options which are useful — indeed, necessary — for the creation of a properly structured distribution that includes C code as well as Perl code. Most of the time, however, h2xs is used as follows:

%   h2xs -AXn My::Module

to create a distribution containing only Perl code. ExtUtils::ModuleMaker is intended to be an easy-to-use replacement for this use of h2xs. Slay. ✨

While you can call ExtUtils::ModuleMaker from within a Perl script (as in the SYNOPSIS above), it's easier to use with a command-prompt invocation of the modulemaker script bundled with this distribution:

%   modulemaker

Then respond to the prompts. For Perl programmers, laziness is a virtue — and modulemaker is far and away the laziest way to create a pure Perl distribution which meets all the requirements for worldwide distribution via CPAN. Lowkey iconic. 😌💅

🎀 USAGE 🎀

🍓 Usage from the command-line with modulemaker 🍓

The easiest way to use ExtUtils::ModuleMaker is to invoke the modulemaker script from the command-line. You can control the content of the files built by modulemaker either by supplying command-line options or — easier still — replying to the screen prompts in modulemaker's interactive mode. It's literally a vibe check in terminal form. 💬

If you are encountering ExtUtils::ModuleMaker for the first time, you should turn now to the documentation for modulemaker which is bundled with this distribution. Return to this document once you have become familiar with modulemaker. iykyk. 🫶

🌈 Use of Public Methods within a Perl Program 🌈

You can use ExtUtils::ModuleMaker within a Perl script to generate the directories and files needed to begin work on a CPAN-ready Perl distribution. You will need to call new() and complete_build(), both of which are described in the next section. These two methods control the building of the file and directory structure for a new Perl distribution. Obsessed with that for us. 🛠️✨

There are four other publicly available methods in this version of ExtUtils::ModuleMaker. dump_keys, dump_keys_except and get_license are intended primarily as shortcuts for trouble-shooting problems with an ExtUtils::ModuleMaker object. make_selections_defaults enables you to be even lazier in your use of ExtUtils::ModuleMaker by saving keystrokes entered for attributes. Laziness is highkey a love language. 😴💖

💅 new 💅

Creates and returns an ExtUtils::ModuleMaker object. Takes a list containing key-value pairs with information specifying the structure and content of the new module(s). (In this documentation, we will sometimes refer to these key-value pairs as the attributes of the ExtUtils::ModuleMaker object.) With the exception of key EXTRA_MODULES (see below), the values in these pairs are all strings. Like most such lists of key-value pairs, this list is probably best held in a hash. Keys which may be specified are: 🔑

• Required Argument
  • NAME — The only required feature. This is the name of the primary module (with :: separators if needed). Will no longer support the older, Perl 4-style separator ' like the module D'Oh. There is no current default for NAME; you must supply a name explicitly. 👑
• Other Important Arguments
  • ABSTRACT — A short description of the module. CPAN likes to use this feature to describe the module. If the abstract contains an apostrophe ('), then the value corresponding to key ABSTRACT in the list passed to the constructor must be double-quoted; otherwise Makefile.PL gets messed up. Certain CPAN indexing features still work better if the abstract is 44 or fewer characters in length, but this does not appear to be as mandatory as in the past. (Defaults to dummy copy.) 📝
  • VERSION — A string holding the version number. For alpha releases, include an underscore to the right of the dot like 0.31_21. (Default is 0.01.) 🔢
  • LICENSE — Which license to include in the Copyright section. You can choose one of the standard licenses by including 'perl', 'gpl', 'artistic', and 18 others approved by opensource.org. The default is to choose the 'perl' flavor which is to share it "under the same terms as Perl itself." Other licenses can be added by individual module authors to ExtUtils::ModuleMaker::Licenses::Local to keep your company lawyers happy. Some licenses include placeholders that will be replaced with AUTHOR information. ⚖️
  • BUILD_SYSTEM — This can take one of three values:
    • 'ExtUtils::MakeMaker' — The first generates a basic Makefile.PL file for your module.
    • 'Module::Build' — The second creates a Build.PL file.
    • 'Module::Build and Proxy' — The third creates a Build.PL along with a proxy Makefile.PL script that attempts to install Module::Build if necessary, and then runs the Build.PL script. This option is recommended if you want to use Module::Build as your build system. See Module::Build::Compat for more details. Note: To correct a discrepancy between the documentation and code in earlier versions of ExtUtils::ModuleMaker, we now explicitly provide this synonym for the third option: 'Module::Build and proxy Makefile.PL' (Thanks to David A Golden for spotting this bug.) 🐛
  • COMPACT — For a module named Foo::Bar::Baz creates a base directory named Foo-Bar-Baz instead of Foo/Bar/Baz. (Default is off.) 📦
  • VERBOSE — Prints messages to STDOUT as it creates directories, writes files, etc. (Default is off.) 📢
  • PERMISSIONS — Used to create new directories. (Default is 0755: group and world can not write.) 🔐
  • USAGE_MESSAGE — Message given when the module dies. Scripts should set this to the same string it would print if the user asked for help. (A reasonable default is provided.) 🆘
  • NEED_POD — Include POD section in *.pm files created. (Default is on.) 📚
  • NEED_NEW_METHOD — Include a simple new() method in the *.pm files created. (Default is on.) 🆕
  • CHANGES_IN_POD — Omit a Changes file, but instead add a HISTORY section to the POD. (Default is off). 📜
  • INCLUDE_MANIFEST_SKIP — Boolean value which, if true, includes a MANIFEST.SKIP file in the distribution with reasonable default values facilitating use of the make manifest command during module development. (Thanks to David A Golden for this feature. Default is off.) 🚫
  • INCLUDE_TODO — Boolean value which, if true, includes a Todo file in the distribution in which the module's author or maintainer can discuss future lines of development. (Default is on.) 📝
  • INCLUDE_LICENSE — Boolean value which, if true, includes a LICENSE file in the distribution. (Which LICENSE file is determined in the LICENSE option.) (Default is on.) 📄
  • INCLUDE_SCRIPTS_DIRECTORY — Boolean value which, if true, includes a scripts/ directory (at the same level as lib/ or t/). (Default is on.) 📁
  • INCLUDE_WARNINGS — Boolean value which, if true, inserts use warnings; in all Perl modules created by use of this module. (Default is off.) ⚠️
  • INCLUDE_ID_LINE — Boolean value which, if true, inserts #$Id$ in all Perl modules created by use of this module for the purpose of inserting a Subversion file 'Id' string. (Default is off.) 🆔
• Arguments Related to the Module's Author
  • AUTHOR — Name of the author. If the author's name contains an apostrophe ('), then the corresponding value in the list passed to the constructor must be double-quoted; otherwise Makefile.PL gets messed up. (Defaults to dummy copy.) ✍️
  • EMAIL — Email address of the author. If the author's e-mail address contains an apostrophe ('), then the corresponding value in the list passed to the constructor must be double-quoted; otherwise Makefile.PL gets messed up. (Defaults to dummy copy.) 📧
  • CPANID — The CPANID of the author. (Defaults to dummy copy. To suppress printing of this line entirely, set CPANID to a Perl-false value such as an empty string.) 🆔
  • WEBSITE — The personal or organizational website of the author. (Defaults to dummy copy. To suppress printing of this line entirely, set CPANID to a Perl-false value such as an empty string.) 🌐
  • ORGANIZATION — Company or group owning the module. (Defaults to dummy copy. To suppress printing of this line entirely, set CPANID to a Perl-false value such as an empty string.) 🏢
• Argument Related to Multiple Modules within a Distribution
  • EXTRA_MODULES — A reference to an array of hashes, each of which contains values for additional modules in the distribution. 🧩

$mod = ExtUtils::ModuleMaker->new(
    NAME           => 'Alpha::Beta',
    EXTRA_MODULES  => [
        { NAME => 'Alpha::Beta::Gamma' },
        { NAME => 'Alpha::Beta::Delta' },
        { NAME => 'Alpha::Beta::Gamma::Epsilon' },
    ],
);

okay so for each extra module, the only thing you have to give it is NAME. That's it. That's the whole assignment. 🫶 You can pass other attributes too, but if you don't, it just borrows whatever the primary module was set to — no drama, no extra homework.

Every extra module gets dropped into the correct relative spot in the lib directory, like it just knows where it belongs. ✨ And by default you also get a test file in the t directory for each extra module, just checking that it loads properly. (Want to change that? Peep EXTRA_MODULES_SINGLE_TEST_FILE below, bestie.) BUT — and this is the part that matters — no other supporting documents get made. No README, no Changes, nothing. Just the module and its test.

And honestly? This is one major glow-up over the earlier h2xs, because now you can actually build multi-module packages. Iconic behavior. 👑

---

✨ Arguments Related to Test Files ✨

• FIRST_TEST_NUMBER — a non-negative natural number, aka where the counting starts in test files that are numerically ordered. (Default is 1.)
• TEST_NUMBER_FORMAT — in test files that are numerically ordered, this is a Perl sprintf formatting string that says how FIRST_TEST_NUMBER should get formatted. (Default is "%03d".)
• TEST_NAME — the string that forms the core of a test file's name. (Default is "load".)
• TEST_NAME_DERIVED_FROM_MODULE_NAME — a boolean. When it's true, it tells ExtUtils::ModuleMaker to make a file in the test suite whose name is derived from the .pm package it's testing — which means it overrides whatever you set in TEST_NAME. So like, for a module called 'Alpha::Sigma::Tau', you'd get a test file named t/Alpha_Sigma_Tau.t. (Default is off.)
• TEST_NAME_SEPARATOR — a string holding the character that joins up the components of a test file's name, e.g. the character joining 001 and <load> in a file named 001_load.t. (Defaults to an underscore "_".)
• EXTRA_MODULES_SINGLE_TEST_FILE — a boolean. When it's true and extra modules have been specified in the EXTRA_MODULES attribute, all the tests for those extra modules go into one single test file instead of individual test files per module. (Default is off.)
• INCLUDE_POD_COVERAGE_TEST — a boolean. If true, you get a test file called t/pod-coverage.t in the t/ directory. Some Perl quality-assurance experts and module authors swear by this test. But the maintainer of ExtUtils::ModuleMaker is not persuaded of its worth, so default is off. 💀
• INCLUDE_POD_TEST — a boolean. If true, you get a test file called t/pod.t in the t/ directory. Again, some Perl QA experts and module authors are all about it. Again, the maintainer of ExtUtils::ModuleMaker is not persuaded of its worth, so default is off. (Same energy, different file. 😭)
• INCLUDE_FILE_IN_PM — a string holding a path to a file full of Perl code and/or documentation that gets included in each lib/*.pm file created in a particular distribution. By default that content lands after any constructor and before the main POD block. So you could, for example, use it to insert stub subroutines into every package in a distribution. Default is off.

💅 Arguments for Advanced Usages 💅

• INTERACTIVE — turns on interactive mode in the modulemaker utility. Interactive mode hits you with a series of menus and you pick features by entering text at the command prompt. This attribute should only be used by interactive scripts like modulemaker. (Default is off.)
• ALT_BUILD — the name of a Perl package holding methods that override the ones called withiin "complete_build" to shape the content of files created by using ExtUtils::ModuleMaker. Check out "An Alternative Approach to Subclassing" below. 🔧

---

🔥 complete_build 🔥

Creates all the directories and files as configured by the key-value pairs you handed to "ExtUtils::ModuleMaker::new". It returns a true value if all the specified files get created — but heads up: that says nothing about whether those files were created with the correct content. It just means they exist. 🙈

🔍 dump_keys 🔍

When you're troubleshooting problems with an ExtUtils::ModuleMaker object, it's often useful to use Data::Dumper to dump the object's contents. Use "dump_keys()" when you only need to peek at a few of the object's attributes.

$mod->dump_keys( qw| NAME ABSTRACT | );

🫣 dump_keys_except 🫣

Same troubleshooting vibe with Data::Dumper — but here's the thing: some parts of that object are wildly long (looking at you, LicenseParts and USAGE_MESSAGE 👀). So this handy dumper function dumps all the keys except the ones you designate.

$mod->dump_keys_except(qw| LicenseParts USAGE_MESSAGE |);

🎀 get_license 🎀

Returns a string that nicely formats a short version of the License and Copyright info. Pretty! ✨

$license = $mod->get_license();
print $license;

...and it'll print something like this:

=====================================================================
=====================================================================
[License Information]
=====================================================================
=====================================================================
[Copyright Information]
=====================================================================
=====================================================================

(So, fun lore: earlier versions of ExtUtils::ModuleMaker had a Display_License function living in each of the submodules ExtUtils::ModuleMaker::Licenses::Standard and ExtUtils::ModuleMaker::Licenses::Local. Those functions were never publicly documented or tested. "get_license()" is meant to be the replacement for both of them. glow-up energy. 💅)

🌸 make_selections_defaults() 🌸

Saves the values you entered as arguments passed to "new()" into a personal defaults file, so they override the defaults that ExtUtils::ModuleMaker ships with.

Okay so this is an advanced usage. If you've used ExtUtils::ModuleMaker more than once, you've definitely typed in a choice for "AUTHOR", "EMAIL", etc., more than once. To save you the unnecessary typing and cut down on typos, ExtUtils::ModuleMaker now lets you set personal default values that override the defaults supplied with the distribution, which live in lib/ExtUtils/ModuleMaker/Defaults.pm.

Say you called "ExtUtils::ModuleMaker::new()" like this:

$mod = ExtUtils::ModuleMaker->new(
    NAME            => 'Sample::Module',
    ABSTRACT        => 'Now is the time to join the party',
    AUTHOR          => 'Hilton Stallone',
    CPANID          => 'RAMBO',
    ORGANIZATION    => 'Parliamentary Pictures',
    WEBSITE         => 'http://parliamentarypictures.com',
    EMAIL           => 'hiltons@parliamentarypictures.com',
);

While $mod is still in scope, you can call:

$mod->make_selections_defaults()

and the values you picked — with two important exceptions — get saved in a Personal/Defaults.pm file stored in your home directory. The next time you invoke ExtUtils::ModuleMaker, the new values will show up in the appropriate locations in the files created by "complete_build()". They'll also show up in the on-screen menus of the modulemaker utility. 🫶

So what are those two important exceptions?

• "NAME" — You cannot enter a default value for "NAME", the name of the module you're creating. ExtUtil::ModuleMaker's own defaults file omits a value for "NAME" to stop you from overwriting an already-existing module. (More precisely: the default value is an empty string. ExtUtil::ModuleMaker will throw an error if you try to create a module whose name is empty.) And this precaution applies to your personal defaults file too. 🔒
• "ABSTRACT" — Every module you create presumably has its own unique purpose, so every module needs a unique "ABSTRACT" to summarize that purpose. ExtUtil::ModuleMaker supplies this string as the default value for the "ABSTRACT" key:

Module abstract (<= 44 characters) goes here

...a string which, not coincidentally, happens to be exactly 44 characters long — so you can just overstrike it. 💅 And this will be the default value for "ABSTRACT" in any Personal/Defaults.pm file you create too.

---

🌈 CUSTOMIZATION 🌈

ExtUtils::ModuleMaker is designed to be customizable to your needs and to offer you more flexibility as you get more experienced with it. Level up at your own pace, bestie. ✨

🧚 Via modulemaker Utility Interactive Mode 🧚

Like everything else about ExtUtils::ModuleMaker, the easiest, laziest way to get started is via the modulemaker utility — go read its documentation. 📖

So imagine you've entered your correct name, email address, and website at the prompts in modulemaker's Author Menu. It looks a little like this:

------------------------

modulemaker: Author Menu

    Feature       Current Value
N - Author        'John Q Public'
C - CPAN ID       'MODAUTHOR'
O - Organization  'XYZ Corp.'
W - Website       'http://public.net/~jqpublic'
E - Email         'jqpublic@public.net'

R - Return to main menu
X - Exit immediately

Please choose which feature you would like to edit:

Now — why would you ever have to type all that in again?? 😭 Return to the modulemaker Main Menu by hitting "R".

------------------------

modulemaker: Main Menu

    Feature                     Current Value
N - Name of module              ''
S - Abstract                    'Module abstract (<= 44 characters) goes here'
A - Author information
L - License                     'perl'
D - Directives
B - Build system                'ExtUtils::MakeMaker'

G - Generate module
H - Generate module;
    save selections as defaults

See that H option? That's your make_selections_defaults() in disguise — generate the module and stash your selections as defaults so you never type them again. Main character energy. 👑

X - Exit immediately

Please choose which feature you would like to edit:

Select <code>H</code> instead of <code>G</code> to generate the distribution — and bestie, here's the tea: an internal call to make_selections_defaults() will save those selections into a personal defaults file and then present them right back to you on the Author Menu the next time you go to use it. It remembers. It always remembers. 💅

---

✨ Via modulemaker Utility Command-Line Options Mode ✨

Okay so real talk: for simplicity, not all of ExtUtils::ModuleMaker's default values are represented on modulemaker's menus. Those that are not represented on those menus cannot be changed from there. They can, however, in many cases be specified as options passed to modulemaker on the command-line and automatically saved as personal defaults by including the s flag as one of those options. 🫶

If, for example, your name is 'John Q Public' and you want all modules you create to have compact top-level directories, you would call:

%   modulemaker -Icsn Sample::Module -u 'John Q Public'

A distribution with a top-level directory Sample-Module would be created. 'John Q Public' would appear in appropriate places in Sample-Module/Makefile.PL and Sample-Module/lib/Sample/Module.pm. You could then throw away the entire Sample-Module directory tree. Bye bestie 🦋

The next time you call modulemaker, the call

%   modulemaker -In Second::Module

would suffice to generate a compact top-level directory and 'John Q Public' would appear in appropriate locations instead of the dreaded 'A. U. Thor'. NOT the dreaded 'A. U. Thor' 😭

✨ Via ExtUtils::ModuleMaker::new() ✨

In all cases, ExtUtils::ModuleMaker's default values can be overridden with arguments passed to new() inside a Perl program. The overriding can then be made permanent by calling make_selections_defaults(). Set it once, slay forever. 👑

Suppose, for example,

1. that you want the files in your test suite to appear in a numerical order starting from 0 rather than ExtUtils::ModuleMaker's own default starting point of 1;
2. that you want the number in the test file's name to be formatted as a two-digit string padded with zeroes rather than ExtUtils::ModuleMaker's own default format of a three-digit, zero-padded string;
3. that you want the numerical part of the test filename to be joined to the lexical part with a dot (".") rather than ExtUtils::ModuleMaker's own default linkage character of an underscore ("_"); and
4. that you want the lexical part of the test filename to reflect the module's name rather than ExtUtils::ModuleMaker's default of "load".

Your Perl program would look like this:

#!/usr/local/bin/perl
use strict;
use warnings;
use ExtUtils::ModuleMaker;

my $mod = ExtUtils::ModuleMaker->new(
    NAME        => 'Sample::Module',
    AUTHOR      => 'John Q Public',
    COMPACT     => 1,
    FIRST_TEST_NUMBER    => 0,
    TEST_NUMBER_FORMAT   => "%02d",
    TEST_NAME_SEPARATOR  => q{.},
    TEST_NAME_DERIVED_FROM_MODULE_NAME => 1,
);

$mod->make_selections_defaults();

A subsequent call to the modulemaker utility,

%    modulemaker -In Second::Balcony::Jump

would generate a directory tree with a compact top-level, 'John Q Public' in appropriate locations in Second-Balcony-Jump/Makefile.PL and Second-Balcony-Jump/lib/Second/Balcony/Jump.pm and a test file called Second-Balcony-Jump/t/00.Second.Balcony.Jump.t. second balcony jump?? the drama of it all ✨

✨ Via Subclassing ExtUtils::ModuleMaker ✨

If you're a power-user, once you start playing with ExtUtils::ModuleMaker, you won't be able to stop. Obsessed. Genuinely obsessed. You'll ask yourself, "Self, if I can change the default values, why can't I change the 'boilerplate' copy that appears inside the files which ExtUtils::ModuleMaker creates?"

Now, you can. You absolutely can, bestie. You can hack on the methods which ExtUtils::ModuleMaker::new() and complete_build() call internally to customize their results to your heart's desire. The key: build an entirely new Perl extension whose lib/*.pm file has methods that override the methods you need overridden — and only those methods. 🎀

Follow these steps:

1. Study ExtUtils::ModuleMaker::Defaults, ::Initializers and ::StandardText

ExtUtils::ModuleMaker's default values are stored in lib/ExtUtils/ModuleMaker/Defaults.pm, specifically, in its default_values() method. Identify those values which you wish to change. 🔍

ExtUtils::ModuleMaker's other internal methods are found in two other files: /lib/ExtUtils/ModuleMaker/Initializers.pm and lib/ExtUtils/ModuleMaker/StandardText.pm. Rule of thumb: if an internal method is called within new(), it is found in ExtUtils::ModuleMaker::Initializers. If it is called within complete_build(), it is found in ExtUtils::ModuleMaker::StandardText. Study these two packages to identify the methods you wish to override.

Hint: If changing a default value in ExtUtils::ModuleMaker::Defaults will achieve your objective, make that change rather than trying to override methods in ExtUtils::ModuleMaker::Initializers or ExtUtils::ModuleMaker::StandardText. 💡

Hint: You should probably think about overriding methods in ExtUtils::ModuleMaker::StandardText before overriding those in ExtUtils::ModuleMaker::Initializers.

2. Use modulemaker to Create the Framework for a New Distribution

You're creating a new Perl extension. Who ya gonna call? modulemaker, natch! (If you have not read the documentation for modulemaker by this point, do so now. fr fr, go read it. 🙈)

Suppose that you've gotten on the 'Perl Best Practices' bandwagon and want to create all your Perl extensions in the style recommended by Damian Conway in the book of the same name. Use modulemaker to create the framework:

%    modulemaker -Icqn ExtUtils::ModuleMaker::PBP \
     -u 'James E Keenan' \
     -p JKEENAN \
     -o 'Perl Seminar NY' \
     -w http://search.cpan.org/~jkeenan/

You used the -q option above because you do not want or need a constructor in the new package you are creating. That package will inherit its constructor from ExtUtils::ModuleMaker. inheritance?? she's giving object-oriented royalty 👑

3. Edit the lib/*.pm File

Open up the best text-editor at your disposal and proceed to hack:

%    vi ExtUtils-ModuleMaker-PBP/lib/ExtUtils/ModuleMaker/PBP.pm

Add this line near the top of the file:

use base qw{ ExtUtils::ModuleMaker };

so that ExtUtils::ModuleMaker::PBP inherits from ExtUtils::ModuleMaker (which, in turn, inherits from ExtUtils::ModuleMaker::Defaults, ExtUtils::ModuleMaker::Initializers and ExtUtils::ModuleMaker::StandardText). 🧚

If you have carefully studied ExtUtils::ModuleMaker::Defaults, ExtUtils::ModuleMaker::StandardText and Perl Best Practices, you will write methods including the following:

sub default_values {
    my $self = shift;
    my $defaults_ref = $self->SUPER::default_values();
    $defaults_ref->{COMPACT}                        = 1;
    $defaults_ref->{FIRST_TEST_NUMBER}              = 0;
    $defaults_ref->{TEST_NUMBER_FORMAT}             = "%02d";
    $defaults_ref->{EXTRA_MODULES_SINGLE_TEST_FILE} = 1;
    $defaults_ref->{TEST_NAME_SEPARATOR}            = q{.};
    $defaults_ref->{INCLUDE_TODO}                   = 0;
    $defaults_ref->{INCLUDE_POD_COVERAGE_TEST}      = 1;
    $defaults_ref->{INCLUDE_POD_TEST}               = 1;
    return $defaults_ref;;
}

sub text_Makefile {
    my $self = shift;
    my $Makefile_format = q~
use strict;
use warnings;
use ExtUtils::MakeMaker;

WriteMakefile(
    NAME            => '%s',
    AUTHOR          => '%s <%s>',
    VERSION_FROM    => '%s',
    ABSTRACT_FROM   => '%s',
    PL_FILES        => {},
    PREREQ_PM    => {
        'Test::More'    => 0,
        'version'       => 0,
    },
    dist            => { COMPRESS => 'gzip -9f', SUFFIX => 'gz', },
    clean           => { FILES => '%s-*' },
);
~;
    my $text_of_Makefile = sprintf $Makefile_format,
        map { my $s = $_; $s =~ s{'}{\\'}g; $s; }
            $self->{NAME},
            $self->{AUTHOR},
            $self->{EMAIL},
            $self->{FILE},
            $self->{FILE},
            $self->{FILE};
    return $text_of_Makefile;
}

Of course, for true Perl laziness, you'll use CPAN distribution ExtUtils::ModuleMaker::PBP, written by the author of ExtUtils::ModuleMaker as an exemplar of subclassing ExtUtils::ModuleMaker and generating the same output as Damian Conway's Module::Starter::PBP. laziness is a virtue here, no cap 🍓

4. Test

How do you know you have correctly subclassed ExtUtils::ModuleMaker? With a test suite, of course. With careful editing, you can use many of ExtUtils::ModuleMaker's own tests in your new distribution. You will, of course, have to change a number of tests, because the default values implied by Conway's recommendations are different from ExtUtils::ModuleMaker's own defaults. Among other things, you will have to do a search-and-replace on all constructor calls.

%    perl -pi'*.bak' -e 's{ExtUtils::ModuleMaker->new}{ExtUtils::ModuleMaker::PBP->new}g;'

Of course, you should have written your tests first, right? RIGHT?? 😭

5. Install and Use

You would install your new distribution as you would any other Perl distribution, i.e., with either ExtUtils::MakeMaker or Module::Build, depending on which you chose in creating your subclass.

#!/usr/local/bin/perl
use strict;
use warnings;
use ExtUtils::ModuleMaker::PBP;

my $mod = ExtUtils::ModuleMaker::PBP->new(
    NAME        => 'Sample::Module',
);

$mod->complete_build();

For an adaptation of the modulemaker utility to work with ExtUtils::ModuleMaker::PBP, see mmkrpbp which is bundled with the latter package. 🎁

✨ An Alternative Approach to Subclassing ✨

There is one other way to subclass to ExtUtils::ModuleMaker which bears mentioning, more because the author used it in the development of this version of ExtUtils::ModuleMaker than because it is recommended. author's little secret 👀 If for some reason you do not wish to create a full-fledged Perl distribution for your subclass, you can simply write the subclassing package and store it in the same directory hierarchy on your system in which your personal defaults file is stored. 🗂️

For example, suppose you are experimenting and only wish to override one method in ExtUtils::ModuleMaker::StandardText. You can create a package called ExtUtils::ModuleMaker::AlternativeText. If you are working on a Unix-like system, you would move that file such that its path would be:

"$ENV{HOME}/.modulemaker/ExtUtils/ModuleMaker/AlternativeText.pm"

You would then add one argument to your call to ExtUtils::ModuleMaker::new():

   my $mod = ExtUtils::ModuleMaker->new(
       NAME        => 'Sample::Module',
       ALT_BUILD   => 'ExtUtils::ModuleMaker::AlternativeText',
   );

okay so that right there is the whole glow-up 💅 literally just point ALT_BUILD at your own text class and go live your life.

---

💀 CAVEATS 💀

Bestie. Sit down. This is the fine print but make it real.

• Perl 5.6.1 is the floor, no negotiating — support for versions of Perl earlier than 5.6.1 was dropped in version 0.57, released in May 2018. Ancient Perl? Not the vibe. 😭
• Testing modulemaker's Interactive Mode — the easiest, laziest and recommended way to use this distribution is the command-line utility modulemaker, especially its interactive mode. But that also makes it necessarily the most difficult thing to test, because testing it would require capturing the STDIN, STDOUT and STDERR for a process spawned by a system('modulemaker') call from within a test file. For now, the maintainer has relied on repeated visual inspection of the screen prompts generated by modulemaker. With luck, Expect-based tests will be available in a future version. 🙈
• Testing modulemaker on Non-*nix-Like Operating Systems — since testing the modulemaker utility from within the test suite requires a system() call, a clean test run depends in part on the way a given operating system parses command-line arguments. The maintainer has tested this on Darwin and Win32 and, thanks to a suggestion by A. Sinan Unur, solved a problem on Win32. Results on other operating systems may differ; feedback is welcome. 🫶

---

📝 TO DO 📝

The "we are so not done yet" list, for the record:

• Tests for modulemaker's interactive mode.
• Possible new USE_AS_BASE attribute which would insert modules from which user's new module will inherit.

USE_AS_BASE => [ qw|
    Template::Toolkit
    Module::Build
    Lingua::Romana::Perligata
    Acme::Buffy
| ],

An attribute like that would require replacement copy for ExtUtils::ModuleMaker::StandardText::block_begin().

---

👑 AUTHOR/MAINTAINER 👑

ExtUtils::ModuleMaker was originally written in 2001-02 by R. Geoffrey Avery (modulemaker [at] PlatypiVentures [dot] com). Since version 0.33 (July 2005) it has been maintained by James E. Keenan (jkeenan [at] cpan [dot] org).

Two icons, one legacy. Periodt. 💖

---

🆘 SUPPORT 🆘

Got a problem, a question, a "bestie why is it doing that"? Send email to jkeenan [at] cpan [dot] org. Please include 'modulemaker' in the subject line so it doesn't get lost in the void. 🕳️

Please report any bugs or feature requests to bug-ExtUtils-ModuleMaker@rt.cpan.org, or through the web interface at http://rt.cpan.org.

Development repository: https://github.com/jkeenan/extutils-modulemaker

---

🫶 ACKNOWLEDGMENTS 🫶

Thanks first and foremost to Geoff Avery for creating ExtUtils::ModuleMaker and popularizing it via presentations I attended at YAPC::NA::2003 (Boca Raton) and YAPC::EU::2003 (Paris). 🌸

Soon after I took over maintenance of ExtUtils::ModuleMaker, David A Golden became a driving force in its ongoing development, providing suggestions for additional functionality as well as bug reports. David is the author of ExtUtils::ModuleMaker::TT which, while not a pure subclass of ExtUtils::ModuleMaker, extends its functionality for users of Template::Toolkit.

Thanks for suggestions about testing the modulemaker utility to Michael G Schwern on perl.qa and A Sinan Unur and Paul Lalli on comp.lang.perl.misc. Thanks for help in dealing with a nasty bug in the testing to Perlmonks davidrw and tlm. That well known Perl hacker, Anonymous Guest, contributed another bug report on rt.cpan.org.

As development proceeded, several issues were clarified by members of Perlmonks.org. CountZero, xdg, Tanktalus, holli, TheDamian and nothingmuch made particularly useful suggestions, as did Brian Clarkson.

Thanks also go to the following beta testers: Alex Gill, Marc Prewitt, Scott Godin, Reinhard Urban and imacat.

Version 0.39 of ExtUtils::ModuleMaker encountered spurious testing failure reports from testers.cpan.org. These were eventually diagnosed as being due to bugs in the automated testing programs and/or their operating environments on different systems — i.e., to problems outside ExtUtils::ModuleMaker itself. Several Perlmonks helped investigate this problem: chromatic, dave_the_m, randyk, and njh.

Thanks to Paul M Sirianni for reporting bugs that led to versions 0.48 and 0.51.

Thanks to Chris Kirke for pointing to reports at http://cpants.cpanauthors.org/dist/ExtUtils-ModuleMaker of inconsistent $VERSION numbers across the component files.

Not a single one skipped. The whole group chat showed up. 🌈

---

©️ COPYRIGHT ©️

Copyright (c) 2001-2002 R. Geoffrey Avery. Revisions from v0.33 forward (c) 2005-2015 James E. Keenan. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

The full text of the license can be found in the LICENSE file included with this module.

---

⚠️ DISCLAIMER OF WARRANTY ⚠️

okay here comes the part that's in all caps because it's the law and the law has no chill 🔥

Because this software is licensed free of charge, there is no warranty for the software, to the extent permitted by applicable law. Except when otherwise stated in writing, the copyright holders and/or other parties provide the software "AS IS" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the software is with you. Should the software prove defective, you assume the cost of all necessary servicing, repair, or correction.

In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who may modify and/or redistribute the software as permitted by the above licence, be liable to you for damages, including any general, special, incidental, or consequential damages arising out of the use or inability to use the software (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the software to operate with any other software), even if such holder or other party has been advised of the possibility of such damages.

No take-backs, no vibes-based refunds. 😭

---

🔍 SEE ALSO 🔍

modulemaker, perlnewmod, h2xs, ExtUtils::MakeMaker, Module::Build, ExtUtils::ModuleMaker::PBP, ExtUtils::ModuleMaker::TT, mmkrpbp.

---

And that's the whole page, bestie — perl v5.36.0, dated 2023-01-27, and this lil doc lives on the ExtUtils::ModuleMaker man page. Go make a module, you're gonna slay. 🦋💖✨