Hi,

Johan Vromans requested that I post a short description of Module::Build 
itself.  Here's an excerpt (though not necessarily short) from the docs:

DESCRIPTION
        This is a beta version of a new module set I've been
        working on, "Module::Build".  It is meant to be a pure-perl
        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             # this script is created by 'perl Build.PL'
           ./Build test
           ./Build install

        Actions defined so far include:

          build                          help
          clean                          install
          dist                           manifest
          distcheck                      realclean
          distclean                      skipcheck
          distdir                        test
          disttest                       testdb
          fakeinstall

        It's like the "MakeMaker" metaphor, except that "Build" is
        a short Perl script, not a long 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.

        For information on providing backward compatibility with
        "ExtUtils::MakeMaker", see the Module::Build::Compat
        manpage.
....
MOTIVATIONS
        There are several reasons I wanted to start over, and not
        just fix what I didn't like about MakeMaker:

        o   I don't like the core idea of MakeMaker, namely that
            "make" should be involved in the build process.  Here
            are my 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.

        o   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.

        o   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.

        o   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
            "http://www.dsmit.com/cons/"; .


  -Ken

Reply via email to