Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

Re^12: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?

by ELISHEVA (Prior)
on Feb 18, 2011 at 15:58 UTC ( #888935=note: print w/replies, xml ) Need Help??

in reply to Re^11: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?
in thread Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?

I had been already to break out the Champagne when I cleaned out everything and rebuilt from scratch. Once again, even with all the tests in tests rather than t, I saw the same behavior. runs fine when it runs directly on the command line perl ./ TAP gets swallowed when is executed by make test.

Clearly whatever is causing this on-again off-again TAP swallowing is not merely about the name of the test directory. In fact it seems to have nothing to do with it. You can get make test to work with the files in t or in test. The only factor that seems to make a difference is the "test" key:

# this creates a broken Makefile WriteMakefile ( 'INSTALLDIRS' => 'site', , 'NAME' => MyModule::Foo , 'VERSION' => 0.999_003 , 'PREREQ_PM' => { 'Fiddle::Faddle' => 0 } , 'test' => { TESTS => '' } ); # this does not (test key removed) WriteMakefile ( 'INSTALLDIRS' => 'site', , 'NAME' => MyModule::Foo , 'VERSION' => 0.999_003 , 'PREREQ_PM' => { 'Fiddle::Faddle' => 0 } );

I'm not going to be entirely comfortable until I understand why this makes a difference. Just as yours and my empirical observations about t vs. tests turned out to be unlikely, so too could my empirical observations about the 'test' key.

It does however look like we are well on our way, without having to reinvent the wheel.

As for "you could have asked" :-).... don't underestimate your role in causing me to revisit an option I'd rejected. By believing it could be done and even offering to look at a reduced code sample, you convinced me that I might have given up too quickly. You all but invited me to ask for help - and you are correct that I did not explicitly do so - it isn't easy for me - I tend to believe I have to take care of myself at all times. However, had you not issued that quasi-invitation, I would not have told you the story of why I gave up and perhaps you would not have offered evidence that my original intent to call runtests could work if things outside my code were set up properly.

Thanks again for your help. You do honor to the name "Anonymous Monk".

Replies are listed 'Best First'.
Re^13: Do Pure Perl CPAN packages really need to use ExtUtils::Command::MM?
by Anonymous Monk on Feb 19, 2011 at 08:07 UTC
    I asked for a patch before; here is how I work it
    module-starter --eumm --module=TestPL --author=name --email=emai +l cd TestPL wget perl Makefile.PL && nmake test
    This does the unwanted
    C:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, ' +blib\lib', 'blib\arch')" t/*.t C:\perl\bin\perl.exe "-Iblib\lib" "-Iblib\arch"
    which is why you rename t to tests, so that only gets run.

    If you add test  => { TESTS => '' }, you get No plan found in TAP output, which is not surprising, since runs its own harness, so there is nothing for the other harness to consume.

    You don't want to run through a harness, is the harness.

    Do you see what I see?

      Well, that patch appears to have been made to the EVO module's - there is now a warning not to set test => {TESTS => ...}. Thank-you.

      Sadly, it turns out that this solution isn't going to pass muster. The combination of + tests in "test" rather than "t" + no TESTS => '' works under "make test", but it borks "./Build test". "./Build test" doesn't appear to be smart enough to give the file special treatment and it runs it through run_tests, resulting in the same problems with TAP that I was seeing earlier under MM: it goes to the console but not to Build.

      I haven't given up experimenting with ways to get M:B to run as a harness rather than a test, but so far I haven't found a solution. Any ideas?

      Re: what do I see.

      With regard to t/*.t files, I see the same thing you do. I suspect that the t/ wasn't causing me a problem in my actual project directory because make/ExtUtils appears to only consider the immediate children of "t/". I name my tests after the class they are testing so all my tests are 2 or more levels deep.

      If I set TESTS => '', make/MM can't seem to find the TAP output though it is clearly displayed on the console (tested by inserting a fail() and diag()). However, the message I get is different from you. If only successful tests are run, I get "one test script could be run - FAILED before any test output arrived. FAILED alas no output ever seen." If I insert a fail(), the message is just the first and last sentence: "one test script could be run - FAILED alas no output ever seen."

        Any ideas?

        Try the respective mailing lists

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://888935]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (5)
As of 2017-12-15 17:15 GMT
Find Nodes?
    Voting Booth?
    What programming language do you hate the most?

    Results (439 votes). Check out past polls.