Slash Boxes
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

use Perl Log In

Log In

[ Create a new account ]

ajt (2546)

  (email not shown publicly)

UK based. Perl, XML/HTTP, SAP, Debian hacker.

  • PerlMonks: ajt []
  • Local LUG: AdamTrickett []
  • Debian Administration: ajt []
  • LinkedIn: drajt []

Journal of ajt (2546)

Tuesday February 06, 2007
03:10 PM

Build.PL versus Makefile.PL

[ #32329 ]

In the CPAN modules I maintain, three use both ExtUtils::MakeMaker and Module::Build and the most recent only uses Module::Build. I find Module::Build easier to work with and it has advantages that I use. I don't like having to maintain and update both of them, so my most recent module only has Module::Build.

To improve my testing I use several optional modules, and use the build process to probe for and only run tests that can be run - rather than getting the tests to skip.

People doing smoke tests on my modules report false positives because they try to run tests that can't be run. I'll put steps in place to prevent that from happening, but in the mean time I wonder do people think that both build processes will hang around in parallel for ever? will one replace the other? which one will become "standard"?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Surely whatever about the future ExtUtils::MakeMaker is the standard now.

    Why is handling testing dependencies best done in the Makefile.PL/Build.PL? What are the advantages over skipping tests?
    • Why is handling testing dependencies best done in the Makefile.PL/Build.PL?

      I believe that's so that META.yml can express dependencies required for the build properly.

      What are the advantages over skipping tests?

      CPANTS penalizes you for not shipping POD checking tests, but their value to anyone but developers is minimal, for example.

    • > Why is handling testing dependencies best done in the Makefile.PL/Build.PL?

      It's not so much "testing" as "checking".

      In multi-platform source packages (like CPAN packages) the dependencies of a package require turing-completeness to determine. That is, a dependency on your platform might be different to the dependencies on some other platform.

      Part of the job of the Configure phase (Makefile.PL and Build.PL) is to resolve the Complete Dependencies down to a set of Static Dependencies. That static list ca
  • I have not figured out how to keep Module::Build modules from installing pod when they don't use the compatibility layer. That keeps me from using them in my product.

    Having a 'make pure_all' and a 'make pure install' (or something similar) is a requirement for me. Is there a way to do that with Module::Build?
  • You need to have a Makefile.PL, even if it's (correctly) auto-generated.

    Because at the moment, if you install a fresh version of Perl 5.8.8, and then try to install your module, it will fail. Because Module::Build has a configure-time dependency (a dependency needed just to run Build.PL) which CPAN clients are not currently capable of handling.

    Go try it.

    Until this situation is fixed, and your module is actually installable on the most common stock production Perl versions, you should keep producing Makefile
  • ExtUtils::MakeMaker will live forever, at least until you can upgrade all those systems with 5.5_003 (Solaris 8) or 5.8.4 (Solaris 10) deployed, or stop caring about the users of "old" versions of Perl. Whatever the goal of the Module::Build authors is, I hope that people will not use Module::Build where they can just as well use EU:MM.