Skip Menu |

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

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

People
Owner: Nobody in particular
Requestors: steve.hay [...] uk.radan.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 6.25_08
Fixed in: (no value)



Subject: Error with pm_to_blib.ts target building libwin32
I reported this bug already on makemaker@perl.org (http://www.mail-archive.com/makemaker@perl.org/msg01865.html), but there was no reply so I'm logging it here too so that it doesn't get forgotten. In short, when trying to build libwin32-0.191 with EU-MM-6.25_08 I find that Win32API/File/cFile.pc doesn't get copied into place. The copy is performed by the cFile_pc_to_blib target, which was referenced like this under 6.17: pure_all :: config pm_to_blib subdirs linkext $(NOECHO) $(NOOP) pm_to_blib: cFile_pc_to_blib However, under 6.25_08 the pure_all target now depends on pm_to_blib.ts, but it is still pm_to_blib that depends on cFile_pc_to_blib so the latter target never gets run: pure_all :: config pm_to_blib.ts subdirs linkext $(NOECHO) $(NOOP) # For backwards compat with anything that referenced this target. pm_to_blib: pm_to_blib.ts $(NOOP) pm_to_blib: cFile_pc_to_blib I'm running perl-5.8.6 on WinXP, using VC++ 6.0 and nmake.
It turns out that the offending pm_to_blib reference actually comes from libwin32 itself - APIFile/Makefile.PL contains a MY::postamble that refers to it: # Install F<$final> whenever regular pm_to_blib target is built: push @m, " pm_to_blib: ${_final}_to_blib ${_final}_to_blib: $final ... I don't know what the correct solution here is. Is that Makefile.PL wrong to have referenced such EU::MM internals, or has EU::MM broken backwards compatibility?
[SHAY - Wed Feb 16 06:17:13 2005]: Show quoted text
> I don't know what the correct solution here is. Is that Makefile.PL > wrong to have referenced such EU::MM internals, or has EU::MM broken > backwards compatibility?
Both. It is wrong to have referenced internals, however there is no right way to do it. This is why MakeMaker is doomed. Because of this, MakeMaker tries as hard as it can to not break author's modules with internal changes to the Makefile. This is why MakeMaker is doomed. I think I know how to fix this particular problem. Look for _09.
From: rurban [...] x-ray.at