rinceWind has asked for the wisdom of the Perl Monks concerning the following question:

Having been asked to write an enhancement to an existing CPAN module (CGI::Wiki::Kwiki), I find that its MANIFEST contains both a Build.PL and a Makefile.PL, which contain a different list of prerequisites.

I also know that this module has been worked on by more than one person. I just wonder what the currently accepted wisdom is for modules that offer both Build.PL and Makefile.PL for backwards compatibility.

I also wonder if I should just fix the dependency list in both scripts, or adopt a different mechanism in the module patch I am working on.

There are also wider issues involved, such as whether Module::Build needs to be installed on the target machine. With the current, traditional method, installing does not require Module::Build.

Note: I know it's a touchy subject with some people, but this is not an invitation for a flame war, as happened with this post. I am a fan of Module::Build, as is apparent from my review of this module. Do you agree with the second anonymonk's reply to this review?

--
I'm Not Just Another Perl Hacker

Update: The Makefile.PL contains a comment at the top, to indicate that is was generated by Module::Build::Compat->create_makefile_pl. Clearly, anyone updating this module needs to re-invoke this if they change Build.PL - this clearly does not happen automatically.

From the POD to Module::Build::Compat, the style used is 'traditional'. Maybe a call to create_makefile_pl needs to go inside Build.PL somewhere as an action. Thoughts please.

Replies are listed 'Best First'.
Re: Module::Build compatibility woes
by PodMaster (Abbot) on Dec 07, 2003 at 13:39 UTC
    1. They have the same prerequisites, so there is nothing to fix there (yes, i'm sure).
    2. Module::Build should not be forced upon users until it starts generating .packlist's (at least -- no packlist means there is no clean way to uninstall a module).

      I'll personally continue writing Makefile.PL's for distributions which have fake Makefile.PL's (or no Makefile.PL's) until Modle::Build starts generating packlist's.

    3. I do agree with the "second anonymonk". Unless Makefile.PL is going to write a Makefile (a MakeMaker generated Makefile), what's the point in including it (other than to cause trouble)?

      Apparently CPAN.pm doesn't support Build.PL, but I can't say I much care :)(if you can install Module::Build, you can install CPANPLUS.pm).

    BTW, at least Module::Build is better than Make.pm (and thank *someone* rarely any PAUSE authors are using it).

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]
Re: Module::Build compatibility woes
by Aristotle (Chancellor) on Dec 07, 2003 at 12:47 UTC
    Have a look at Module::Build::Compat. It lets you generate a Makefile.PL which in turn writes a makefile that delegates back to Build.PL.

    Makeshifts last the longest.

[reply]
      I highly reccomend against that (it's a foolish idea and it just doesn't work, for example, make test TEST_VERBOSE=1 won't translate to perl Build test verbose=1 and the list goes on).

      MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
      I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
      ** The third rule of perl club is a statement of fact: pod is sexy.

[reply]

Back to Seekers of Perl Wisdom