Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much

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]
[Corion]: Hi Lady_Aleena!
[Lady_Aleena]: marioroy, are you also writing a Meditation for this?
choroba o/
Discipulus adds tozzetti alle mandorle to the platter on the sideboard.
Lady_Aleena was checking #cbstream and saw the big announcement.
[marioroy]: Tie::IxHash can be shared. Also similar modules. I cannot wait to post a solution sharing Tie::File and iterating among workers.
[marioroy]: Lady_Aleena Yes, will post something with all the new features. Parallel with few lines of code.
[marioroy]: Yes, will do for PM. I love PM.
Lady_Aleena ponders a meditation of her own, but it would be on a far far less important topic.
[marioroy]: I'm hoping to have a release in about a week's time.

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (5)
As of 2017-05-26 08:54 GMT
Find Nodes?
    Voting Booth?