On Tuesday, September 3, 2002, at 03:10 PM, Michael G Schwern wrote:
> On Tue, Sep 03, 2002 at 11:26:01AM +1000, Ken Williams wrote: >>>> 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"'. > > It already happens inside TestInit. Cool. > [...] > So they can't run from the top level directory, and at that > point you're > already different than CPAN. A pity - it means that if they write files, etc. (which is presumably the only case where this consideration matters) they have to do it differently in the core vs. regular CPAN if they want the effect to be the same. Just another obstacle to having things lead dual lives. >>> 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. > > I thought the whole idea was to run blib.pm to set @INC. If > the test suite > is setting up @INC we don't need blib. blib.pm only adds to @INC. Seems like the core requires something to strip @INC down to a small set, not add to it. So blib.pm as it currently works isn't really the right tool I guess. Nick was suggesting blib.pm could be changed, but it sounds like you'd rather create a different TestInit tool. Anyway, what I meant was that @INC needs to be one value to find blib.pm, and then blib.pm changes @INC to be another value, so there's no chicken/egg problem. > And if we're not using blib to setup > @INC there's no point in shoving extra functionality unrelated > to finding > modules into it. Even more importantly, there may not be room in the blib.pm interface for other stuff. >> I have to wonder why it's preferable to put code on command >> lines rather than in modules. > > As mentioned below, it's not. That's why it's already in > TestInit.pm (are > you sensing a theme here?) I was just spelling out the > equivalent command to show blib wasn't buying us anything. Ah, I see. >>> 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. > > Sorry, I ment perl's @INC. That's what I meant too. People can build Perl without '.' in @INC, right? -Ken
