On Jul 9, 2008, at 14:25, Eric Wilhelm wrote:
But alas, like Test::Harness, we have perpetuated a culture of
assuming
that your @INC always magically appears in the child process --
including in M::B's own code. That might be unsurprising most of the
time, but it does make a certain class of
# from David E. Wheeler
# on Wednesday 09 July 2008 11:58:
>Uh, but DistGen does generate this test:
>
> use Test::More tests => 1;
> use strict;
>
> use $self->{name};
> ok 1;
Well, I wasn't talking about DistGen and the tests within the tests --
just about the tests.
I was loo
On Jul 9, 2008, at 11:49, David E. Wheeler wrote:
You were not running './Build test --use-tap-harness' for
Module::Build
because I am still sitting on the make-that-an--option code.
The test I wrote uses it, though (as a boolean), and it runs tests.
Oh! The tests run by the tests have no
On Jul 9, 2008, at 11:43, Eric Wilhelm wrote:
Makes sense to me. Though it did work fine the way I had it. I wonder
why it wasn't a problem?
You were not running './Build test --use-tap-harness' for
Module::Build
because I am still sitting on the make-that-an--option code.
The test I wr
# from David E. Wheeler
# on Wednesday 09 July 2008 11:35:
>> TAP::Harness doesn't force the caller's @INC into subprocesses the
>> way Test::Harness did, so it needs to be explicitly passed as 'libs
>> => [EMAIL PROTECTED]' -- though we might want to clean that up a bit to have
>> e.g. only 'blib
On Jul 9, 2008, at 10:15, Eric Wilhelm wrote:
TAP::Harness doesn't force the caller's @INC into subprocesses the way
Test::Harness did, so it needs to be explicitly passed as 'libs =>
[EMAIL PROTECTED]' -- though we might want to clean that up a bit to have e.g.
only 'blib/lib'?.
Makes sense t
# from David E. Wheeler
# on Wednesday 09 July 2008 09:51:
>> (For some value of 'work' -- that's a major wreck right now for
>> Module::Build's tests -- some assumption about blib/lib is wrong?)
>
>Um, what?
TAP::Harness doesn't force the caller's @INC into subprocesses the way
Test::Harness di
