Skip Menu |

This queue is for tickets about the ExtUtils-MakeMaker CPAN distribution.

Report information
The Basics
Id: 45701
Status: resolved
Priority: 0/
Queue: ExtUtils-MakeMaker

People
Owner: Nobody in particular
Requestors: schwern [...] pobox.com
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: [Fwd: Bug? EU::MM fails if PERL_SRC && not PERL_CORE]
Date: Mon, 04 May 2009 10:59:13 -0700
To: via RT <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
From: Michael G Schwern <schwern [...] pobox.com>
Show quoted text
-------- Original Message -------- Subject: Bug? EU::MM fails if PERL_SRC && not PERL_CORE Date: Sat, 2 May 2009 16:18:37 -0700 From: Joshua ben Jore <twists@gmail.com> To: Perl 5 Porters <perl5-porters@perl.org> At work, we've got a build repo for making a single debian package of perl and all the modules we use. Our current organization is: perl-whitepages-5.10.0/*perl* perl-whitepages-5.10.0/Configure ... perl-whitepages-5.10.0/whitepages-modules/*modules* perl-whitepages-5.0.0.0/whitepages-modules/ExtUtils-MakeMaker-6.50/ and the Debian build rules currently install perl, then build the modules. I've found I can build anything else except EU::MM itself which fails because some tests assume that if PERL_CORE is false, PERL_SRC must also be false. I can just reorganize my build and move on but I'm wondering if this is a bug in EU::MM. The documentation and notes say that PERL_SRC is intuited so that things in ext/ work. I'm not messing with ext/, I have an entirely different directory which happened to be inside the perl source tree. It seems like the ext/-seeking logic doesn't have to be effective here. Should it? I've included the "failing" tests. EU::MM makes t/Big-Dummy so the PERL_SRC path of ../../../.. is correct when the test runs because cwd is perl-whitepages-5.10.0/whitepages-modules/ExtUtils-MakeMaker-6.50/t/Big-Dummy. The tests worked right but thought to expect undef because PERL_CORE was false. t/INST.t 1..26 ... not ok 9 - PERL_SRC # Failed test 'PERL_SRC' # in t/INST.t at line 84. # got: '../../../..' # expected: undef ... # Looks like you failed 1 test of 26. t/INST_PREFIX.t 1..52 ... not ok 18 - PERL_SRC # Failed test 'PERL_SRC' # in t/INST_PREFIX.t at line 113. # got: '../../../..' # expected: undef BTW, having recently been tipped off to cpan2dist + CPANPLUS::Dist::Deb, I'm going to try switching to that. This memo is just about resolving the potential bug-or-not. Thanks, Josh -- 125. Two drink limit does not mean two kinds of drinks. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
RT-Send-CC: BINGOS [...] cpan.org
This seems like it's dealt with now in tests? (including verification by the smoke process)
My further take on this is that the scenario reported by the original requester most closely resembled a PERL_CORE situation, and therefore what he would need to do would be to simply run the tests with PERL_CORE set to the same value as when building Perl normally. I am therefore marking this as resolved.