/ 
Module-Build-0.02
River stage five • 4637 direct dependents • 18131 total dependents
/ Module::Build

NAME

Module::Build - Perl extension for blah blah blah

SYNOPSIS

  perl Build.PL
  ./Build             # this script created by 'perl Build.PL'
  ./Build test
  ./Build install

Other actions:

  ./Build clean
  ./Build realclean

DESCRIPTION

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 ExtUtils::MakeMaker.

To install 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 _build/.

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 ./Build whatever.

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.

MOTIVATIONS

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 make should 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 MY package 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::Build is 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 Cons package for one example, at http://www.dsmit.com/cons/ .

Please contact me if you have any questions or ideas.

AUTHOR

Ken Williams, ken@forum.swarthmore.edu

SEE ALSO

perl(1), ExtUtils::MakeMaker(3)

http://www.dsmit.com/cons/