Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>We use <a href="http://search.cpan.org/dist/Module-Build/" rel="nofollow noreferrer">Module::Build</a> in our group.</p> <p>The main reason is <strong>Easy Extensibility</strong>.</p> <p>Module::Build allows you to do more with your build process in pure Perl through subclassing. If you want to do more using <a href="http://cpanratings.perl.org/dist/Module-Install" rel="nofollow noreferrer">Module::Install</a>, you have to have knowledge of how Makefiles work, AFAIK. Since you presumably already know Perl, this can be an advantage.</p> <p>As you said, using Module::Build removes the dependency on an external <code>make</code> program, which can be viewed as a good thing.</p> <p>However, the main cons that I can think of are:</p> <ul> <li>Although Module::Build has hit core, not everyone will be using an up-to-date version of Perl. For users with older versions of the core, you will be creating a new dependency.</li> <li>Lots of veterans (not necessarily Perl people) are used to the <code>perl Makemaker.PL; make; make install</code> paradigm, and can be thrown off by having <code>Build.PL</code> instead. Hopefully this isn't a big deal.</li> <li>Module::Build has occasionally broken our builds when its functionality has changed because the documentation didn't cover an edge case which we were using. The edge case was then changed and documented, but we had to re-code our subclass to get our build to work again (this happened for us at the recent upgrade from 0.2808 to 0.3).</li> </ul> <p>All that said, though, I still recommend Module::Build simply for the extensibility. If that's not an issue for you, you may be better off sticking with Module::Install.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload