Bug #22149 for ExtUtils-MakeMaker: Bug in ExtUtils::MM_Any::manifypod

Tue Oct 17 12:40:39 2006 lanny [...] cisco.com - Ticket created

Subject:	Bug in ExtUtils::MM_Any::manifypod_target()
Date:	Tue, 17 Oct 2006 11:39:32 -0500
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Lanny Ripple <lanny [...] cisco.com>

Release: ExtUtils-MM_Any-0.13_01 (Still exists in latest ExtUtils::MakeMaker version.) ExtUtils::MM_Any::manifypod_target() gathers keys from MAN1PODS and MAN3PODS. However it duplicates MAN3PODS. Rough code example showing the pattern is: for my $name ( keys %{ $self->{MAN1PODS }}, keys %{ $self->{MAN3PODS}} ) { ... } for my $name ( keys %{ $self->{MAN3PODS}} } ) { ... } Here's a diff of the solution I placed in my install. *************** *** 648,654 **** my $dependencies = ''; # populate manXpods & dependencies: ! foreach my $name (keys %{$self->{MAN1PODS}}, keys %{$self->{MAN3PODS}}) { $dependencies .= " \\\n\t$name"; } --- 648,654 ---- my $dependencies = ''; # populate manXpods & dependencies: ! foreach my $name (keys %{$self->{MAN1PODS}}) { $dependencies .= " \\\n\t$name"; } --- cut --- -ljr -- Lanny Ripple <lanny@cisco.com> ScmDB / Cisco Systems, Inc.

Tue Oct 17 20:07:15 2006 mschwern [...] cpan.org - Correspondence added

Good catch. According to the logs that was introduced years ago. Was it causing a problem or did you just happen to notice the duplication? r1114 (orig r1114): schwern | 2002-12-18 21:23:09 -0800 Changed paths: M /mirror/svn.schwern.org/CPAN/ExtUtils-MakeMaker/trunk/lib/ExtUtils/MM_Any.p m M /mirror/svn.schwern.org/CPAN/ExtUtils-MakeMaker/trunk/lib/ExtUtils/MM_Unix. pm Adapting manifypods to use split_command().

Tue Oct 17 20:07:16 2006 The RT System itself - Status changed from 'new' to 'open'

Tue Oct 17 20:07:16 2006 mschwern [...] cpan.org - Status changed from 'open' to 'resolved'

Wed Oct 18 10:52:46 2006 lanny [...] cisco.com - Correspondence added

Subject:	Re: [rt.cpan.org #22149] Bug in ExtUtils::MM_Any::manifypod_target()
Date:	Wed, 18 Oct 2006 09:51:59 -0500
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Lanny Ripple <lanny [...] cisco.com>

I'm working on the Pugs project and was trying to figure out why an ExtUtil generated makefile was failing on Win32 using nmake-1.5. I thought this was the problem but it turns out it's the split_command() heuristic for trying not to exceed max_exec_len on text expansion. (Previously reported as: http://rt.cpan.org/Public/Bug/Display.html?id=20145 and apparently TODO after 6.31). I have worked around it by explicitly redefining \&ExtUtils::MM_Win32::max_exec_len for the makefile generation that is causing the problem. A better solution would be if ExtUtils supported setting the expansion value for split_command() in Makefile.PL. Not ideal but unless the tool could fully expand all text, check against max_exec_len, and then rework as needed I don't see an internal solution working. Cheers, -ljr Michael_G_Schwern via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=22149 > > > Good catch. According to the logs that was introduced years ago. Was > it causing a problem or did you just happen to notice the duplication? > > > r1114 (orig r1114): schwern | 2002-12-18 21:23:09 -0800 > Changed paths: > M > /mirror/svn.schwern.org/CPAN/ExtUtils-MakeMaker/trunk/lib/ExtUtils/MM_Any.p > m > M > /mirror/svn.schwern.org/CPAN/ExtUtils-MakeMaker/trunk/lib/ExtUtils/MM_Unix. > pm > > Adapting manifypods to use split_command().

-- Lanny Ripple <lanny@cisco.com> ScmDB / Cisco Systems, Inc.

Wed Oct 18 10:52:48 2006 The RT System itself - Status changed from 'resolved' to 'open'

Wed Oct 25 03:16:09 2006 mschwern [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #22149 for ExtUtils-MakeMaker: Bug in ExtUtils::MM_Any::manifypod_target()