Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Busy busy... 3 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I like Ken Williams' work a lot, but Module::Build is not shipped with Perl. Don't use Module::Build unless you have a problem that it solves better than MakeMaker. That would be something like interactive questions for the user.

    Alternatively, support both equally well by using the "traditional" option for creating a Makefile.PL from Module::Build. Otherwise I would have to install Module::Build on every machine where I want to put your module, for no good reason.

    • Re:please don't (Score:1)

      by knowmad (2542) on 2004.12.09 8:28 (#36660)

      I too really like Module::Build and use it exclusively when developing internal projects. However, I think that wisdom of the previous two posters prevails until such time as M::B is shipping with a mainstream version of Perl.

      Because I haven't released many modules to CPAN, I didn't even realize M::B could generate a traditional Makefile.PL. Indeed the create_makefile_pl parameter to new() in conjunction with Module::Build::Compat should generate the file as Perrin describes. Cool!

      • Doh, I also meant to mention ExtUtils::ModuleMaker [cpan.org] which I use for creating my base packages. It can generate EU::MM, M::B, or M::B with a proxy Makefile.PL packages. The latter option isn't much help to you since it would still require M::B to be installed on the target system (it's like the 'small' style of create_makefile_pl).

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.