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

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

by Anonymous Monk
on Feb 18, 2011 at 11:09 UTC ( [id://888881]=note: print w/replies, xml ) Need Help??


in reply to Re^10: 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?

...Doing it isn't the hard part. Spending my free time all but reinventing the wheel when

Or you could have asked how to do it, instead of trawling (fishing) for "concrete reasons" ... :)

See another example http://search.cpan.org/~evo/Class-MakeMethods-1.01/test.pl, the magic part is naming it "tests/*t" instead of "t/*t", works like a charm, there is no TAP swallowing or anything :)

Replies are listed 'Best First'.
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

    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. test.pl runs fine when it runs directly on the command line perl ./test.pl. TAP gets swallowed when test.pl 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 => 'test.pl' } ); # 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 test.pl code were set up properly.

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

      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 http://cpansearch.perl.org/src/EVO/Class-MakeMethods-1.01/test.pl 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" test.pl
      which is why you rename t to tests, so that only test.pl gets run.

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

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

      Do you see what I see?

        Well, that patch appears to have been made to the EVO module's test.pl - 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 test.pl + tests in "test" rather than "t" + no TESTS => 'test.pl' works under "make test", but it borks "./Build test". "./Build test" doesn't appear to be smart enough to give the test.pl 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 test.pl 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 => 'test.pl', 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."

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://888881]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others examining the Monastery: (8)
As of 2024-03-28 15:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found