A week or two ago, I configured a newer version of CPAN.pm than I have ever used. Don't laugh if this is old news, but one of the configuration options that were new to me involved the choice between Makefile.PL and Module::Build.
I have written modules that use Makefile.PL, but never Module::Build. 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. I don't trouble myself too much with it. CPAN.pm usually handles this just fine for me, I'm sure that Module::Build is the wave of the future, and I will learn about it when the benefits I'm aware that it provides exceed the cost of learning it, which is to say, "some day." :)
I think this configuration option wanted me to select which method I preferred in situations where I had a choice in installing a module: if both a Makefile.PL and a Module::Build are present, which one would I prefer to use? In retrospect, it seems to me that this is a decision best answered by the module author, not the module installer. I'm certain that in every case one of these options is better maintained than the other. And I suspect that for many modules, one day the difference in quality between the well-maintained and the less-maintained routes will be enough that one route will cease to be maintained for that module.
So it seems to me that it would be nice if Module::Build files and/or Makefile.PL files could have a new option added, one which specifies which installation method is the one preferred by the module author and is therefore likely to be more maintained. Then CPAN.pm could check this and try the better maintained route first. Personally I don't care which method is used, as long as the installation is flawless and the module solves all of my problems including world hunger. :) So as a module installer, this question is really not that relevant to me.
Of course, getting this option into Module::Build and/or Makefile.PL and CPAN.pm has a cost, and the cost involved might be so much that by the time it is spent (it is likely to be a time cost) everybody will be using Module::Build anyway. But it was something to think about.
In retrospect upon completing this post, it dawns on me that the best thing to do is teach CPAN.pm to be aware of some new third file which will indicate the installation method recommendation in some machine-readable way, rather than mucking about with Module::Build itself.
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 and many different versions of make support (all, naturally, with subtle differences), how many people wanting EMM can say they are qualified to comment in this area? Trying to work out all of the hideous makefile issues is a nightmare and is a constant source of bugs. Further, adding new features to EMM is very difficult, but it tends to be much easier for MB. Thus, I wouldn't want to encourage people to say "I'm going to prefer the Makefile.PL over the Build.PL."
For more discussion, you can read Schwern's rant on the matter or a Perlmonks thread on the matter (and one where Schwern loses his temper and uses very work unfriendly language. Frankly, I understand where he's coming from).
Re:And the winner is ...
jk2addict on 2006-08-24T01:49:29
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 rather spend time coding that working through M::B conversion issues, I'll always stick to EU::MM. For people not hacking it...it [still] just works. In time, that may change, by it isn't there yet, despite the prescribes by it's author to kill it.Re:And the winner is ...
Matts on 2006-08-24T02:42:34
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 to hack on EU::MM.
Having said that, I think the concept of M::B is right - in hindsight EU::MM should never have existed. But it's there, it works fine on all the platforms I'd ever want any of my modules to work on, and I've never really found it lacking.Re:And the winner is ...
Aristotle on 2006-08-24T11:53:49
Personally, I use M::B, and just throw in
create_makefile_pl => 'traditional'in theBuild.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 theMakefile.PL.Best of all worlds, if you ask me.
Re:And the winner is ...
chromatic on 2006-08-24T18:54:02
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 start to wonder how to do it, my brain starts to scream and just won't shut up until I think about something else for a while.
Re:And the winner is ...
Matts on 2006-08-24T19:06:39
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.Re:And the winner is ...
chromatic on 2006-08-24T19:57:10
Let me be very concrete then. When writing the build process for
Embed::Parrot, I wanted to useparrotto compile a PIR file into PBC. I want to do this as part of the build process before the test process, so I overrodeACTION_buildin Build.PL. I assume, from writing other makefiles, that adding to thetesttarget 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.
Re:And the winner is ...
jdavidb on 2006-08-24T15:41:40
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.
:) Re:And the winner is ...
jdavidb on 2006-08-24T19:14:55
My response is confusing because when I said "installer," I meant, "installing admin," not "installing program."
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 case it is the Build.PL that should be preferred. There is no tool which casually autogenerates a Build.PL from Makefile.PL, but there is one which works the other way around, and I’m quite sure that noone maintains both files manually.
This option should default to one of the choices, and it’s obvious which one that should be.
Re:This shouldn't even need configuring
jdavidb on 2006-08-24T15:45:55
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. It's not that much more work to type "look Module; perl Makefile.PL
..." Re:This shouldn't even need configuring
Aristotle on 2006-08-24T17:31:04
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.
Re:This shouldn't even need configuring
jdavidb on 2006-08-24T19:15:24
BTW, I just went through this again on another box, and noted that it defaults to EUMM rather than MB.
