Module::Build - Perl extension for blah blah blah
perl Build.PL ./Build # this script created by 'perl Build.PL' ./Build test ./Build install Other actions: ./Build clean ./Build realclean
This is a very alpha version of a new module set I've been working on,
Module::Build. It is meant to be a replacement for
Module::Build, and any other module that uses
Module::Build for its installation process, do the following:
perl Build.PL ./Build ./Build test ./Build install
Other actions so far are:
./Build clean ./Build realclean ./Build fakeinstall ./Build dist
It's very much like the
MakeMaker metaphor, except that
Build is a Perl script, not a Makefile. State is stored in a directory called
Any customization can be done simply by subclassing
Module::Build and adding a method called (for example)
ACTION_test, overriding the default action. You could also add a method called
ACTION_whatever, and then you could perform the action
More actions will certainly be added to the core - it should be easy to do everything that the MakeMaker process can do. It's going to take some time, though. In the meantime, I may implement some pass-through functionality so that unknown actions are passed to MakeMaker.
There are several reasons I wanted to start over, and not just fix what I didn't like about MakeMaker:
I don't like the core idea of MakeMaker, namely that
makeshould be involved in the build process, for these reasons:
When a person is installing a Perl module, what can you assume about their environment? Can you assume they have
make? No, but you can assume they have some version of Perl.
When a person is writing a Perl module for intended distribution, can you assume that they know how to build a Makefile, so they can customize their build process? No, but you can assume they know Perl, and could customize that way.
For years, these things have been a barrier to people getting the build/install process to do what they want.
There are several architectural decisions in MakeMaker that make it very difficult to customize its behavior. For instance, when using MakeMaker you do
use MakeMaker, but the object created in
WriteMakefile()is actually blessed into a package name that's created on the fly, so you can't simply subclass
ExtUtils::MakeMaker. There is a workaround
MYpackage that lets you override certain MakeMaker methods, but only certain explicitly predefined (by MakeMaker) methods can be overridden. Also, the method of customization is very crude: you have to modify a string containing the Makefile text for the particular target.
It is risky to make major changes to MakeMaker, since it does so many things, is so important, and generally works.
Module::Buildis an entirely seperate package so that I can work on it all I want, without worrying about backward compatibility.
Finally, Perl is said to be a language for system administration. Could it really be the case that Perl isn't up to the task of building and installing software? Absolutely not - see the
Conspackage for one example, at http://www.dsmit.com/cons/ .
Please contact me if you have any questions or ideas.
Ken Williams, firstname.lastname@example.org