develooper Front page | perl.qa | Postings from March 2005

Re: Test::META

From:
Yitzchak Scott-Thoennes
Date:
March 28, 2005 19:00
Subject:
Re: Test::META
Message ID:
20050329025959.GA10344@efn.org
On Mon, Mar 28, 2005 at 03:10:52PM -0800, Michael G Schwern wrote:
> On Mon, Mar 28, 2005 at 08:42:50AM -0500, Christopher H. Laco wrote:
> > That's another gripe of mine about M::B and create_makefile_pl.
> > It puts the requires AND build_requires in the PREREQ_PM in the 
> > Makefile.PL, which I won't want; nor do I think it right for everyone.
> 
> There is no build_requires or recommends equivalent in MakeMaker, nor will 
> there be,

Too bad.  Seems to me it would make sense to have MakeMaker support
adding the tags to META.yml.  Don't see what other MakeMaker change
would be needed.  Maybe that presupposes something else that I see as
very desirable: META.yml being (re)generated by Makefile.PL at build
time, and CPAN* looking in META.yml instead of Makefile for prereqs.

> so putting it into PREREQ_PM is the best thing to do.  That's
> what every MakeMaker-based module on CPAN does after all.
> 
> Its better than just dropping it and having the build fail.
> 
> 
> > Take Test::More for example. It's usually a build_requires and the other 
> > Test* things like Test::Strict, Apache::Test, etc are in recommends. 
> > Test probably won't run with Test::More, but skipping a few subtests 
> > based on recommends is ok. But I don't think build_requires should be a 
> > PREREQ_PM requirement at all.
> 
> *scratch head* but if you don't have the modules necessary to BUILD the
> module (as opposed to those necessary to run it)... how are you going to 
> build it?

The distinction between PREREQ_PM and build_requires only becomes
meaningful for binary (that is to say, pre-built) distributions.  Such
distributions should be able to rely on PREREQ_PM to indicate what
other (binary) distributions are required.

Whether things that are required for *testing* belong in
build_requires really depends on whether you view testing as an
integral part of the build process.  This is something that is likely
to depend on the *builder*, not the module author, which is, in my
mind, the only argument (and a good one) for a separate test_requires.
The distinction between build_recommends and and a possible
test_recommends is more ambiguous.



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About