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, ken@forum.swarthmore.edu

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

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