Skip Menu |

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the CPAN-Reporter CPAN distribution.

Report information
The Basics
Id: 92123
Status: rejected
Priority: 0/
Queue: CPAN-Reporter

People
Owner: Nobody in particular
Requestors: pause [...] tlinx.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: cpan-reporter doesn't load TEST_REQUIRES before running tests
I have a TEST_REQUIRES section in my Makefile.PL. Unfortunately, I am getting a fail from cpantesters viewable at: http://www.cpantesters.org/cpan/report/8ef926b5-6c04-1014-ace8-5c489752f052 The distribution is for Xporter-0.10.0. --- The Makefile.PL is below: ---- use ExtUtils::MakeMaker; # See lib/ExtUtils/MakeMaker.pm for details of how to influence # the contents of the Makefile that is written. WriteMakefile( NAME => 'Xporter', VERSION_FROM => 'lib/Xporter.pm', AUTHOR => 'LA Walsh (LAWALSH@cpan.org)', ABSTRACT => "Alt. exporter w/persistent, dflts & auto ISA", BUILD_REQUIRES=> { 'ExtUtils::MakeMaker' => '6.82', }, TEST_REQUIRES => => { 'Test::Simple' => '0.44', mem => '0.4.5' }, dist => { TAR=> 'tar', TARFLAGS=> "-H v7 -h -cf " }, ); --------------------- Neither 'Test::Simple' nor 'mem' show up as "required" for testing so the test runs with a FAIL status. It seems a report should not be sent if the REQUIRES are not met (such is true for PM/BUILD REQs)... Is it an oversight that TEST_REQs isn't checked as well? Thanks!
Hi, Linda. CPAN::Reporter relies on CPAN.pm to determine the list of prerequisites. CPAN.pm relies on information provided by Makefile.PL. TEST_REQUIRES is a relatively new field and is only supported by recent versions of ExtUtils::MakeMaker. You need to make sure that the configure_requires field in META.yml (and the prereqs/configure/requires field in META.json) list a new-enough version of ExtUtils::MakeMaker that supports that field. Right now, you have "0" as the configure/requires version of ExtUtils::MakeMaker. Alternatively, you need to have Makefile.PL copy TEST_REQUIRES into PREREQ_PM on older versions. I'm going to close this ticket as it is not something that CPAN::Reporter can fix. Regards, David Golden
On Tue Jan 14 07:17:25 2014, DAGOLDEN wrote: Show quoted text
> TEST_REQUIRES is a relatively new field and is only supported by > recent versions of ExtUtils::MakeMaker. > > You need to make sure that the configure_requires field in META.yml > (and the prereqs/configure/requires field in META.json) list a new- > enough version of ExtUtils::MakeMaker that supports that field. Right > now, you have "0" as the configure/requires version of > ExtUtils::MakeMaker.
----- I noted it was a new param in trying to fix another problem and made sure that ExtUtils::MM was in the BUILD_REQUIRES field so that it would be new enough to recognize the TEST field. And the error report does say that ExtUtils:MM was 6.86 (I only had a need for 6.82 in my tests). I'm not sure where configure comes into building a module, -- usually there is build, test & install. Install might be considered 'configure', but test comes before install and is often considered part of deciding whether or not the build was successful. Show quoted text
> I'm going to close this ticket as it is not something that CPAN::Reporter can fix.
---- I understand CPAN::Reporter relies on CPAN -- and an up-to-date ExtUtils:MM. But for figuring out why this happened(happens?), "shouldn't" the build-req take care of making sure ExtUtils was sufficiently new (not to mention, the version of ExtUtils used was newere than the Buildreqs). It seems there is something missing -- since the same version of Xporter built successfully in 9 other instances of win32/non-cygwin in perls from 5.10.x -> 5.18.x. From everything you've said, the version of Extutils should have been the only thing necessary to process the TEST_REQs, and from the report, it was sufficient as well? Any ideas? Linda Walsh
The "configure" step means running "Makefile.PL" or "Build.PL". CPAN clients look at META.yml or META.json for any prerequisites for that step. If they find them, they install them. Then Makefile.PL is run. Only then are the normal set of prerequisites available for inspection. Hope that helps, David
On Tue Jan 14 17:15:43 2014, DAGOLDEN wrote: Show quoted text
> The "configure" step means running "Makefile.PL" or "Build.PL".
---- But running Makefile.PL isn't where it failed. It ran that, since it picked up the the "build_requires" (listed in the report): build_requires: Module Need Have ------------------- ---- ---- ExtUtils::MakeMaker 6.82 6.86 configure_requires: Module Need Have ------------------- ---- ---- ExtUtils::MakeMaker 0 6.86 It failed in the subsequent 'dmake' test that ran out of a "Makefile" generated by "Makefile.PL". I.e. It appears we are already past the "config" case, as it ran Makefile.PL and found the build_requires. It seems a bit circular: if I put CONFIGURE_REQUIRES for EU::MM, then running perl Makefile.PL, will copy the config info necessary for running Makefile.PL into the META files? (FWIW, I've always relied on EUMM creating/writing the Meta files from what is in Makefile.PL -- as the documentation said the META files would be created from the Makefile.PL). Show quoted text
> > CPAN clients look at META.yml or META.json for any prerequisites for > that step. If they find them, they install them. > > Then Makefile.PL is run. Only then are the normal set of > prerequisites available for inspection.
--- The manpage for EUMM claims the config step: make config # to check if make config # to check if the Makefile is up-to-date the Makefile is up-to-date And the general flow is: Default Makefile Behaviour The generated Makefile enables the user of the extension to invoke [1] perl Makefile.PL # optionally "perl Makefile.PL verbose" [2] make [3] make test # optionally set TEST_VERBOSE=1 [4] make install # See below ---- In the above, steps 1+2 are done. with CONFIGURE_REQUIRES stating preconditions for [1], and BUILD_REQUIRES stating preconditions for [2]. Looking at the MM pod/man, it lists no minimum version for TEST_REQ, but it lists min vers of 6.52 for CONFIG and 6.5503 for BUILD. Regardless -- I can't see how the test client would have 6.86 and have it NOT process the TEST_REQ. anyway--- thanks for the hints... this seems alot more complicated than it should be, but I'm sure the flexibility is useful given all the places perl builds...