views:

892

answers:

11

What's the best framework for writing modules -- ExtUtils::MakeMaker (h2xs) or Module::Build?

+2  A: 

There are pros and cons to both. These days I use and recommend Module::Build and Module::Starter.

Frank Wiles, Revolution Systems, www.revsys.com

Frank Wiles
A: 

EU::MM still seems to be the most widely supported and popular one, but Module::Build is catching up. Also, check out Module::Starter for a module that will help you get started.

amoore
+2  A: 

I also recommend Module::Build and Module::Starter (with the TT2 plugin).

cjm
+2  A: 

Module::Build is better by any means, but it is less widely supported than ExtUtils::MakeMaker (more specifically, older versions of Perl don't support it out of the box). It depends on your needs.

Leon Timmermans
+24  A: 

There are two questions here.

First, never use h2xs. It's old outdated nastiness, though I suppose if you're actually trying to turn a header file into XS code, it might be useful (never done that myself).

For creating a new module, use Module::Starter. It works great, and has some nice plugins for customizing the output.

Second, you're asking what build system you should use. The three contenders are ExtUtils::MakeMaker (EUMM), Module::Build (MB), and Module::Install (MI).

EUMM is a horrid nasty piece of work, but it works, and if you're not customizing your build process at all, works just fine.

MB is the new kid, and it has its detractors. It's big plus is that if you want to heavily customize your install and build process, it's quite possible to do this sanely (and in a cross-platform manner) using MB. It's really not possible using EUMM.

Finally, MI is basically a declarative wrapper on top of EUMM. It also packages itself along with your distro, in an attempt to work around problems with users trying to install modules with old toolchain modules. The downside of the "package self" trick is that if there's a bug in MI itself, you have to re-release all your modules just to fix it.

As far as customization goes, there are some plugins for MI, but if you want to go beyond them you'll be back at the problem of dealing with Makefiles and build tools across a dozen+ platforms, so it really isn't going to help you too much in that realm.

Dave Rolsky
+13  A: 

I just uploaded Distribution::Cooker to CPAN. It's what I use to make new distributions. The nice thing about it is that your distributions can be whatever you like: you're just cooking some templates. You might start with something like Module::Starter to make your starter templates then add your own boilerplate and favorite way of doing things. You choose not only whatever you want in each file, but which files show up in the distro. As you figure out how you like to do things, you simply update your own templates.

As for Makemaker and Module::Build, the future is Module::Build. It's only us old guys using Makemaker anymore. :) There are ways to use both (or pretend to use both) at the same time. Look at the Module::Build, Module::Build::Compat, and Module::Install docs.

Although this is a bit of a cop-out answer, try using each just to get a little experience with each.

brian d foy
+2  A: 

Personally, I recommend Module::Install, as do a lot of folks I know - the likes of the Catalyst and Moose folks also use it.

Penfold
Well, Moose moved away from it for Class::MOP, so I could add some make the XS optional bits that would've been painful to do in MI. And that is the crux of (one reason) why I don't like MI. It's a very narrow API, and customizing it is even more painful than dealing with EUMM.
Dave Rolsky
Module::Install looks very nice, but you distribute it with your module so you're stuck with whatever version you distribute. I don't like having another set of things to update in a dist either. Aside from that, Module::Install is nice as long as you don't use auto_install. :)
brian d foy
+2  A: 

Here's a little clarification of the direction I hoped the responses would take:

  • pros/cons of various of frameworks
  • compatibility/install base of frameworks
  • suitability for internal (local) vs. external (CPAN) releases
  • not bare "use X" answers

Dave's answer has some good pro/con info. Leon's answer alludes to compatibility but isn't explicit. As brian d foy mentioned, only the old hats use EUMM, but I'm not convinced that MB is a good framework for things destined for CPAN due to it not being part of the core until 5.9.

Michael Carman
The core module problem is why I haven't used Module::Build yet, but now that 5.10 has it, I should probably use Module::Build now. Even though 5.10 isn't widely distributed yet (still being 5.10.0), if I start a module I don't want to have to redo it's build system later. :)
brian d foy
+4  A: 

Hi Michael,

The only trouble with compatibility regarding Module::Build is when a user tries to install modules without updating their CPAN client (CPAN.pm or CPANPLUS.pm) If they are installing your module from the CPAN, they can just as easily upgrade their client from the same mirror.

If you don't want to do anything complicated in your build process, sure: use EUMM. But if you have a build problem on a different target platform, you might end up in the Makefile, which is different on every variation of make.

Module::Build gives you lots of features (anything you can think of if you extend it) and is all perl so you never end up debugging a makefile. Module::Install gives you features, but you have to bundle it and everything ends up running through 'make' in the end.

Eric Wilhelm
Not everyone installs via the cpan shell so dependency resolution isn't necessarily automatic. I've had a hard time trying to get it to work with ActivePerl (though it seems to be okay now in 5.10). That said, I think your second paragraph is the key answer.
Michael Carman
+33  A: 

As the maintainer of ExtUtils::MakeMaker, I like to recommend Module::Build because MakeMaker is a horror show and I don't want to maintain it any more. Module::Build is so much better put together. But those aren't your concerns and I'll present my "least hassle for you" answer.

Executive Summary:

Because Module::Build support is not 100% in place through all of Perl, start with MakeMaker. If you want to do any customization at all, switch to Module::Build. Since their basic layout, options and interface are almost identical this will be painless. As seductive as it looks, avoid Module::Install.

Fortunately, Module::Build can emulate MakeMaker which helps some, but doesn't help if you're going to do any customization. See Module::Build::Compat.

For CPAN releases using Module::Build is fine. There's enough Module::Build stuff on CPAN now that everyone's dealt with getting it bootstrapped already.

Finally, the new configure_requires option lets CPAN shells know to install Module::Build before they can start building the module. Unfortunately only the latest CPAN shells know about configure_requires.

Oh, whatever you do don't use h2xs (unless you're writing XS code... and even then think about it).

MakeMaker Pros:

  • Comes with Perl.
  • Everything knows what to do with a Makefile.PL.
  • Most module authoring documentation will cover MakeMaker.

MakeMaker Cons:

  • Requires make (think Windows)
  • Difficult to customize
  • Even harder to customize and make cross platform
  • Difficult to debug when something goes wrong (unless you understand make)
  • No new features are being added (except related to META.yml)

Module::Build Pros:

  • Easier to customize
  • Pure Perl
  • Easier to debug (it's Perl)
  • Can emulate MakeMaker in several ways
  • The CPAN shell will install Module::Build for you
  • New features are being added

Module::Build Cons:

  • CPANPLUS (as of this writing) won't install Module::Build for you. Real Soon Now.
  • Older versions of CPAN and CPANPLUS don't know anything about Module::Build.

Module::Install Pros:

  • Slick interface
  • Bundles itself, you have a known version
  • Everything knows how to deal with a Makefile.PL

Module::Install Cons:

  • Requires make
  • Always uses bundled version, vulnerable to external breakage
  • Difficult to customize outside its interface
  • Mucks with the guts of MakeMaker so a new MakeMaker release will eventually break it.
Schwern
If I recall correctly, CPANPLUS cannot uninstall modules that it installed using Module::Build, but it can uninstall them if they were installed using MakeMaker. So that's a con for M::B.
Ryan Thompson
@Ryan That doesn't appear to be true, just tried it on Acme::Pony (MakeMaker) and Gravatar::URL (Module::Build). CPANPLUS' uninstall is packlist based, and there may have been a time when MB didn't produce packlists.
Schwern
Hmm. I'm on Ubuntu 9.10. Since perl is such a core component of the OS, I know that Debian/Ubuntu tends to update it infrequently. Maybe I'm just living in the past.
Ryan Thompson
+9  A: 

You also might want to look at Dist-Zilla which is a new author-only tool to create distributions. Because it just helps build the distribution, it doesn't ship with your code or do any installation, it can do a lot of powerful stuff.

Schwern
+1: Dist::Zilla is the new sex.
Kent Fredric
Combining both of your posts @Schwern , you should use Dist::Zilla with [ModuleBuild] plugin =). http://p3rl.org/Dist::Zilla::Plugin::ModuleBuild
Kent Fredric