On Mon, Mar 28, 2005 at 06:20:32PM -0500, Christopher H. Laco wrote: > >Its better than just dropping it and having the build fail. > > That's a matter of opinion; one I think should be left up to the person > makeing Build.PL.
That sort of dubious flexibility is well out of the scope of Module::Build::Compat, a module intended to cover the most common conversion scenarios. > build_requires is a bad place for test requirements, but recommends > isn't right either. You're right, there probably should be test_requires and test_recommends. I belive the argument at the time when these things were being layed out was "the tests are part of the build stage, you should always run the tests when you build". This appears to be wearing thin. Until such time as there are test_* flags, one should take a pragmatic view. And that view is "what is going to cause the least amount of hassle for those who want to install my module" because they don't know nor care about the internal mechanics. So you put the test requirements into build_requires and the test recommendations into recommends because those are the closest equivalents. And then you submit a patch to Module::Build to add test_requires and test_recommends. :) Looking at how create_makefile_pl works and given the lack of resolution in MakeMaker's dependency system, the obvious thing to do is to glom all the *required* Module::Build dependencies (and if there was a test_requires, that too) into PREREQ_PM so the module builds, tests and installs because nearly every Perl module build tool... A) resolves the dependencies B) builds the module C) runs the tests So Module::Build::Compat is doing the right thing. If you desire to break automated installation of your modules over an internal bit of semantics, well, I don't expect the Module::Build::Compat folks to bend over backwards to support you. You might have to write your own converter.
