Skip Menu |

This queue is for tickets about the MP3-Tag CPAN distribution.

Report information
The Basics
Id: 46602
Status: open
Priority: 0/
Queue: MP3-Tag

People
Owner: Nobody in particular
Requestors: eric_a_benson [...] yahoo.com
Cc:
AdminCc:

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



Subject: Bug in Makefile.PL on non-Unix platforms
Date: Mon, 1 Jun 2009 23:17:24 -0700 (PDT)
To: bug-MP3-Tag [...] rt.cpan.org
From: Eric Benson <eric_a_benson [...] yahoo.com>
It appears that the creation of the ./lib subdirectory caused manifypods() in Makefile.PL to fail on platforms where : is not a legal file name constituent. I discovered this bug while building on Cygwin. This code did not change, the bug was already there, but was not apparent until the source tree shifted. If this bug is not fixed, MP3::Tag cannot be built on Cygwin, and possibly not on Win32 as well, although I haven't tried that. I have a fix for this bug which is a little ugly. It involves cutting and pasting some code from ExtUtils::MakeMaker. However, it does fix the bug. Basically I just copied the piece of code from init_MAN3PODS in MM_Unix that your local version of manifypods() was skipping. ------------------------------------------------------------------- package MY; sub manifypods { my $self = shift; my $manpagename = 'lib/MP3/Tag/ID3v2-Data.pod'; my $parentlibs_re = join '|', @{$self->{PMLIBPARENTDIRS}}; unless($manpagename =~ s!^\W*($parentlibs_re)\W+!!s) { $manpagename = $self->catfile( split(/::/,$self->{PARENT_NAME}),$manpagename ); } $manpagename = $self->replace_manpage_separator($manpagename); $self->{MAN3PODS}->{'lib/MP3/Tag/ID3v2-Data.pod'} = $self->catfile("\$(INST_MAN3DIR)", "$manpagename.\$(MAN3EXT)"); $self->SUPER::manifypods(@_); } ------------------------------------------------------------------- A better solution would be to find a way to add this target to the list $self->{PM} prior to the processing done in init_MAN3PODS, but I have not pursued this approach. I learned more than I ever wanted to know about ExtUtils::MakeMaker tonight.
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms
Date: Tue, 2 Jun 2009 14:29:28 -0700
To: Eric Benson via RT <bug-MP3-Tag [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Tue, Jun 02, 2009 at 02:17:52AM -0400, Eric Benson via RT wrote: Show quoted text
> It appears that the creation of the ./lib subdirectory caused manifypods() in Makefile.PL to fail on platforms where : is not a legal file name constituent. I discovered this bug while building on Cygwin. This code did not change, the bug was already there, but was not apparent until the source tree shifted. If this bug is not fixed, MP3::Tag cannot be built on Cygwin, and possibly not on Win32 as well, although I haven't tried that.
The main development platform is non-Unix, so your description of the bug is faulty. I suspect a bug in MakeMaker on Cygwin. Try to compare its manifypods() with it of other DOSISH platforms... Yours, Ilya
Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms
Date: Tue, 2 Jun 2009 15:55:49 -0700 (PDT)
To: bug-MP3-Tag [...] rt.cpan.org
From: Eric Benson <eric_a_benson [...] yahoo.com>
You put a file name with a colon into the MAN3PODS hash. Does a file get written on your dev. platform that contains colons? That's where the problem occurs. Cygwin can't handle colons in file names, while "normal" Unix can. I'm guessing Win32 can't, but I don't have a Win32 Perl I can test against. Show quoted text
----- Original Message ---- From: Ilya Zakharevich via RT <bug-MP3-Tag@rt.cpan.org> To: eric_a_benson@yahoo.com Sent: Tuesday, June 2, 2009 2:29:53 PM Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms <URL: https://rt.cpan.org/Ticket/Display.html?id=46602 > On Tue, Jun 02, 2009 at 02:17:52AM -0400, Eric Benson via RT wrote:
> It appears that the creation of the ./lib subdirectory caused manifypods() in Makefile.PL to fail on platforms where : is not a legal file name constituent. I discovered this bug while building on Cygwin. This code did not change, the bug was already there, but was not apparent until the source tree shifted. If this bug is not fixed, MP3::Tag cannot be built on Cygwin, and possibly not on Win32 as well, although I haven't tried that.
The main development platform is non-Unix, so your description of the bug is faulty. I suspect a bug in MakeMaker on Cygwin. Try to compare its manifypods() with it of other DOSISH platforms... Yours, Ilya
Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms
Date: Tue, 2 Jun 2009 18:46:57 -0700 (PDT)
To: bug-MP3-Tag [...] rt.cpan.org
From: Eric Benson <eric_a_benson [...] yahoo.com>
OK, I just installed ActiveState Perl and did a CPAN install of MP3::Tag. It looks like the deal is that the manifypods rule in the generated Makefile never gets used in that environment. If I do a "make manifypods" in the ActiveState MP3::Tag build directory, I get a failure just like in Cygwin. If I use my patched Makefile.PL then "make manifypods" works in ActiveState as well as Cygwin. Show quoted text
----- Original Message ---- From: Ilya Zakharevich via RT <bug-MP3-Tag@rt.cpan.org> To: eric_a_benson@yahoo.com Sent: Tuesday, June 2, 2009 2:29:53 PM Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms <URL: https://rt.cpan.org/Ticket/Display.html?id=46602 > On Tue, Jun 02, 2009 at 02:17:52AM -0400, Eric Benson via RT wrote:
> It appears that the creation of the ./lib subdirectory caused manifypods() in Makefile.PL to fail on platforms where : is not a legal file name constituent. I discovered this bug while building on Cygwin. This code did not change, the bug was already there, but was not apparent until the source tree shifted. If this bug is not fixed, MP3::Tag cannot be built on Cygwin, and possibly not on Win32 as well, although I haven't tried that.
The main development platform is non-Unix, so your description of the bug is faulty. I suspect a bug in MakeMaker on Cygwin. Try to compare its manifypods() with it of other DOSISH platforms... Yours, Ilya
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms
Date: Tue, 2 Jun 2009 22:49:38 -0700
To: Eric Benson via RT <bug-MP3-Tag [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Tue, Jun 02, 2009 at 02:17:52AM -0400, Eric Benson via RT wrote: Show quoted text
> It appears that the creation of the ./lib subdirectory caused
manifypods() in Makefile.PL to fail on platforms where : is not a legal file name constituent. I discovered this bug while building on Cygwin. This code did not change, the bug was already there, but was not apparent until the source tree shifted. Do you know why this "was not apparent"? Show quoted text
> If this bug is not
fixed, MP3::Tag cannot be built on Cygwin, and possibly not on Win32 as well, although I haven't tried that. ??? Why failure of manifypod() implies "cannot be built"? Puzzled, Ilya
Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms
Date: Wed, 3 Jun 2009 01:29:47 -0700 (PDT)
To: bug-MP3-Tag [...] rt.cpan.org
From: Eric Benson <eric_a_benson [...] yahoo.com>
MM_Win32 in ExtUtils is using all_target from MM_Any.pm, while MM_Cygwin is using all_target defined in MM_Unix.pm. The MM_Unix all :: target generated in the Makefile includes manifypods as a dependency, while the MM_Any does not include it. That's why the build fails on Cygwin. On "real" Unix manifypods creates files with colons in their names, but on Cygwin the colons are turned into dots, but it happens at an earlier stage in the process than the function manifypods, in the function init_MAN3PODS(). The original double colons in the name get converted to directory separators, then converted back into :: on Unix or into dots on Cygwin by the function replace_manpage_separator(). Your local version of manifypods only works for the Unix case by accident. The version I sent contains the code from init_MAN3PODS that does the right thing on all platforms. Show quoted text
----- Original Message ---- From: Ilya Zakharevich via RT <bug-MP3-Tag@rt.cpan.org> To: eric_a_benson@yahoo.com Sent: Tuesday, June 2, 2009 10:50:03 PM Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms <URL: http://rt.cpan.org/Ticket/Display.html?id=46602 > On Tue, Jun 02, 2009 at 02:17:52AM -0400, Eric Benson via RT wrote:
> It appears that the creation of the ./lib subdirectory caused
manifypods() in Makefile.PL to fail on platforms where : is not a legal file name constituent. I discovered this bug while building on Cygwin. This code did not change, the bug was already there, but was not apparent until the source tree shifted. Do you know why this "was not apparent"?
> If this bug is not
fixed, MP3::Tag cannot be built on Cygwin, and possibly not on Win32 as well, although I haven't tried that. ??? Why failure of manifypod() implies "cannot be built"? Puzzled, Ilya
CC: undisclosed-recipients: ;
Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms
Date: Wed, 3 Jun 2009 02:38:47 -0700
To: Eric Benson via RT <bug-MP3-Tag [...] rt.cpan.org>
From: Ilya Zakharevich <nospam-abuse [...] ilyaz.org>
On Wed, Jun 03, 2009 at 04:30:09AM -0400, Eric Benson via RT wrote: Show quoted text
> MM_Win32 in ExtUtils is using all_target from MM_Any.pm, while
MM_Cygwin is using all_target defined in MM_Unix.pm. The MM_Unix all :: target generated in the Makefile includes manifypods as a dependency, while the MM_Any does not include it. That's why the build fails on Cygwin. On "real" Unix manifypods creates files with colons in their names, but on Cygwin the colons are turned into dots, but it happens at an earlier stage in the process than the function manifypods, in the function init_MAN3PODS(). The original double colons in the name get converted to directory separators, then converted back into :: on Unix or into dots on Cygwin by the function replace_manpage_separator(). Your local version of manifypods only works for the Unix case by accident. The version I sent contains the code from init_MAN3PODS that does the right thing on all platforms. Something in this explanation is yet fishy, since MM_OS2 inherits from MM_Unix (and OS/2 does not allow : in filenames), and I do not see any problem on OS/2... Anyway, thank you a lot for unwinding this mess for me! I marked this in my TODO file, but do not yet know (see above ;-) what is the PROPER way to fix this... Yours, Ilya
Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms
Date: Wed, 3 Jun 2009 08:38:29 -0700 (PDT)
To: bug-MP3-Tag [...] rt.cpan.org
From: Eric Benson <eric_a_benson [...] yahoo.com>
MM_OS2 inherits from MM_Any and then MM_Unix, the same as MM_Win32 does. So it uses the all_target() in MM_Any not MM_Unix. Cygwin, Windows, OS/2 are all generating Makefiles for which "make manifypods" will always fail, but only Cygwin fails on "make all" because it inherits directly from MM_Unix. This inheritance structure is a little odd, since MM_Unix inherits from MM_Any. So on these "less Unixy" platforms the grandparent shadows the definition from the parent, by also being a parent earlier in the precedence list! Browsing around the other platform MM implementations, I see that Darwin and AIX inherit only from MM_Unix, while BeOS inherits from MM_Any and then MM_Unix. That's not really the issue anyway, since the definition of manifypods() in MP3::Tag's Makefile.PL is broken in any case. The resulting Makefile has a rule that cannot work on any platform that does not allow colons in filenames. The patch I sent will fix it. It is a little suspect because it is cut-and-pasted from init_MAN3PODS. One way to fix it would be to shadow that function instead of manifypods. You would have to arrange to add the right name to the {PM} hash so that it got processed correctly. By the way, isn't data_pod.PL being used to generate a file that is in the source tree anyway? That in itself seems a little suspect. SInce it only ever changes when a new ID3 version is supported, it seems like a bit of overkill to run this script every time you build anyway. You really only need to run it yourself when the ID3 tags change. That seems like the "right" fix to me. Show quoted text
----- Original Message ---- From: Ilya Zakharevich via RT <bug-MP3-Tag@rt.cpan.org> To: eric_a_benson@yahoo.com Sent: Wednesday, June 3, 2009 2:39:13 AM Subject: Re: [rt.cpan.org #46602] Bug in Makefile.PL on non-Unix platforms <URL: http://rt.cpan.org/Ticket/Display.html?id=46602 > On Wed, Jun 03, 2009 at 04:30:09AM -0400, Eric Benson via RT wrote:
> MM_Win32 in ExtUtils is using all_target from MM_Any.pm, while
MM_Cygwin is using all_target defined in MM_Unix.pm. The MM_Unix all :: target generated in the Makefile includes manifypods as a dependency, while the MM_Any does not include it. That's why the build fails on Cygwin. On "real" Unix manifypods creates files with colons in their names, but on Cygwin the colons are turned into dots, but it happens at an earlier stage in the process than the function manifypods, in the function init_MAN3PODS(). The original double colons in the name get converted to directory separators, then converted back into :: on Unix or into dots on Cygwin by the function replace_manpage_separator(). Your local version of manifypods only works for the Unix case by accident. The version I sent contains the code from init_MAN3PODS that does the right thing on all platforms. Something in this explanation is yet fishy, since MM_OS2 inherits from MM_Unix (and OS/2 does not allow : in filenames), and I do not see any problem on OS/2... Anyway, thank you a lot for unwinding this mess for me! I marked this in my TODO file, but do not yet know (see above ;-) what is the PROPER way to fix this... Yours, Ilya