Skip Menu |

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

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

People
Owner: Nobody in particular
Requestors: MITHALDU [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 6.57_05
Fixed in: (no value)



Subject: miniperl.t causes tests to fail under ActivePerl 1007 (with patch proposal)
First off, i have no idea what miniperl is, so i was sorta flying blind on this one. When trying to run the miniperl.t test under ActivePerl 1007 with the newest dev version, it fails with an "Unknown error" deep in the bowels of required modules. This unknown error is actually caused by Carp's confess failing to run correctly on invocation. The error it's trying to output is a stacktrace along with the message "Tried to load XS for Win32". In order to fix both of these I've adapted NoXS.pm to include its own stacktrace emitter, as well as allow Win32 to passthrough to Dynaloader::bootstrap, so %Config can be populated. The changes can be found in this branch: http://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commits/ activeperl_miniperl_fix Since i'm not 100% confident about this, i'm submitting it here first, so a few people can look at it and provide feedback. (Suggestions as to where else to post about this are welcome.) Once I've received either some agreement on this being a fix that might work well, or some time of silence (indicating no disagreement), i'll merge it to trunk.
Subject: Re: [rt.cpan.org #61868] miniperl.t causes tests to fail under ActivePerl 1007 (with patch proposal)
Date: Fri, 08 Oct 2010 13:57:14 -0400
To: bug-ExtUtils-MakeMaker [...] rt.cpan.org
From: Michael G Schwern <schwern [...] pobox.com>
On 2010.10.3 5:22 PM, Christian Walde via RT wrote: Show quoted text
> First off, i have no idea what miniperl is, so i was sorta flying blind > on this one.
miniperl is a stripped down version of perl built as part of the process of building perl. Its primarily missing the ability to load XS modules. Because perl builds itself using MakeMaker and miniperl, the point of the test is to make sure MakeMaker can work without any XS modules. Fortunately, it only has to work with bleadperl. There's no backwards compatibility requirement. In fact, it probably shouldn't run outside of the core tests and release tests. I've just patched it up to not run outside the core. Show quoted text
> When trying to run the miniperl.t test under ActivePerl 1007 with the > newest dev version, it fails with an "Unknown error" deep in the bowels > of required modules. > > This unknown error is actually caused by Carp's confess failing to run > correctly on invocation. > > The error it's trying to output is a stacktrace along with the message > "Tried to load XS for Win32". > > In order to fix both of these I've adapted NoXS.pm to include its own > stacktrace emitter, as well as allow Win32 to passthrough to > Dynaloader::bootstrap, so %Config can be populated. The changes can be > found in this branch: > > http://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commits/ > activeperl_miniperl_fix > > Since i'm not 100% confident about this, i'm submitting it here first, > so a few people can look at it and provide feedback. (Suggestions as to > where else to post about this are welcome.) > > Once I've received either some agreement on this being a fix that might > work well, or some time of silence (indicating no disagreement), i'll > merge it to trunk.
Hmmm. Having to do all that seems like its papering over a bug in perl or Carp. I'm inclined to say just leave it and let p5p figure it out. They probably already have. -- 151. The proper way to report to my Commander is "Specialist Schwarz, reporting as ordered, Sir" not "You can't prove a thing!" -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
On Fri Oct 08 13:57:36 2010, schwern@pobox.com wrote: Show quoted text
> In fact, it probably shouldn't run outside of the core tests and > release tests. I've just patched it up to not run outside the > core.
Thanks a lot for the explanation. In this case i agree it is certainly best to just disable it and let people who actually deal with it poke at it. :)