Re: Re: Re: Module::Build and the PPM

[Corion]

I recently moved one of my modules over to Module::Build because I don't like make and all the things it entails, and ExtUtils::MakeMaker turned me off due to its complexity and uglyness for expansion.

The first thing that really annoyed me was, that there was no pass-through Makefile.PL included and that I had to hunt down one of your distributions to find a Makefile.PL so that the make && make test && make install dance still works. I don't like make, but it is a very convenient way to unify my automated nightly testing scripts. For something that claims to be the next best thing, this was a bad decision.

Recently, I've gone to writing some meta-packages that automate the installation of other modules, and while battling it out with ExtUtils::MakeMaker, I found it actually not that convoluted and ugly, as long as it is about generating one-shot makefiles and not some ingenious framework to do it all.

I think that the lack of Win32 feedback mostly stems from people shortly evaluating Module::Build under Win32 and then deciding that it's not worth the bother. If you want acceptance, you will have to actively seek out the people there, and not supporting a proper, automatic CPAN installation will not make people like Module::Build, at least, it made me not like it.

[autarch]

The first thing that really annoyed me was, that there was no pass-through Makefile.PL included and that I had to hunt down one of your distributions to find a Makefile.PL so that the make && make test && make install dance still works. I don't like make, but it is a very convenient way to unify my automated nightly testing scripts. For something that claims to be the next best thing, this was a bad decision.

Module::Build has come with Module::Build::Compat for quite some time. Just do this:

Module::Build->new( module_name => ...,
                    create_makefile_pl => 'passthrough',
                  )->create_build_script;

There are other options that can be passed to "create_makefile_pl". See Module::Build::Compat for details.

The nice bit about this is that Module::Build will simply re-generate the Makefile.PL each time you run "./Build dist". So if Module::Build improves compatibility, you just install the new improved version and next time you create a distro tarball, you get the improved version of the Makefile.PL script automatically.

[tilly]

It comes with that option, but does the option work well?

If you write that as your Makefile.PL and then run it, you'll get error messages. Why? Because you don't have some of the files that passthrough says you require built yet.

If you're like me, you look at it and think that you need Module::Build::Compat to be loaded and run to crate them. So I did that. And got rid of all errors. Then built my tarball.

If you avoid errors by doing that under Linux, you'll actually wind up with an uninstallable tarball. Why? Because certain things have just been loaded by force, and are not overwriteable. What you need to do is have the passthrough, and ignore errors. When you build the tarball, the missing files will be built for you, but not until. (This was the case a few months ago. I don't know if it is now.)

I discovered this only after uploading to CPAN and having a CPAN tester complain about the uninstallable file. I didn't bother reporting the bug after I fixed it because the response the first time that I reported a bug dissuaded me from caring.

Perhaps this is better now. Perhaps not. As I mentioned, I didn't report it so I don't know. Besides, I explained to the CPAN tester what happened, I wasn't the first person that he saw make the mistake, and if that tester continued testing, then any other people making that mistake at least had a good explanation hand-delivered...

The fact that I didn't report it and I don't know whether it is fixed should be a red flag. Something is wrong with how they're dealing with the community. People in the community who're trying to communicate should not consistently become pissed off with the process. Once or twice, it is just some bad apples. If problems are consistent, at some point you really need to stop making excuses and say, "Why am I not being seen like I want to be seen?"

I submit that Module::Build has hit that point and should ask that question.

[adrianh]

It comes with that option, but does the option work well?

It does work well in my experience. I assume that the bug you mentioned has now been fixed.

The fact that I didn't report it and I don't know whether it is fixed should be a red flag. Something is wrong with how they're dealing with the community. People in the community who're trying to communicate should not consistently become pissed off with the process. Once or twice, it is just some bad apples. If problems are consistent, at some point you really need to stop making excuses and say, "Why am I not being seen like I want to be seen?"

From what I have seen on the M::B list bug reports are fixed quickly and patches are accepted. Evidently a few people's experiences have been different which is sad.

Personally I don't think Ken's response to your initial report was as harsh as you seem to think it was - but YMMV. Ken's also recently said that he'll be removing his expressed personal preference from the docs.

Personally I'd say giving M::B another chance. I've seen no signs of any arrogance on the list myself, only people trying hard to come up with a useful alternative to EU::MM.

[Corion]

Why is this option not simply the default then?

That way, Module::Build could have transparently replaced ExtUtils::MakeMaker without any other interference.

For something that wants to replace an existing module, I find the lack of migration paths a major deficiency. And since I found that Module::Build doesn't scratch the itches I have with ExtUtils::MakeMaker, I'm not likely to move the rest of my modules over to it.

[autarch]

Why is this option not simply the default then?

I can't say for sure, but I'm guessing because Ken wants people to think about how they want to do this. The passthrough option seems to work reasonably well, but it is doing pretty funky stuff under the hood. The other methods that use a Makefile.PL also have their drawbacks, so it's really up to each developer to decide how they want to handle this.

For something that wants to replace an existing module, I find the lack of migration paths a major deficiency.

Somebody else has created a Makefile.PL => Build.PL converter tat works for simple Makefile.PL scripts. If you're doing something complex in your Makefile.PL, there's obviously no way to automate the conversion.