ExtUtils-ModuleMaker reviews

RSS | Module Info

ExtUtils-ModuleMaker (0.32) ****

Although I heard Geoff Avery's presentation on ExtUtils::ModuleMaker at YAPC::NA::2003 in Boca Raton (and possibly also in Paris), I never got around to installing it until today, when I decided to play around with the 'modulemaker' utility as an alternative to 'h2xs'.

Geoff, I have to pay you a high compliment: 'modulemaker' is truly f***ing Lazy!

I do have some criticisms, but to those in a moment. First, some context. I'm planning to give a talk on Perl modules and testing in a couple of months. As part of the talk, I want people in the audience to create a Perl module from scratch as I speak.

At first I thought: One step in the process will be to teach them about h2xs. But that will entail teaching them to set aside h2xs's original purpose (facilitating inclusion of C code in a Perl extension) and focus on what is probably its more widely used purpose: creating the initial structure for modules with no C code whatsoever. That meant that (a) I had to study the h2xs docs much more than previously; (b) I had to try out the most recent version (since I haven't had to create a module structure totally from scratch in years). When I tried it out, this was the Makefile.PL I got:

$ h2xs -AXn Nola::Three


NAME => 'Nola::Three',

VERSION_FROM => 'lib/Nola/Three.pm', # finds $VERSION

PREREQ_PM => {}, # e.g., Module::Name => 1.1

($] >= 5.005 ? ## Add these new keywords supported since 5.005

(ABSTRACT_FROM => 'lib/Nola/Three.pm', # retrieve abstract from module

AUTHOR => 'James E Keenan <jimk@local>') : ()),


I gagged at this. It's much uglier than its output of 3 or so years ago. It took me 8 or 10 viewings to realize that the 3 lines below PREREQ_PM are (take a deep breath) the evaluation of a ternary condition within the list of arguments being passed to WriteMakefile()! And, of course, it gets the e-mail address wrong.

So, I thought, maybe is the time for me to get familiar with EU::MM. But, I figured that for purposes of my talk, what I really needed to do was to get familiar with the 'modulemaker' command-line utility -- since *that* is what is really the drop-in replacement for 'h2xs'.

So that's what I did at work today! And as I filled in the responses to the prompts I thought: Wow, this is really f***in' Lazy! I could have my secretary do it!

Now the criticisms -- and, with one exception, these are criticisms of the utility, not of the module (which I haven't really peered into or used in a script).

(1) The Makefile.PL created by modulemaker indicates Test::Simple is needed:


NAME => 'Nola::Two',

VERSION_FROM => 'lib/Nola/Two.pm', # finds $VERSION

AUTHOR => 'jk (jkeenan@cpan.org)',



'Test::Simple' => 0.44,



But the test file created by the same process uses Test::More, not Test::Simple:

use Test::More tests => 2;

What gives? Shouldn't it be Test::More which is specified in PREREQ_PM?

(2) As you can see above, the Makefile.PL created by modulemaker includes a line for the ABSTRACT. But, AFAICT, modulemaker doesn't prompt the user to enter an abstract. I would suspect that you could add this rather easily, and it would avoid POD looking like this:

head1 NAME

Nola::Two -


The neat thing about the modulemaker utility is that if you follow the prompts you can create a module *that does absolutely nothing* and have it go through make, make test, make install and make dist *without writing any Perl code at all*.

Now, if that ain't Laziness, I don't know what is.

My one criticism: the module could use more documentation.

ExtUtils-ModuleMaker (0.32) *****

Although I just filed a bug report against this module (#3326), I'm still giving it a 5 star overall rating, because it's such a refreshing alternative to the old "h2xs -XAn" method of generating a module skeleton. Using the included 'modulemaker' binary, it's possible to answer a few easy questions and have a nice module distribution generated for you...without having read any prior documentation. It's even compatible with the newer and hipper Module::Build method generating modules.

Let's flush out the few bugs and kinks in this system and put h2xs to rest as the primary recommendation for module skeleton generation.