Module-Build reviews

RSS | Module Info

Module-Build (0.4224) *

Absolutely horrible. Intended as a replacement for the ExtUtils::MakeMaker, but does not replicate EU::MM's install options, nor fully document its differences. After ten years of using it, I am sick of modules which use Build.PL failing to install, or build into Debian packages due to permissions errors.

After a decade, you've had long enough to prove perl can do everything make can seamlessly. It can't, or at least your implementation can't. Make works. This module feels as though it exists out of an ideological purity, rather than any technical superiority to EU::MM.

If you are a module author, using this module is trading the users of your module's ease of use for your own. I would discourage any module authors from using Module::Build in the strongest possible terms.

Module-Build (0.4220) *****

All tests passed.

Module-Build (0.4205) *

The lowest possible rating as this module has always sucked something terrible on Cygwin. I cannot update or install a "growing" number of key modules because they rely on this piece of dodgy donkey doodoo.
No offence, but Cygwin is my key link to the world of sanity, and although Strawberry Perl is wonderful it doesn't easily mesh with my Cygwin environment.

Module-Build (0.4003) ***

I agree with Rolsky's observation that Module::Build is great for custom installers. I have found it the ideal solution for scripting packaging and installation solutions. It is simple to add custom actions and build elements and the resulting installation procedure is simple. I have not prepared CPAN modules with it, nor been bitten by the PREFIX issue, so I have no comment on that.

Module-Build (0.4214)

Module::Build is a replacement for ExtUtils::MakeMaker for building CPAN modules.

Unless you already know exactly what you are doing before you start using it, Module::Build is very difficult to use, error-prone, and badly documented. For example, try the following experiment; delete the "package" line from your module. What happens? Here is the build script:

use Module::Build;
my $builder = Module::Build->new(

module_name => 'Fake::Module',

---- end

Here is lib/Fake/

#package Fake::Module;
our $VERSION = 0.01;

---- end

Here is the exact error message:

$ perl Build.PL
Can't determine distribution version, must supply either 'dist_version',
'dist_version_from', or 'module_name' parameter at /home/ben/software/install/lib/perl5/5.10.0/Module/Build/ line 1150.

Adding to this,

perldoc Module::Build

is no help at all telling me about any of these parameters.

This is just one example but very typical of Module::Build: meaningless error messages, and unhelpful documentation. I could pick several other examples, since I've had many, many frustrations like this dealing with Module::Build, but this was the one which prompted me to come here and write this review, since it actually happened (I accidentally deleted the "package" line from a long module, and spent some time trying to work out what on earth the above error message meant.)

Yes, it's my own fault for doing stupid things like accidentally deleting the "package" line from my module. But I don't want to spend all this time and agony learning the convolutions of Module::Build for what seems to be little gain.

To take yet another frustration from today (which is why I came back to rewrite this review), it seems I have not written a module abstract for a different module in the way that Module::Build requires, so it is complaining about "dist_abstract". And yet it does not document anywhere what the correct format for the module abstract is. I try searching on Google, and find in the docs for Module::Build::Functions

"Module::Build looks in the POD of the module from which it gets the distribution's version. If it finds a POD section marked "=head1 NAME", then it looks for the first line matching \s+-\s+(.+), and uses the captured text as the abstract."

OK, I write exactly what it says, like this:

=head1 NAME

Module - My Module


Does it work? No.

Then I try a whole bunch of other variations. Then I look at the source code to try to find what to do. Still I can't work it out. Again it's my own fault: somehow, some way, I should magically know what format Module::Build expects. But I don't.

Yes, I suppose I could study the source code even harder to work out what is going on. But if this really is meant to be the default way to build modules, is it too much to ask for it to be clearly documented, and have meaningful error messages, instead of sending people scrabbling around its source code or searching on Google?

There is some documentation of some of the parts in another module called "Module::Build::Functions", but unfortunately it's not accurate or complete.

Module-Build (0.32) ****

If you read some of the reviews from years past, it seems like many of these issues are solved.

"install_base" is now supported by EU::MM and Module::Build, which solved that complaint. Figuring out every gyration to get PREFIX and INSTALL*DIR just right is now obsolete, thankfully.

Module::Build::Compat can also spit out a Makefile.PL for backwards compatibility.

Module-Build (0.31012) ***

Module::Build is the thing that perl should have had all along. No need to have "make" - when perl is good enough. 2 minor suggestions that would eliminate the source of all the bad reviews here:

1. Spit out a compat passthrough Makefile.PL by default. Option should be to turn this off, not on.

2. "Autobundle" itself into inc/ (check out Module::Install, which should be looked to for other good options as well). Should be the default for compatibility at least for the next 5 years.

Module-Build (0.2808) ****

I create all my packages using this package.

It could be better documented and be easier to extend, but for the most part it is wonderful.

Module-Build (0.2808) ****

Module::Build has come a long way. I use it in my Video::Xine module because it offers a clean, well-documented way to add arbitrary arguments to the C compiler. In addition, it has a superior interface for authors (who we should encourage... the best reason to use Perl is CPAN), plus some well-designed methods for backward compatibility. It will, in fact, automatically create a Makefile.PL in your distribution.

The only things preventing a five-star rating are buildability checks and the sheer number of unfixed bugs sitting in the queue. The CPAN automated testing system is designed to skip sending a FAIL report if the Build.PL or Makefile.PL script exits successfully but without creating a Makefile or Build file. It's easy to add an assertion to the Build.PL file, but if there's a compatibility-layer Makefile.PL, it will error out if the Build.PL doesn't create a Build file.

In the end, the benefits strongly outweigh the drawbacks, and I look forward to its joining the Perl core, which will eliminate many of the other objections.

Module-Build (0.2808) ***

Here's the short story: first there's Exutils::MakeMaker, which requires make and hard to extend, but everybody uses it due to lack of alternatives. Then came Module::Build which is pure perl and easier to use for authors, but breaks compatibility. Users can no longer use the 'perl Makefile.PL && make && make install' mantra. Plus, it used to not support PREFIX. Plus, MB-based modules require MB which is not by default installed. This pisses *a lot* of people.

Lesson to learn: maintaining backward-compatibility is very important, especially for end users. I think the intention of MB is a good one, but the execution could be a bit better. For example, perhaps the "Build.PL" script could've still just been named "Makefile.PL", couldn't it?

I recommend people shopping for a module installer to look at Module::Install instead. MI is a middle ground between Eu::MM and MB. It's pure perl and easy to extend but it also allows users (and et al) to install modules the old way. It embeds a copy of itself in every MI-based modules, so there's no depedency hell. Best of both worlds.

Module-Build (0.2805)

This is not a review, but a plea to module authors. Please don't require Module::Build (especially via the execrable Module::Build::Compat waiting in ambush in an innocent Makefile.PL) unless you absolutely must. While it may be helpful for complicated Makefiles, in many cases it is simply a reinvented wheel and an annoyance.

Module-Build (0.2805) *

This is a horrible set up. Rick said it right.
I cannot build it with
perl Makefile.PL.
Since it require Module::Build itself. What a waste of everyone's time.
If it cannot find Module::Build, switch to something else that let the build continue.

I will give it zero if there is such a rating.

Module-Build (0.2805) *

Worse than horrible trying to install this on a virgin machine. Install a really old version first (0.26 iirc). But make sure that your env isn't too long or you won't be able to upgrade to this version. Go figure.

Module-Build (0.28) *

All I want to do is to configure the CPAN shell to install all modules under my home directory (not as root), even though the Perl I am using is bundled with my system (installed as root).

I can figure out how to set PERL5LIB to access the modules. I always have.

I used to simply set PREFIX. But now that half of the &^##@%! modules on CPAN use MakeMaker and half use Module::Build, I have no idea what to set. I tried setting both PREFIX and install_base in the CPAN shell defaults, but then Module::Build modules refuse to compile at all (they bomb when given PREFIX).

Nice job breaking something that has worked for years. This sucks even by open source standards... I don't care about stupid religious wars; I just want some setting -- any setting -- to convince all of the modules on CPAN to install themselves under ${HOME}. Is there one? There used to be.

Module-Build (0.35) ***

I get the point. I even like the idea. But Module::Build has been promoted as being usable for some time now, when it (to me at least) still seems to have icky problems.

For starters, every Module::Build script seems to blindly assume that M:B is already installed, something that it isn't on new installs, or new installs of older Perls.

So if you install something with the normal Makefile.PL and some dependency of a dependency uses M:B boom it dies.

Second, it doubles the configuration load... and asks almost all of the same questions about configuration. Or at least, that seems to have been forced on both and when dealing with configurations.

Then there's the problems with it not more-closely matching the way EU::MM does things like PREFIX. When faced with the PREFIX problems, Module::Build presents a long lecture on why PREFIX is bad, and proposes a different mechanism that is COMPLETELY incompatible with PREFIX. This makes the 10% of CPAN that uses Module::Build incompatible with the other 90%, and thus breaking 10 years of accumulated core and third-party toolchains, not to mention the built up knowlegde of millions of Perl programmers and sysadmins.

In addition, Module::Build-based modules are unable to bootstrap, since they rely on Module::Build being installed already, and in addition Module::Build has zero back-compatibility capability in it's design, something the author admits in his Motiviations section.

It really comes down to too many people promoting the user of pre-production beta software. See that version number. It's for a reason. I'd recommend most people to go away and wait until it is bug-free and hits 1.000. Unless you really absolutely have to do something madly custom, then use it. But otherwise wait.

Module-Build (0.2611) ****

After using it for years, I'm still very happy with Module::Build.

It is way-better than MakeMaker. It's easier to use, allows one to specify more complex requirements and recommendations than MakeMaker allows, but it has backwards compatability so it can generate Makefile.PL as well as Build.PL.

I strongly recommend using this and as a replacement for MakeMaker.

One important and subtle hitch: it does not handle auto-splitting automatically, and the docs indicate that the autosplitting interface may change. So if you've installed an earlier version of your module (using older Makefile), it will pass tests because autoloading methods are already available, but it will fail CPAN testers.

Another nit (and the reason I've updated my review): one does need to read the docs section "Alternatives to PREFIX" before complaining about it: <;

Module-Build (0.2611) *

What a nightmare. Lack of PREFIX support makes it hard (impossible?) to install modules via CPAN.

The docs indicate that I can specify an alternate install location by supplying --install_path parameters to the Build.PL script. In theory, this means I could :

perl Build.PL --install_path lib=/some/place
./Build test
./Build install

Presumably, libs would be installed under /some/place, but no! The --install_path param has no effect on the install process!

Instead, you have to change the last step to:
./Build install --install_path lib=/some/place

Module-Build (0.2611) **

Module::Build seems to have been written with Module Authors in mind, with little-to-no thought given to the end users, the ones who would use the modules written with Module::Build.

One of the main perks of Perl in general and CPAN in particular is the ease with which one can install and use a module. Simply by typing
cpan Name::Of::Module
we can have the module and all of its dependencies downloaded, built, tested, and installed.

Modules that are written with Module::Build completely destroy this ability. I've read the author's reasoning for not supporting PREFIX, and it just doesn't hold up. PREFIX is the standard, it is what is used, and alternative OS's aside, it works for 90% of the cases in which its used. By not supporting PREFIX, the author makes it impossible to install a module via the cpan shell. It would even be acceptable if the author allowed makepl_arg to have both PREFIX and destdir or install_base set, and simply ignore PREFIX if it's there. But that doesn't work either, as the Build.PL script dies with an error if PREFIX is given at all.

Going through the four step process of manually building Module::Build-dependent modules is not acceptable, for the same reason that led to the creation of to begin with - all of the module's dependencies and sub-dependencies have to be retrieved, built, tested, and installed independently and in the correct order.

Until, or get together and make a coherent way to install all modules regardless of whether they use build or make, I will choose the simple alternative of not using any module which relies on Module::Build. Thus far, I haven't found any burning hole in my programming abilities caused by not using them.

Module-Build (0.3607) ****

I have also suffered Module::Build lack of support for the PREFIX option.

I was trying to install an application on a client server under a home directory. I had configured CPAN to use the correct PREFIX and so, everything was installing smoothly until, one of modules asked for Module::Build and everything become a mesh...

Maybe the directory structures created by ExtUtils::MakeMaker are not the most beautiful ones, but it doesn't harm, so, why to make Module::Build use a different format, one that will stop it from supporting the most useful and common Makefile.PL option, PREFIX???

Module-Build (0.2610) ****

I've used this module to build various custom logic into the build/install process for various Perl modules and applications, and it's been invaluable for that. The docs are fairly complete, but a bit overwhelming. Fortunately, they're getting cleaned up and re-organized for the next (0.27+) releases.

If you've been "subclassing" ExtUtils::MakeMaker run, do not walk, and check out Module::Build. If you have a Perl-based app that you need to write an installer for, then this is the module for you.

OTOH, if you just need to have an installer for a plain vanilla Perl module, then Module::Build is no easier (or harder) than using ExtUtils::MakeMaker.

Module-Build (0.26) ***

I'm very unhappy that it doesn't support the standard PREFIX option. I use this option to install modules with on my home directory and I'm very happy with the layout that it produces. When I tried to install a module that used Module::Build, everything became a big mess.

Module-Build (0.21) *****

Replacement for ExtUtils::MakeMaker. Very nice. If you need to write custom build scripts try this instead of ExtUtils::MakeMaker. It's 100% Perl OO architecture makes everything so much more simple.

Module-Build (0.20) *****

Module::Build is a superb package. It intends to replace ExtUtils::MakeMaker and the ubiquitous Makefile.PL files with Build.PL files. I hope it succeeds!

It is very friendly to subclassing and it is fairly easy to read. Don't let the low version number fool you. This package is nearly ready for prime-time.

The changes I've noticed are that it's stricter about where it looks for some files. *.pm files must live in a lib/ subdirectory, which is a good idea in the long run I think.

Module-Build (0.19) *****

Module::Build is a replacement for ExtUtils::MakeMaker, and specifically aims to replace 'make' in the module build process. Module authors should consider using Module::Build instead of EU::MM when creating new distributions. A very solid offering.
1 hidden unhelpful review