Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
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 the section on "/www.dsmit.com/cons/" in the http: manpage . Please contact me if you have any questions or ideas. AUTHOR Ken Williams, email@example.com SEE ALSO perl(1), ExtUtils::MakeMaker(3) http://www.dsmit.com/cons/