Front page | perl.qa |
Postings from March 2005
From: Michael G Schwern
March 28, 2005 16:47
Message ID: 20050329004722.GC14928@windhund.schwern.org
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
> 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