There is much talk in the Perl world about Module::Build. Discussion surfaced originally around February 2003, when Mike Schwern published a paper of advocacy. Please refer to this thread for PM's reaction at the time.

More recently, I attended a Perl monger tech talk, at which Schwern was presenting "MakeMaker is doomed!". Prior to the talk, I was somewhat skeptical. After all, Makefile.PL works, Nearly all of CPAN uses a recognised and recognisable installation process:

perl Makefile.PL
make
make test
make install
[download]

I'd also heard that some prominent people in the Perl community have abandoned MakeMaker for all new modules, in favour of Module::Build. Having attended the talk, I began to see why.

Portability

The MakeMaker method relies on two mechanisms which are not truly cross-platform:

• make
• the shell

Why do this, when we have an excellent scripting language which is totally cross-platform? Why indeed not have a pure perl installation mechanism?

This is indeed what Module::Build is, and it calls no modules which use XS. The steps are replaced with:

perl Build.PL
perl Build
perl Build test
perl Build install
[download]

In my opinion, Build.PL should have been named Configure.PL, so as to remove completely, any confusion between the first two steps. I am raising this point with Ken Williams and others.

I came away from Schwern's talk convinced that Module::Build is the future. Also, there is talk that it is entering the core of 5.10, which will greatly help the advocacy cause.

Complex configuration

In the mean time, there is a circumstance when I would completely recommend adopting Module::Build. The initial step, running the perl program Makefile.PL has been greatly simplified and freed. For trivial installations, there is probably no mileage in moving to Module::Build, as the Makefile.PL contains a single call to WriteMakefile. For non-trivial installations, you might experience difficulties getting help writing and fixing your Makefile.PL.

Module::Build uses an OO interface, and the actions that you want to do in configuration are method calls. For doing _really_ clever stuff you can subclass Module::Build.

Using Module::Build for other than modules

This new flexibility means that Module::Build becomes available for other purposes - in fact for any kind of controlled install. For example, it can be used to deploy database schemas and suites of standalone perl scripts. An example of a project where this has been used is on OpenGuides - a project I am involved with.

Conclusion

It seems quite stable now, and there are many people out there using it. I am not advocating a wholesale morphing of CPAN to this mechanism overnight. Once 5.10 goes in and stable with Module::Build in the core, we should push for all new modules to use it.

Update, October 2004

I am nowhere near as happy with Module::Build as when I originally wrote this review. In particular, I have the following issues:

• Automated installs with CPAN don't happen. Though they might if you are lucky and the module author has provided a compatibility Makefile.PL that does everything Build.PL does. Apparently CPANPLUS supports Module::Build builds, but I have had problems getting CPANPLUS working at all on some platforms.

• Build.PL does not have the standard command line options that Makefile.PL uses. In particular, there is not an equivalent of PREFIX=x, which I need for builds where I am installing to platforms where I don't have root.

• Some module kits have a Build.PL and a Makefile.PL which build differently. This may well be an oversight on the part of the module author, but it does not reflect well on the underlying build mechanism.

• I have also had issues building XS code with Module::Build.

With hindsight, I think that Schwern was right that ExtUtils::MakeMaker is due for review. However, Module::Build is too much of a step for most module authors, and most Perl admins. Also, Perl 5.10 is still well beyond the horizon.

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.