Item Description: an h2xs replacement for non-XS modules
Review Synopsis:
ExtUtils::ModuleMaker vs h2xs
ExtUtils::ModuleMaker is a replacement for h2xs. So what's wrong with h2xs
anyway and how does ExtUtils::ModuleMaker perform any better?
h2xs -AXn Foo::Bar
My annoyances with h2xs (these are purely personal):
- by default: it produces code that isn't backwards compatible [see note] (our instead of use vars, use warnings, and use 5.00?)
- you have extra work if you have more than one module in the distribution
- you have lots of editing to do before you get started, (unless your name is A. U. Thor)
- module code and tests are all dumped into the main directory
On reflection, these seem quite petty -- but I am very lazy.
perl -MExtUtils::ModuleMaker -e "Quick_Module ('Foo::Bar')"
This is more to type, and produces similar results to h2xs. However there are the following improvements:
- module files are neatly stored in a "lib" folder
- test file is created in "t" subfolder
- LICENSE file is included - defaults to perl license (GPL & Artistic)
- lib/Foo/Bar.pm is backwards compatible with perl 5.005
- useful pod sample for documenting subroutines
Advanced use of ExtUtils::ModuleMaker
The QuickModule() function still leaves A.U. Thor as the author of your work and other defaults
and leaves you with only one module in your distribution. Use Generate_Module_Files() for a more complete solution...
Generate_Module_Files()
- Specify author details, (fills in the pod, Makefile.PL, etc)
- Specify version number to start on
- Specify the license that your module is released under (over 20 licenses included - or use custom)
- Create module and test files for additional modules
Here is my code using ExtUtils::ModuleMaker that allows me to be extra lazy:
#!/usr/bin/perl5.6.1 -w
use strict;
use Getopt::Long;
use ExtUtils::ModuleMaker;
my %author =
(
NAME => 'Simon Flack',
EMAIL => 'simonflk@example.com',
CPANID => 'SIMONFLK',
WEBSITE => 'http://www.simonflack.com',
);
# Set some defaults
my $license = 'perl';
my $version = '0.1';
my $module_name = '';
my $extra_modules = '';
my @extra_modules = ();
GetOptions
(
'name=s' => \$module_name,
'version:f' => \$version,
'license:s' => \$license,
'extra:s'=> \$extra_modules
);
Usage() unless $module_name;
######################################################################
+#########
# Now make the module
######################################################################
+#########
push @extra_modules, {NAME => $_, ABSTRACT => $_}
for split /,/, $extra_modules;
Generate_Module_Files
(
NAME => $module_name,
ABSTRACT => $module_name,
AUTHOR => \%author,
VERSION => $version,
LICENSE => $license,
EXTRA_MODULES => \@extra_modules,
);
sub Usage
{
my ($prog) = $0 =~ /\/([^\/]+)$/;
print <<HELP;
$prog - Simple Module Maker
Usage: $prog <-name ModuleName> [-version=?] [-extra=?,?] [-license=?]
Eg: $prog -name My::Module
$prog -name My::Module -version 0.11
-extra My::Utils,My::Extra -license perl
HELP
}
Now I can write: "newmodule -n Foo::Bar -v 1.0 -l gpl" and I can start coding and
writing tests straight away...
Note: If you use this, don't forget to change the author info.
Problems with ExtUtils::ModuleMaker
There aren't many.
- ExtUtils::ModuleMaker won't be helpful if you are writing XS modules. You should stick to h2xs for this, probably.
- The .pm files it creates encourage inline pod for documenting subroutines. I know a lot of people do this,
but I prefer putting my pod at the bottom.
- The test files are obscurely named, you'll probably want to rename them.
Reference:
See the following docs for more information about writing modules
update: h2xs compatibility
crazyinsomniac pointed out that h2xs has a backwards compatibility option "-b" I couldn't find this documented and it didn't work when I tried it (my v5.6.0 h2xs is higher up in the PATH than my 5.6.1 h2xs). It seems that is is a new option since perl5.6.1. I'll leave my original statement in here because it will still apply to some people on older perls. Thanks to crazyinsomniac for pointing out this option.
Re: ExtUtils::ModuleMaker
by Dog and Pony (Priest) on Jun 11, 2002 at 15:32 UTC
|
First of all, thanks for this. I've been using your script for a while, because I find this way much easier than the H2XS way. I just discovered that a new feature has been added to ExtUtils::ModuleMaker that I thought I'd share with the rest of you.
If you add
compact => 1,
to the arguments to Generate_Module_Files it produces the directory "Foo-Bar" instead of "Foo/Bar", which apparently is what you want to make it easier to make for instance a CPAN distribution (see link below).
It still doesn't add the version number, as recommended in the excellent How to make a CPAN Module Distribution, but now it is much easier to do that too. The following lines, added to your script (together with the "compact" argument) takes care of this:
my $dir_name = $module_name;
$dir_name =~ s/::/-/g;
print STDERR "renaming '$dir_name' to '$dir_name-$version'\n";
rename $dir_name, "$dir_name-$version"
or warn "Could not rename '$dir_name' to '$dir_name-$version': $!"
+;
Just so we all can be even more lazy... :)
Note that you must upgrade ExtUtils::ModuleMaker to a newer version for this to work, I am using version 0.204, while whatever the last one I had was, did not have the compact parameter.
You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue. | [reply] [d/l] [select] |
|
Here's my revamp of simonflk's utility rolling in D&P's compact stuff:
STANDARD COMPACT USAGE:
$> newmodule -name Foo::Bar -version 0.01 -compact 1
$> newmodule -n Foo::Bar -v 0.01 -c 1
COMPACT USAGE WITH VERSION # IN FOLDER NAME:
$> newmodule -name Foo::Bar -version 0.01 -compact 2
$> newmodule -n Foo::Bar -v 0.01 -c 2
$> newmodule -n Foo::Bar -v 0.01 (My Default Setting)
DEFAULT FOLDER NAMING USAGE:
$> newmodule -name Foo::Bar -version 0.01 -compact 0
$> newmodule -n Foo::Bar -v 0.01 -c 0
#!/usr/bin/perl
use strict;
use warnings;
use Getopt::Long;
use ExtUtils::ModuleMaker 0.204;
my %author =
(
NAME => 'Christopher Baker',
EMAIL => 'ignatz@ignatzmouse.com',
# CPANID => 'IGNATZ', Someday *SIGH*
WEBSITE => 'http://www.ignatzmouse.com'
);
# Set some defaults
my $license = 'perl';
my $version = '0.01';
my $module_name = '';
my $compact = 2;
my $extra_modules = '';
my @extra_modules = ();
GetOptions
(
'name=s' => \$module_name,
'version:f' => \$version,
'license:s' => \$license,
'extra:s' => \$extra_modules,
'compact:i' => \$compact
);
Usage() unless $module_name;
######################################################################
+#########
# Now make the module
######################################################################
+#########
push @extra_modules, {NAME => $_, ABSTRACT => $_}
for split /,/, $extra_modules;
Generate_Module_Files
(
NAME => $module_name,
ABSTRACT => $module_name,
AUTHOR => \%author,
VERSION => $version,
LICENSE => $license,
compact => $compact, # Module uses wrong option case, not C
+OMPACT
EXTRA_MODULES => \@extra_modules
);
if ($compact == 2)
{
my $dir_name = $module_name;
$dir_name =~ s/::/-/g;
print STDERR "renaming '$dir_name' to '$dir_name-$version'\n";
rename $dir_name, "$dir_name-$version"
or warn "Could not rename '$dir_name' to '$dir_name-$version':
+ $!";
}
sub Usage
{
my ($prog) = $0 =~ /\/([^\/]+)$/;
print <<HELP;
$prog - Simple Module Maker
Usage: $prog <-name ModuleName> [-version=?] [-extra=?,?] [-license=?]
+ [-compact=?]
Eg: $prog -name My::Module
$prog -name My::Module -version 0.11
-extra My::Utils,My::Extra -license perl
HELP
}
()-()
\"/
`
| [reply] [d/l] |
|
If you execute this script in the same directory as it and you don't pass any parameters, your Usage() doesn't construct $prog correctly.
my ($prog) = $0 =~ /\/([^\/]+)$/;
---- Change to:
use File::Basename;
...
my ($prog) = basename($0);
------ We are the carpenters and bricklayers of the Information Age. The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6 Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
| [reply] [d/l] |
|
| [reply] [d/l] |
Re: ExtUtils::ModuleMaker
by xdg (Monsignor) on Mar 08, 2004 at 16:23 UTC
|
I've recently posted ExtUtils::ModuleMaker::TT to CPAN, which extends ModuleMaker to allow user-customized templates to support personal coding style. Also, it includes makeperlmod -- a new command line script that will read default ModuleMaker values from a config file when generating skeleton distributions. As a side benefit, it can add new skeleton .pm and .t files into an existing ModuleMaker distribution tree.
-xdg
Code posted by xdg on PerlMonks is public domain. It has no warranties, express or implied. Posted code may not have been tested. Use at your own risk.
| [reply] |
Re: ExtUtils::ModuleMaker
by geektron (Curate) on Feb 08, 2005 at 17:24 UTC
|
i just started poking around with ExtUtils::ModuleMaker, and this node has, unfortunately, become outdated, since the public interface, as of the .3x releases, has become object-oriented, not function-oriented.
just an FYI, i guess ...
| [reply] |
Re: ExtUtils::ModuleMaker
by bart (Canon) on Nov 18, 2006 at 15:20 UTC
|
perl -MExtUtils::ModuleMaker -e "Quick_Module ('Foo::Bar')"
Nope, that no longer works. The Quick_Module function seems to have been deleted from the module.
But now, life is easier still; just run the script
modulemaker
and you can interactively set some of your configuration preferences, even store them for next time when you finish. So, you only have to enter your name and contact info once. Nice.
| [reply] [d/l] [select] |
|
|