First, depending upon how you count it, Perl runs on over 40 operating systems. Those operating systems often have a different command line syntax, limits on command length, different ways of specifying file paths, etc. The makefile generated by MakeMaker needs to be aware of this.

Now lets consider how many different make programs are out there. Let's consider that different versions of the same make program are often incompatible and multiply that by the number of operating systems you have to support and you begin to see why MakeMaker has become so difficult to maintain, much less extend. (anyone wonder why so many Java programmers use Ant instead of makefiles?)

So what does all of this translate to in real-world terms? Schwern offers some insight about the differences between MM 6.25 and 6.26 (and note that this is only a point release!):

Its nearly 200k. 7000 lines. Took three months and 12 alpha releases to get it right (and its still not right). Total number of non-trivial features added? 2. All the rest is bug fixes and code cleanup and repairing the repercussions of that... and then fixing the new bugs those fixes introduced... and so on.

That's what's wrong with ExtUtils::MakeMaker. As a member of TPF, I've heard a number of complaints about how MakeMaker gathers a lot of dust between releases. It's something that have come up in grant committee discussions more than once. People want these problems solved. They want open-source programmers to volunteer even more time to fix problems the programmer may not have (and on operating systems the programmer may not have access to) and if the programmer doesn't do this, people get upset. Maybe you now have a small inkling of the scope of the problem.

Clearly the biggest complaint about Module::Build is the lack of PREFIX. There's also the complaint that it doesn't offer the same interface and thus is not entirely backwards compatible. (Of course, it's tough to verify the backwards compatability without having all of those make programs and operating systems at your disposal.) However, I find it interesting to note how many people complain that Module::Build doesn't have all of the features that MakeMaker has and yet they ignore all of the features that that MB has which MM does not (and having used MB quite a bit for the past six months, I confess that I like these features.) For example:

• Better dependency resolution
• Builds HTML docs
• Test coverage (./Build cover)
• Help (./Build help)
• See what's really being changed (./Build diff)
• Versioned installs
• Runs if make is not available
• License metadata is captured

There's more, but if you read the docs, you'll see that.

Many of you will object "but I don't need that stuff!" Again, I point out that a proper build system must satisfy the needs of all users, not just yours, and it's a heck of a lot easier to reliably add many of those things to MB than to MM. Heck, you want to build PAR support to create a standalone executable? Subclass MB and add this:

sub ACTION_par { ... }

Of course, the devil is in the details, but many features you want to add are a simple matter of filling in that sub. For example, when we needed some custom config files to support whatever database our user picked, here's what we did:

sub ACTION_test {
    my $self = shift;
    $self->depends_on('code');
    $self->depends_on('config');

    # Set up the test configuration file.
    $self->conf($self->notes('test_conf_file'));

    $self->SUPER::ACTION_test(@_);
}
[download]

And now when a user runs ./Build test, the config files are properly created. For comparison, why don't you post what would need to be added to a makefile to support something similar and note which operating systems it works on, which make distribution it works on, which versions of that distribution may have problems, etc. Heck, most of us can't do that because we don't know make or, if we do, we don't know the many corner cases involved. Most of us know Perl, though.

Yes, this does require learning a different way of doing things, but when you need a large, robust, easily configurable build system, MakeMaker isn't there, either. Module::Build can get there, but pretending that MakeMaker can keep up isn't realistic. It's hitting its limits. And with Schwern being the maintainer and the only active developer, if he goes crazy(er), gets hit by a bus or just quits, MakeMaker is going to gather even more dust. MB, on the other hand, is much easier to work on, once you put the time into it.

---

^* For those who are claiming that Ken Williams and Schwern aren't terribly responsive, I do find it interesting to note how many changes are reported by and credited to other people. It was mentioned in the chatterbox by one person that their emails were not being answered and a patch they sent was not incorporated. I'm curious about where those emails were sent and what the patch was for.