Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation


by rinceWind (Monsignor)
on Apr 30, 2003 at 16:50 UTC ( [id://254380]=modulereview: print w/replies, xml ) Need Help??

Item Description: A replacement for ExtUtils::MakeMaker

Review Synopsis: Module::Build is the future of CPAN installs

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
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.


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
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.


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.

Replies are listed 'Best First'.
Re: Module::Build
by Anonymous Monk on Apr 30, 2003 at 22:18 UTC
    A note for anyone wanting to use Build.PL and provide a Makefile.PL, please be aware of the conflicts. If you use a Makefile.PL, don't have it write a Makefile, just have it print a message saying use Module::Build and run perl Build.PL
      A note for anyone wanting to use Build.PL and provide a Makefile.PL, please be aware of the conflicts. If you use a Makefile.PL, don't have it write a Makefile...
      This comment must be based on old information. There is currently no problem with Makefile.PL generating Makefile.
      ... just have it print a message saying use Module::Build and run perl Build.PL
      No! This then forces the user to have Module::Build installed.

      If you don't want to support a Makefile.PL script in your distribution, then just don't put one in it. Or better yet, make use of Module::Build's capability to generate a Makefile.PL script.

      Remember: There's always one more bug.
        Doc excerpt:

        ExtUtils::MakeMaker has been a de-facto standard for the common distribution of Perl modules; Module::Build is expected to supersede ExtUtils::MakeMaker in some time (part of the Perl core as of 5.10?)

        The transition takes place slowly, as the converting process manually achieved is yet an uncommon practice. The Module::Build::Convert Makefile.PL parser is intended to ease the transition process.

Re: Module::Build
by Anonymous Monk on Apr 30, 2003 at 22:14 UTC
    It seems quite stable now
    What is this based on? Pixies and fairy dust? Module::Build is suprisingly nowhere near ready. Sure 5.10 is a ways off, but still, I don't see what the hold up is. The XS support is ridiculously horrible. Please write a review once this module is useful for something other than toy installs, until then, it's all speculation.
      What is this based on? Pixies and fairy dust? ...
      It's based on pragmatic experience. I've actually found it very useful for automating many tasks that happen alongside installation - hence my comments about using Module::Build for other things than installing modules.

      However, I've never written an XS module, and I have no idea how well or otherwise Module::Build holds up when building external C code, but I meet regularly with some mongers who write XS code who swear by Module::Build. OK, if there are deficiencies here, please post feedback to the authors of the module. I don't feel it invalidates what I have to say in my review.

        Module::Build's XS support is still in alpha phase (according to its POD), and still somewhat buggy (I've submitted bug reports for all of the items below).

        For XS support to work, ExtUtils::ParseXS must be installed. Module::Build doesn't check for it, so you must add it to 'build_requires' in Build.PL.

        Module::Build doesn't generate VERSION and XS_VERSION for compiling the C code generated from the XS code. You need to add them to 'extra_compiler_flag' in Build.PL.

        Your Build.PL file should check for have_c_compiler() if you plan to upload it to CPAN.

        Remember: There's always one more bug.
Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: modulereview [id://254380]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (2)
As of 2024-07-23 05:41 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.