> On Sat, Jan 05, 2002 at 10:17:34PM +0100, Mattia Barbon wrote:
> > > On Wed, Jan 02, 2002 at 05:37:28PM +0100, Mattia Barbon wrote:
> > > > I don't care for the variable name, but I'd really like
> > > > to have this feature.
> > >
> > > Would it work ok as a Test::Builder accessor method rather than an
> > > environment variable?
> > No, unfortunately, because the call order is like this:
> > * init code in the backend
> > * BEGIN blocks of the program ( including use Foo; )
> > * B::Backend::compile
> > * the coderef returned by B::Backend::compile
> >
> > So I can't call the method from the init code in the backend,
> > because Test::Builder hasn't been loaded yet, and calling it from
> > the ::compile is too late ( output is already lost ); the
> > alternative I see is to use a package variable; so I can set
> > $Test::Builder::i_want_the_output_even_if_dollar_caret_C_is_1 = 1;
> > in initialization code.
>
> You could do this:
>
> require Test::Builder;
> my $tb = Test::Builder->new;
> $tb->output_even_if_compiling(1);
>
> in the init code. Since Test::Builder is a singleton your settings
> should stick.
Yes, but then B::C sees the Test::Builder stashes and saves them,
for every compiled program. I might enable yhat based on some
option/environment variable, but this just shifts the problem.
> Here's an interesting alternative. Do C<local $^C = 0> just before
> running the tests, though that's pretty ugly.
>
>
> > But I rwally like the environment variable better, because with the
> > package variable solution I need to set it unconditionally ( because
> > for it to have effect it must be set in the init code, and in the
> > init code I can't look at parameters, because parameters are passed
> > in the call to compile, so I can't set it using a parameter ), and
> > because I was hoping to keep B::C clear from
> > hacks-to-make-the-testsuite-happy.
>
> >From my PoV, I'm hoping to keep Test::Builder clear from
> hacks-to-make-perlcc-happy. :) The $^C thing is already a hack for
I knew you was going to say that :)
> B::Deparse.
>
> Could you explain again why you need test output while compiling, I'm
> not quite following. Assume you had the I_WANT_OUTPUT_DURING_COMPILE
> environment variable could you show how you'd be using it?
Let's say I have this lib/Bar/t/bar.t ( not usint Test::* )
----
#!perl
BEGIN { print "1..2\n" };
BEGIN { print "ok 1" };
print "ok 2\n";
----
This prints "1..2\nok 1\n" at compile time, and "ok 2\n"; at run
time. When compiled with "perlcc --testsuite bar.t", perlcc saves
the compile-time output, and passes to B::C the
-e"print qq{1..2\nok 1\n}" option ( -efoo means "eval foo just before
you run the program" ); so the compiled program prints
1..2
ok 1
ok 2
and t/TEST is happy
However lib/Foo/t/foo.t uses Test::Simple
----
#!perl
use Test::Simple tests => 2;
BEGIN { use_ok('Foo') }
ok( foo(1), "foo(1) is true" );
----
So when compiled with B::C, $^C is set, and it does
not print the "1..2\nok 1\n" at all, so perlcc does not see it,
does not pass anything to B::C, so the compiled
program prints just "ok 2" and t/TEST is very unhappy.
The I_WANT_BEGIN_OUT ( or whatever ) works around that.
Hope it is clearer now.
I could modify t/TEST, but I wanted to modify it as few as possible, and there really
is no ( portable ) way to distinguish between a test
that fails in the middle for some reason ( say it segfaults at test 7 ) and one that
has just planned 6 tests.
Regards
Mattia
