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.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Part of the impetus of Module::Build is to ensure ExtUtils::MakeMaker dies a much needed death. Those who haven't had to do serious hacking on EMM often say that this is a waste of time. Those who have had to do serious hacking on EMM, particularly when they know their hack must support a plethora of systems they don't have access to (really, how many people have a VMS box handy?), absolutely don't want to touch EMM any more. Since much of EMM is trying to build a makefile which many different platforms

    • Funny. I'm responsible for at least two Schwern rants about EU::MM. Curious.

      My real 0XBEEF with M::B and M::I probably stems from three things: 1) the seemingly endless times of cpanp/cpan fuckering up automated testing and deps, and 2) Apache-Test under M::B, which has it's own set of issues and 3) Catalyst installs post EU::MM. Yes, these are not M::B/M::I's problems, but when I can stick to EU::MM and avoid those issues, well, then there's still no reason to declare EU::MM dead for all people.

      Since I'd r
    • There's a sensible distribution of work though. There aren't many people who need to hack on EU::MM - just a select few. For 99.99% of people it works just fine. In most cases where people try to do stuff out of the ordinary with it they probably shouldn't have tried that in the first place.

      I'm still not convinced M::B is worth it (and yes, I've read the rants) for end users - neither module authors nor those installing modules. Seems M::B is worth it for Schwern, and maybe the select few others who wanted
      • Personally, I use M::B, and just throw in create_makefile_pl => 'traditional' in the Build.PL. I use only plain-jane features of M::B, so the modules I upload will work for any user, and come the day that M::B becomes the new officially sanctioned Way To Do It, I can just flip a switch and get rid of the Makefile.PL.

        Best of all worlds, if you ask me.

      • I've hacked on EUMM (to add tests) and I've written cross-platform Makefiles. Maybe that puts me in a narrow group of people and makes my opinion suspect. I don't know; I like to think it gives me specific reasons to hate EUMM.

        If my build process has to do anything other than copying a pure-Perl module into blib/lib, I would rather do it in Perl than figure out how to write Perl to write cross-platform, cross-shell Makefiles. It's not that I can't figure out how to make it work, it's that every time I

        • You don't touch the Makefile though. You just do WriteMakefile(%params) and it's all done for you. I don't quite get the argument.
          • Let me be very concrete then. When writing the build process for Embed::Parrot, I wanted to use parrot to compile a PIR file into PBC. I want to do this as part of the build process before the test process, so I overrode ACTION_build in Build.PL. I assume, from writing other makefiles, that adding to the test target is the way to go with EUMM.

            How do I do this with EUMM? I've skimmed the manpage backwards and forwards and I don't see an easy way to do it without touching the Makefile.

    • I'm sure all of that is true, but it's orthogonal to my point, which is that the installer doesn't know if the module author is an enlightened Module::Build user or a dinosaur who only maintains the EUMM system for his module and lets the other route decay. As an installer, I could care less which system is used as long as it just works. :)

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • My response is confusing because when I said "installer," I meant, "installing admin," not "installing program."

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
  • I’m peripherally aware that for backward compatibility Module::Build authors often supply a Makefile.PL that I think is basically a thin wrapper around the Module::Build process or something.

    It can be. There is also an option to produce a fully self-sufficient Makefile.PL that doesn’t rely on M::B at all. This is what I use and recommend (for the time being).

    I’m certain that in every case one of these options is better maintained than the other.

    I’m certain that in every cas

    • I’m certain that in every case it is the Build.PL that should be preferred.

      In that case, I believe that CPAN.pm should be programmed to do this. Users of CPAN.pm generally don't care which option is used as long as it works.

      This option should default to one of the choices, and it’s obvious which one that should be.

      I'm not really sure the option should exist, then. If you care enough to want to select Makefile.PL over Build.PL, then it seems like you know enough to be doing it by hand

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • I would agree with all of the conclusions you drew from my points. I’m just not sure the maintainer of CPAN.pm wants to make a choice that is at this point somewhat political; hence, I assume, the user-level option.

    • BTW, I just went through this again on another box, and noted that it defaults to EUMM rather than MB.

      --
      J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers