Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Build.PL versus Makefile.PL

by ajt (Prior)
on Feb 06, 2007 at 20:28 UTC ( #598631=perlmeditation: print w/ replies, xml ) Need Help??

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"?

I see that the merits of both systems have been discussed briefly here in the past I'm just curious to the current state of play.


--
ajt

Comment on Build.PL versus Makefile.PL
Re: Build.PL versus Makefile.PL
by Tanktalus (Canon) on Feb 06, 2007 at 21:10 UTC

    Current state? I don't see either one going away. Even if, say, everyone were utterly convinced of the obvious superiority of one over the other, there are too many modules that need too little maintenance to completely effect any definitive change to tools such as CPAN. Perhaps one day, one will be so underused that it is no longer ported to a new platform (somewhat unlikely). But then TPTB would have to decide: port the install module, or port the underlying module to the other install module. My bet is that they'll go for porting the install module, no matter how unwieldy it may or may not be, just because porting someone else's module and releasing it may be seen as "more evil" (as in, usurping a module) than porting the installer.

Re: Build.PL versus Makefile.PL
by dragonchild (Archbishop) on Feb 06, 2007 at 22:12 UTC
    The plan, as I understand it, is that M::B will become part of the core starting in 5.10. At that point, there will be a push to have all CPAN distros migrate to using M::B vs. EU::MM which has been unofficially deprecated.

    In the meantime, I use M::B with the traditional flag.


    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
      I use EU::MM because I have yet to see any benefits at all that I would get from using M::B. I will continue to use EU::MM until I do, whether it be deprecated or no. To change merely for the sake of fashion - and with no good reason that really is all it would be - would be foolish.
        I will continue to use EU::MM until I do, whether it be deprecated or no. To change merely for the sake of fashion - and with no good reason that really is all it would be - would be foolish.

        I've not read the rest of the thread, but from a general pragmatic pov, while I agree with the latter claim, I don't on the former one. Also, "fashion" in general may mean all or nothing. Of course it carries the risk of promoting stuff that has no real value to be. But it may also be a good fashion instead. OTOH sticking with something just because "it does" is not a good way to operate. Indeed we should all be still programming with Perl 4 techniques because they did the job, after all...

        Of course if something gets deprecated there may well be a good reason why. One's opinion may differ, and with... ehm... good reasons too. But one cannot assume that in a collectively taken choice all the others will be dumb idiots...

Re: Build.PL versus Makefile.PL
by xdg (Monsignor) on Feb 07, 2007 at 05:34 UTC
    People doing smoke tests on my modules report false positives because they try to run tests that can't be run.

    I believe that most smoke testers are based on CPANPLUS. CPANPLUS support for Module::Build has been (and may still be) flaky. CPANPLUS::Dist::Build was split out separate from the main CPANPLUS distribution in an attempt to improve support. The most recent release adds support for the build_requires parameter -- previously, this was the cause of numerous test failures.

    If CPANPLUS-based smoke testers upgrade to the latest CPANPLUS::Dist::Build (and perhaps additional bugs are fixed), or if smoke testers switch to CPAN.pm and CPAN::Reporter, these problems should go away.

    -xdg

    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re: Build.PL versus Makefile.PL
by grinder (Bishop) on Feb 07, 2007 at 11:00 UTC

    Module::Build is now part of the Perl core, as of perl 5.9.4 or so. There are vague plans afoot to ship 5.10 some time this year, but as the perl5-porters are all volunteers, finding the necessary time to smoke out errors it may have is the hardest part. But it will be part of the standard distribution in the future.

    I don't see what problem you have with skipping, especially if not doing so means you wind up with failures in the test suite because other users don't have the same setup as you. Just skip and be done with it. Either that, or specify them as prerequisites in the configuration (whether it be M::B or EU::MM so that they get downloaded beforehand).

    I have recently taken over the maintenance of a couple of Win32-specific modules that were designed to be built with Module::Build. As it turns out, ActiveState doesn't bundle this module in its distribution, so the first thing I did was to switch back to EU::MM, so that if other people want to hack on it, they don't have to download Module::Build beforehand.

    • another intruder with the mooring in the heart of the Perl

      so the first thing I did was to switch back to EU::MM, so that if other people want to hack on it, they don't have to download Module::Build beforehand

      ++ for catering to us retro-progressives.

      Cheers,
      Rob

      I also posed the same question on use.Perl. I got a selection of opinions there too.

      There are advantages to Module::Build, in particular on platforms without compilers, e.g. Windows and it will apparently become the "standard". However the traditional method is more tested and far more common.

      In my case I just need to fiddle with the Makefile.PL and make it add optional tests. Basically I need a bunch of modules to test the code, they aren't actually need to use it, so I don't like making them pre-requisits if I can help it. I prefer to use Module::Build, it is easier for me but I'll have to maintain both...


      --
      ajt

        Why don't you just write your tests to skip if the required module is unavailable? I have many tests that basically do:

        my $can_run; my $reason; BEGIN { $can_run = eval { require My::Module; require Some::Other::Module; 1; }; $reason = $@; }; use Test::More; if (! $can_run) { $reason ||= "no reason given"; plan skip_all => "Prerequisite module not found ($reason)"; exit; } else { plan tests => 42; }; ...

        Also, I find the idea of "standard" amusing/confusing - does that mean that all modules currently using ExtUtils::MakeMaker will go out of existence or that people will hurry to Module::Build because nobody cares about compatibility with older versions of Perl anymore?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://598631]
Approved by Paladin
Front-paged by rinceWind
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (10)
As of 2014-09-02 21:57 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (31 votes), past polls