in reply to Re: Re: Makefile.PL even weirder on Windows
in thread Makefile.PL even weirder on Windows

I don't know about the number part, but MakeMaker (or whatever in the backend) globs t/*.t for test files, and runs them. Generally you wanna name these, and putting numbers don't hurt (it's like a convention).

Remember when I say above I added use lib 't'; like to the test file (i do)? You don't do it in the makefile, you do it in your test file.

MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
** The Third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: Re: Re: Makefile.PL even weirder on Windows
by John M. Dlugosz (Monsignor) on Jan 13, 2003 at 18:11 UTC
    That makes the test file sensitive to what directory its run from. Checking the current script's directory and appending a 't' would work, but is more work. Sometimes I wish the @INC paths had "same directory as the main script" option!
[reply]
      Sometimes I wish the @INC paths had "same directory as the main script" option!

      I think I've done something like this before. The following is untested:

      BEGIN {
  use File::Basename;
  my $dir = dirname(__FILE__);
  unshift @INC, $dir;
  require MyModule;
}

      [download]
      If your module has functions, you can just use the whole package/function name to refer to them in your test, e.g. MyModule::function(@args), or explicitly call MyModule->import after the require. This way, I can run the tests from any directory, even from outside of the whole build directory.
[reply]
[d/l]
[select]
        I thought about that before writing the code, but since I'm specifically testing the use statement itself, I didn't want to "fake it" or alter it in any way. That's why I have separate files at all instead of just putting them into the test script.

        Good point about using __FILE__. I kind of forgot about that, but use $0.

        —John

[reply]
[d/l]
      That makes the test file sensitive to what directory its run from.

      True, but I don't find this a huge problem myself.

      I tend to run tests using make test, so ExtUtils::MakeMaker figures it out for me.

      If I want to run individual tests from the command line it's easy to add the path in with -I, or use a tool like Test::Verbose (which looks like it needs patching for Win32 - so probably not a lot of use for you :-).

[reply]
[d/l]
[select]
        My test file, now named t/test.t, by default prints the "ok" lines (only) for the benifit of Test::Harness. But I can run it with the -verbose switch to get trace statements and dumps of structures so I can see what's happening, or with -quiet which just gives me a one line "all tests passed" (or the fail statements). So when developing, I run t/perl test.t -verbose. Turns out the makefile runs Test::Harness from the same directory (that contains the makefile) anyway, or maybe it's whatever the current directory was without changing anything specifically. So my quick and dirty solution is to add 't' to the @INC if it exists, and if not it assumes its being run from its own directory. Hmm, will perl complain about things in @INC that don't really exist? Maybe I could skip the conditional.

        I seem to remember a module that gets the script's directory, for just such a purpose. Maybe I'll find that.

        —John

[reply]
[d/l]

In Section Seekers of Perl Wisdom