Skip Menu |

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 96825
Status: open
Priority: 0/
Queue: Module-Build
People
Owner: Nobody in particular
Requestors: wyant [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Unimportant
Broken in: 0.4205
Fixed in: (no value)

History Show all quoted text
  Sun Jun 29 13:04:47 2014 wyant [...] cpan.org - Ticket created
Subject: testcover may fail if default Perl is not the Perl the module was built under
Under Module::Build 0.4205, the testcover module simply spawns 'cover' to analyze the data generated during the test. If the default Perl is different than the one that Build.PL was run under, the analysis may fail. The attached patch is one way to address the problem. I have marked this unimportant because the workaround is so simple.
Subject: Module-Build-Base.patch
--- lib/Module/Build/Base.old 2014-02-09 11:55:02.000000000 -0500 +++ lib/Module/Build/Base.pm 2014-06-29 12:25:54.000000000 -0400 @@ -2808,7 +2808,7 @@ local $ENV{HARNESS_PERL_SWITCHES} = "-MDevel::Cover"; $self->depends_on('test'); - $self->do_system('cover'); + $self->do_system($self->{properties}{perl}, '-S', 'cover'); } sub ACTION_code {
  Fri Jul 04 19:58:47 2014 LEONT [...] cpan.org - Correspondence added
Subject: Re: [rt.cpan.org #96825] testcover may fail if default Perl is not the Perl the module was built under
Date: Sat, 5 Jul 2014 01:58:19 +0200
To: bug-Module-Build [...] rt.cpan.org
From: Leon Timmermans <leont [...] cpan.org>
On Sun, Jun 29, 2014 at 7:04 PM, Tom Wyant via RT < bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> Under Module::Build 0.4205, the testcover module simply spawns 'cover' to > analyze the data generated during the test. If the default Perl is > different than the one that Build.PL was run under, the analysis may fail. > > The attached patch is one way to address the problem. > > I have marked this unimportant because the workaround is so simple. >
I agree this is a bug, I'm not sure this is the right solution. Running another perl's cover script with your own modules may run into issue (or maybe not). I'll have to look into this, and possibly ask Paul Johnson for some advice. Leon
  Fri Jul 04 19:58:48 2014 The RT System itself - Status changed from 'new' to 'open'
  Sat Jul 05 10:09:11 2014 wyant [...] cpan.org - Correspondence added
Thank you for looking into this. I never claimed that the patch I submitted was the right way to address the problem, simply that it was _A_ way. Changes to a key module like Module::Build should be carefully considered before acceptance. My motivation for wanting this is that I use Devel::ptkdb, but I am running one of those systems (Mac OS X) on which Tk consistently seg faults under Perl 5.20. I still have 5.18 around, so if I'm debugging I switch to that. But 5.20 is still my default Perl. The patch lets me not worry about what my default Perl is once I have built the module under the correct Perl. I have at least three workarounds: 1) Continue to apply "my" patch, which works for me, and which I can readily either fix or revert if it causes trouble. 2) Simply switch to 5.18 before running -d:ptkdb. 3) Take another look at Padre. It was flaky the last time I tried it, but that has been a while.