Re: TAPx::Harness support for EUMM
On 30 Jan 2007, at 02:24, Michael G Schwern wrote: That's one way, though I'd rather it be a Makefile.PL argument. [1] Yup, OK. The way I was thinking was to make it easier for users to write MY::test_harness() so they can plug in any testing system, not just Test::Harness compatible ones. This would mostly involve separating the scaffolding code (expanding and sorting the arguments, fixing up @INC) from the Test::Harness specific stuff. Something like: [snip] Yes, that's all much better :) I'll have a look at it later today. -- Andy Armstrong, hexten.net
Re: TAPx::Harness support for EUMM
I for one would rather it wasn't.
Remembering that NOBODY ever passes Makefile.PL params manually, you
need every build system capable of supporting those params, and ever
CPAN client to be capable of passing them.
An environment variable is a direct line from the user/system to EUMM
for ONLY those cases where it actually is EUMM, and it degrades nicely
in the cases where it isn't.
We've already had enough problems with some build systems not supporting
PREFIX, or --default, or any number of other flags...
Adam K
Michael G Schwern wrote:
Andy Armstrong wrote:
Sure - I'm open to suggestions. Do you mean something like this?:
$ export PERL_EUMM_HARNESS_CLASS=TAPx::Harness::Compatible
$ make test
That's one way, though I'd rather it be a Makefile.PL argument. [1]
The way I was thinking was to make it easier for users to write
MY::test_harness() so they can plug in any testing system, not just
Test::Harness compatible ones. This would mostly involve separating the
scaffolding code (expanding and sorting the arguments, fixing up @INC) from the
Test::Harness specific stuff. Something like:
sub test_harness {
require Test::Harness;
require File::Spec;
my $verbose = shift;
# Because Windows doesn't do this for us and listing all the *.t files
# out on the command line can blow over its exec limit.
require ExtUtils::Command;
my @files = sort { lc $a cmp lc $b }
ExtUtils::Command::expand_wildcards(@ARGV);
local @INC = @INC;
unshift @INC, map { File::Spec-rel2abs($_) } @_;
run_tests(files = [EMAIL PROTECTED], verbose = $verbose);
}
sub run_tests {
my %args = @_;
$Test::Harness::verbose = $args{verbose};
return Test::Harness::runtests(@{$args{files}});
}
Then all you have to override is run_tests().
[1] Or, for the really adventurous... implement a makemakerrc.
Re: TAPx::Harness support for EUMM
On 30 Jan 2007, at 11:34, Adam Kennedy wrote: I for one would rather it wasn't. Remembering that NOBODY ever passes Makefile.PL params manually, you need every build system capable of supporting those params, and ever CPAN client to be capable of passing them. An environment variable is a direct line from the user/system to EUMM for ONLY those cases where it actually is EUMM, and it degrades nicely in the cases where it isn't. I guess it can be an env variable or a command line option without too much difficulty. -- Andy Armstrong, hexten.net
Re: TAPx::Harness support for EUMM
Adam Kennedy wrote: I for one would rather it wasn't. Remembering that NOBODY ever passes Makefile.PL params manually, you need every build system capable of supporting those params, and ever CPAN client to be capable of passing them. An environment variable is a direct line from the user/system to EUMM for ONLY those cases where it actually is EUMM, and it degrades nicely in the cases where it isn't. We've already had enough problems with some build systems not supporting PREFIX, or --default, or any number of other flags... I think all the blood is rushing to your head, being on the bottom of the world. ;P The CPAN clients can easily be configured to pass arbitrary arguments to Makefile.PL. They'd suck pretty hard if they didn't. Every Makefile.PL is run by perl in a separate process. Likewise we run 'make' and 'make install' in separate processes. If you have any parameters (e.g. PREFIX, LIB, UNINST or the like) you want to pass to the calls, please specify them here. As for build systems (I presume you mean stuff that turns CPAN modules into dpkg, rpms, etc...), if they don't want to pass in a new Makefile.PL argument that's their problem. And I don't think a user having an environment variable set and thus globally effecting a build system which doesn't expect it is such a hot idea. Finally, should you still want your environment variables there's the little used PERL_MM_OPT in which you can specify your command line arguments.
Re: TAPx::Harness support for EUMM
Andy Armstrong wrote: On 27 Jan 2007, at 19:10, Andy Armstrong wrote: I've just committed a patch against ExtUtils::MakeMaker 6.31 that makes test_harness use TAPx::Harness instead of Test::Harness if the env variable PERL_EUMM_USE_TAPX is set to a true value and TAPx::Harness is installed. I should clarify: I haven't patched EUMM; I've made a patch that can be applied against EUMM and made it available in our svn. Umm, yeah. I was wondering about that.
Re: TAPx::Harness support for EUMM
Andy Armstrong wrote:
I've just committed a patch against ExtUtils::MakeMaker 6.31 that makes
test_harness use TAPx::Harness instead of Test::Harness if the env
variable PERL_EUMM_USE_TAPX is set to a true value and TAPx::Harness is
installed.
EUMM Patch:
http://svn.hexten.net/tapx/patches/ExtUtils-MakeMaker-6.31.patch
I couldn't accept this patch to MM. This would lead to MM's environment being
littered with PERL_EUMM_USE_FLAVOR_OF_THE_WEEK. And if TAPx::Harness is going
to be the guts for Test::Harness anyway there isn't much point.
Need something a bit more generic. Perhaps make it easier to override the
behavior of test_harness()?
Also fall through logic makes my eyes bleed. Rather than this...
if ($ENV{PERL_EUMM_USE_TAPX}) {
eval require TAPx::Harness;
unless ($@) {
...TAPx code...
return;
}
}
# Fallback: use Test::Harness
Do this.
if( $ENV{PERL_EUMM_USE_TAPX} eval require TAPx::Harness ) {
...TAPx code...
}
else {
...Test::Harness code...
}
Or if the condition for checking to use TAPx::Harness were more complex you can
figure it out beforehand and roll the decision up into $use_tapx.
Re: TAPx::Harness support for EUMM
On 29 Jan 2007, at 12:41, Michael G Schwern wrote: Umm, yeah. I was wondering about that. Sorry for the confusion. The patch serves two purposes: 1) It makes it possible for people to try TAPx::Harness and easily disable it if they run into problems 2) It's part of me working out the role of the TAPx::Harness::Compatible code. I'm trying to identify cases where extant code can easily be made compatible with the new TAPx::Harness interface as part of understanding how the compatibility layer is likely to be used. -- Andy Armstrong, hexten.net
Re: TAPx::Harness support for EUMM
On 29 Jan 2007, at 12:57, Michael G Schwern wrote:
EUMM Patch: http://svn.hexten.net/tapx/patches/ExtUtils-
MakeMaker-6.31.patch
I couldn't accept this patch to MM. This would lead to MM's
environment being littered with PERL_EUMM_USE_FLAVOR_OF_THE_WEEK.
And if TAPx::Harness is going to be the guts for Test::Harness
anyway there isn't much point.
Indeed. I should have been more explicit about my intentions here.
It's offered only as a simple way of injecting TAPx::Harness just now
so that people can play with it in a fairly risk free way.
Actually produced the patch so that *I* can play with TAPx::Harness -
and thought it might be useful for others in the same way.
Need something a bit more generic. Perhaps make it easier to
override the behavior of test_harness()?
Sure - I'm open to suggestions. Do you mean something like this?:
$ export PERL_EUMM_HARNESS_CLASS=TAPx::Harness::Compatible
$ make test
Also fall through logic makes my eyes bleed. Rather than this...
if ($ENV{PERL_EUMM_USE_TAPX}) {
eval require TAPx::Harness;
unless ($@) {
...TAPx code...
return;
}
}
# Fallback: use Test::Harness
Do this.
if( $ENV{PERL_EUMM_USE_TAPX} eval require TAPx::Harness ) {
...TAPx code...
}
else {
...Test::Harness code...
}
Or if the condition for checking to use TAPx::Harness were more
complex you can figure it out beforehand and roll the decision up
into $use_tapx.
Yes indeed. But as you say it'd be nicer still to be able to plug in
any alternative harness.
--
Andy Armstrong, hexten.net
Re: TAPx::Harness support for EUMM
--- Andy Armstrong [EMAIL PROTECTED] wrote: Or if the condition for checking to use TAPx::Harness were more complex you can figure it out beforehand and roll the decision up into $use_tapx. Yes indeed. But as you say it'd be nicer still to be able to plug in any alternative harness. Agreed. Particularly since a large impetus of this project is to allow folks to write custom harnesses for their needs. Cheers, Ovid -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: TAPx::Harness support for EUMM
Andy Armstrong wrote:
Sure - I'm open to suggestions. Do you mean something like this?:
$ export PERL_EUMM_HARNESS_CLASS=TAPx::Harness::Compatible
$ make test
That's one way, though I'd rather it be a Makefile.PL argument. [1]
The way I was thinking was to make it easier for users to write
MY::test_harness() so they can plug in any testing system, not just
Test::Harness compatible ones. This would mostly involve separating the
scaffolding code (expanding and sorting the arguments, fixing up @INC) from the
Test::Harness specific stuff. Something like:
sub test_harness {
require Test::Harness;
require File::Spec;
my $verbose = shift;
# Because Windows doesn't do this for us and listing all the *.t files
# out on the command line can blow over its exec limit.
require ExtUtils::Command;
my @files = sort { lc $a cmp lc $b }
ExtUtils::Command::expand_wildcards(@ARGV);
local @INC = @INC;
unshift @INC, map { File::Spec-rel2abs($_) } @_;
run_tests(files = [EMAIL PROTECTED], verbose = $verbose);
}
sub run_tests {
my %args = @_;
$Test::Harness::verbose = $args{verbose};
return Test::Harness::runtests(@{$args{files}});
}
Then all you have to override is run_tests().
[1] Or, for the really adventurous... implement a makemakerrc.
TAPx::Harness support for EUMM
I've just committed a patch against ExtUtils::MakeMaker 6.31 that makes test_harness use TAPx::Harness instead of Test::Harness if the env variable PERL_EUMM_USE_TAPX is set to a true value and TAPx::Harness is installed. Which this patch applied make test for any EUMM based module will use TAPx::Harness. TAPx::Parser SVN: http://svn.hexten.net/tapx/ EUMM Patch: http://svn.hexten.net/tapx/patches/ExtUtils- MakeMaker-6.31.patch -- Andy Armstrong, hexten.net
Re: TAPx::Harness support for EUMM
On 27 Jan 2007, at 19:10, Andy Armstrong wrote: I've just committed a patch against ExtUtils::MakeMaker 6.31 that makes test_harness use TAPx::Harness instead of Test::Harness if the env variable PERL_EUMM_USE_TAPX is set to a true value and TAPx::Harness is installed. I should clarify: I haven't patched EUMM; I've made a patch that can be applied against EUMM and made it available in our svn. -- Andy Armstrong, hexten.net
