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.
