Like I said in my previous blogpost, Module::Build has some serious technical problems. This causes another problem that I didn't discuss previously, but that's maybe the worst thing: no one loves it. MakeMaker also has some crazy internals, but it commands the love of a dedicated group of hackers. It's because of that more than anything else that I'm pretty sure its flame won't extinguish any time soon. Module::Build does not have such a luxury; no one seems motivated anymore to maintain it (if you are, do please take up contact with its current maintainer, David Golden). I fear Module::Build is screwed.

The way out

The core idea of Module::Build, that of a module builder written in Perl itself is a really good one in my opinion. Module::Build paved the way to do that, but this idea is not tied to Module::Build. End users and CPAN clients don't really care what's behind that Build.PL command, as long as it behaves according to the interface that was defined by Module::Build. That interface is currently in the process of being specified. The first experiment is Module::Build::Tiny, a proof-of-concept that does the simplest thing possible for pure Perl modules.

The module builder I dream of

Since 5.10.1 the toolchain supports configure_requires. This means that the end user no longer has to have the install tool installed before installing the module, the toolchain will take care of this. This means that now the module building is just another program for most purposes.

1. Dependencies
   Module::Build does not have a proper dependency graph. This decision is in many ways at the core of it's design. Writing a proper dependency graph has a serious upfront costs and makes a lot of simple things more complicated, however it also makes a lot of complicated things more simple. It also makes it much more simple to debug various issues, if only because you can serialize a graph.

2. Abstraction
   ExtUtils::MakeMaker uses make, which does have a dependency graph. However there is no convenient way to manipulate it. It boils down to either appending some make commands to the string containing the Makefile or even manipulating it using regexps. This makes it way too difficult to customize the build process. CPAN authors should be able to specify what they want done, not how.

3. Extendability
   Like I said in my previous post, Dist::Zilla showed how easy it can be to extend a program. My imaginary module builder should be just as extendable. However that doesn't mean it shouldn't have the right defaults. The default configuration that handles modules that don't do anything special (which is probably 95% of them right now) should be as simple as:

   [@Basic]
   

   The Build.PL wouldn't need to contain any state. It would probably be as simple as:

   use Dist::Build;
   Build_PL(@ARGV);
   

   More simply isn't necessary. All data is either in the the meta file, configuration file or is generated by plugins.

   The extensions could be anything, though I would obviously expect most to affect the build stage like editing or serializing the graph (perhaps even to a makefile), but it could also be in configuration (e.g. meta information), testing and installing.