The following module was proposed for inclusion in the Module List:

  modid:       Module::Build
  DSLIP:       bdpOp
  description: Build and install Perl modules
  userid:      KWILLIAMS (Ken Williams)
  chapterid:    3 (Development_Support)
  communities:
    #perl, [EMAIL PROTECTED], [EMAIL PROTECTED]

  similar:
    ExtUtils::MakeMaker

  rationale:

    From the docs:

    =head1 MOTIVATIONS

    There are several reasons I wanted to start over, and not just fix
    what I didn't like about MakeMaker:

    =over 4

    =item *

    I don't like the core idea of MakeMaker, namely that C<make> should
    be involved in the build process. Here are my reasons:

    =over 4

    =item +

    When a person is installing a Perl module, what can you assume
    about their environment? Can you assume they have C<make>? No, but
    you can assume they have some version of Perl.

    =item +

    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.

    =back

    For years, these things have been a barrier to people getting the
    build/install process to do what they want.

    =item *

    There are several architectural decisions in MakeMaker that make it
    very difficult to customize its behavior. For instance, when using
    MakeMaker you do C<use MakeMaker>, but the object created in
    C<WriteMakefile()> is actually blessed into a package name that's
    created on the fly, so you can't simply subclass
    C<ExtUtils::MakeMaker>. There is a workaround C<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.

    =item *

    It is risky to make major changes to MakeMaker, since it does so
    many things, is so important, and generally works. C<Module::Build>
    is an entirely seperate package so that I can work on it all I want,
    without worrying about backward compatibility.

    =item *

    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? Even if that software is a bunch
    of stupid little C<.pm> files that just need to be copied from one
    place to another? Are you getting riled up yet??

    =back

    Please contact me if you have any questions or ideas.

  enteredby:   KWILLIAMS (Ken Williams)
  enteredon:   Thu Jun 27 07:39:11 2002 GMT

The resulting entry would be:

Module::
::Build           bdpOp Build and install Perl modules               KWILLIAMS


Thanks for registering,
The Pause Team

PS: The following links are only valid for module list maintainers:

Registration form with editing capabilities:
  
https://pause.perl.org/pause/authenquery?ACTION=add_mod&USERID=b2200000_a520c11c607aa8f3&SUBMIT_pause99_add_mod_preview=1
Immediate (one click) registration:
  
https://pause.perl.org/pause/authenquery?ACTION=add_mod&USERID=b2200000_a520c11c607aa8f3&SUBMIT_pause99_add_mod_insertit=1

Reply via email to