Michael G Schwern <[EMAIL PROTECTED]> writes: >On Fri, Aug 30, 2002 at 11:57:16AM +0100, Nick Ing-Simmons wrote: >> Michael G Schwern <[EMAIL PROTECTED]> writes: >> >On Fri, Aug 30, 2002 at 05:54:15PM +1000, Ken Williams wrote: >> >> Oh, one big lib/, not several different ones? So then why can't it be >> >> run with >> >> >> >> perl -Mblib=lib t/foo/bar.t >> >> >> >> ? >> >> blib was invented to allow just such usage. >> >> > >> >Because tests all try to run from t/. That's what the chdir 't' is for. >> >t/TEST does this for you and so do the tests themselves which makes it much >> >more forgiving. Otherwise it would be very picky and this: >> >> If you look at it you will see it tries to hunt down the right things >> allowing for fact you may have chdir'ed into t (or even deeper). > >It's not just getting @INC right. The tests must be run from t/ (ie. a >canonical directory they're always run from) so that they can find certain >files properly and so that they only scribble scratch files inside t/. > >For example, lib/Test/Simple/t/exit.t has to find some sample programs to >test against in t/lib/Test/Simple/sample_tests. How can it find it if it >doesn't know where it was run from? You have to get into things like >looking at $0 and trying to walk your way up to the top level source >directory. Icky. > >The existing t/TestInit.pm takes this into account by simply chdir'ing to >t/.
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 would work, and I would be more than happy it it looked for a t directory as well. -- Nick Ing-Simmons http://www.ni-s.u-net.com/
