On Tuesday, September 3, 2002, at 08:56 AM, Michael G Schwern wrote:
> On Mon, Sep 02, 2002 at 08:13:06AM +0100, Nick Ing-Simmons wrote: >> I understand all that. My point was that while test itself may care >> where it is run, blib.pm does not mind as much. Also blib.pm's job >> is to make running an un-installed module "easy" which is what you >> want to do for a pre-install test. So if there is boiler-plate stuff >> to do blib.pm is an appropriate place to do it. >> >> Thus is you need to be in t this might suit >> >> cd t; perl -Mblib=lib foo/bar.t I'd be happier if that 'cd t;' happened inside blib.pm as 'chdir "t"'. I'd be happier still if tests didn't run from t/, since that's not how most CPAN modules work. > There's a chicken/egg problem here. blib.pm is going to find the lib/ > directory so we can load uninstalled modules. So... how do you find > blib.pm? This doesn't seem like a real problem. The test suite can find it because it knows where it's being run from. It can set up @INC however it wants, to make sure blib.pm is found. Then blib.pm sets things up for the rest of the tests. > Other problems include that we can't assume blib.pm works. > Don't want the > whole basic test suite falling apart because of a module failure. For core perl, we can indeed assume blib.pm works. If it doesn't, we want to know about it right away. > Finally, since you have to run from t/ anyway, blib.pm is > overkill. This > works just as well: > > cd t; ./perl -I../lib foo/bar.t I have to wonder why it's preferable to put code on command lines rather than in modules. > While the result is still ugly, it means we can expand and alter the > requirements for running a core test. For example, the PERL_CORE > environment variable should be set (t/TestInit.pm currently > doesn't). So > the full command is really something like this: > > cd t; > PERL_CORE=1 ./perl -I../lib path/to/test.t > > Which could be reduced somewhat to: > > ./perl -It -MTestInit t/path/to/test.t That's reasonable to me. I don't really care whether the code goes in TestInit.pm or blib.pm, but a disadvantage of blib.pm is that it's got a rather closed command-line interface, all you can do is specify a directory to treat as a blib/ . Really, it would be nice if you could tell the module about certain situations, like -MTestInit=core or whatever, and that would do whatever's necessary for a core test run (including chdir, @INC adjustments, etc.). Heck: with a smart enough TestInit, it could even adjust @ARGV so that you could specify all *.t paths in Unix format, if that would be helpful. > and perhaps reduced a little further by moving/linking > TestInit.pm into the > top level directory. > > ./perl -MTestInit t/path/to/test.t > > but that will cause trouble when running tests with -T (because . is no > longer in the path). '.' won't necessarily be in the path anyway. -Ken
