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

Another quick question:

Moving the stuff to a t subdirectory, "nmake test" tells me that M1 etc. are not found. Apparently it does not chdir to the t directory before running the tests. How do I say in the Makefile.PL that the modules needed for the test scripts are also in that directory?

Also, what is the significance of the name 00-basic ?

—John

  • Comment on Re: Re: Makefile.PL even weirder on Windows

Replies are listed 'Best First'.
Re^3: Makefile.PL even weirder on Windows
by adrianh (Chancellor) on Jan 13, 2003 at 09:49 UTC

    Moving the stuff to a t subdirectory, "nmake test" tells me that M1 etc. are not found. Apparently it does not chdir to the t directory before running the tests. How do I say in the Makefile.PL that the modules needed for the test scripts are also in that directory?

    There isn't a way of doing this in the Makefile.PL that I am aware of. (Or, to be more accurate, no standard way. You can always write some custom code.)

    People normally add the directory to @INC in the appropriate *.t files.

    Also, what is the significance of the name 00-basic

    Adding a number prefix is one way to define the order test scripts are run in.

    Test are run in filename order. Some people like to have their test scripts run in a certain order. For example, you might test some basic stuff in the first script run and then bail out of the test suite if it fails - saving time when something goes wrong.

      I assume that the 1..m line applies to each file, not the whole set? The docs seem to imply the latter, but that makes things more difficult.

      Is the glob operator defined to return a list sorted by name? Ah yes, it's documented in File::Glob.

      —John

        I assume that the 1..m line applies to each file, not the whole set?

        Yup. It defines the number of expected tests for an individual test script.

        The docs seem to imply the latter, but that makes things more difficult.

        What does it make more difficult?

Re: Re: Re: Makefile.PL even weirder on Windows
by PodMaster (Abbot) on Jan 13, 2003 at 05:08 UTC
    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.

      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!
        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; }
        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.
        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 :-).