Skip to content


Subversion checkout URL

You can clone with
Download ZIP
Perl module to configure and build modules (what backs most Build.PLs)
Perl Perl6

Fetching latest commit…

Cannot retrieve the latest commit at this time

Failed to load latest commit information.


    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

    To install `Module::Build', and any other module that uses
    `Module::Build' for its installation process, do the following:

       perl Build.PL
       ./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 `./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.

    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 "/" in
        the http: manpage .

    Please contact me if you have any questions or ideas.

    Ken Williams,

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

Something went wrong with that request. Please try again.