Bug #46658 for ExtUtils-MakeMaker: Incompatible with older ExtUtils::Install

Thu Jun 04 00:21:53 2009 dmacks [...] netspace.org - Ticket created

Subject:	Incompatible with older ExtUtils::Install
Date:	Thu, 4 Jun 2009 00:21:27 -0400
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Daniel Macks <dmacks [...] netspace.org>

ExtUtils::MakeMaker 6.52 creates a Makefile recipe that uses a recently-implemented feature of ExtUtils::Install and that fails if ExtUtils::Install is an older version. EU::I 1.33 (what ships with perl5.8.8), 'perl Makefile.PL && make && make install' will fail when EU::I::install() is called with a parameter style that isn't known. For example, using fink to supply perl5.8.8 and all dependencies for Gnome2::Canvas: [...] make install NOECHO= [...] /sw/bin/perl5.8.8 -MExtUtils::Install -e 'install([ from_to => {@ARGV}, verbose => '\''0'\'', uninstall_shadows => '\''0'\'', dir_mode => '\''755'\'' ]);' -- \ read /sw/lib/perl5/site_perl/5.8.8/darwin-thread-multi-2level/auto/Gnome2/Canvas/.packlist \ write /sw/build.build/root-gnome2-canvas-pm588-1.002-6/sw/lib/perl5/5.8.8/darwin-thread-multi-2level/auto/Gnome2/Canvas/.packlist \ blib/lib /sw/build.build/root-gnome2-canvas-pm588-1.002-6/sw/lib/perl5/5.8.8 \ blib/arch /sw/build.build/root-gnome2-canvas-pm588-1.002-6/sw/lib/perl5/5.8.8/darwin-thread-multi-2level \ blib/bin /sw/build.build/root-gnome2-canvas-pm588-1.002-6/sw/bin \ blib/script /sw/build.build/root-gnome2-canvas-pm588-1.002-6/sw/bin \ blib/man1 /sw/build.build/root-gnome2-canvas-pm588-1.002-6/sw/share/man/man1 \ blib/man3 /sw/build.build/root-gnome2-canvas-pm588-1.002-6/sw/share/man/man3 Can't coerce array into hash at /sw/lib/perl5-core/5.8.8/ExtUtils/Install.pm line 94. If I upgrade my EU::I to 1.52, 'make install' works. Even with old EU::I, previous versions of EU::MM worked. The problem is in ExtUtils::MM_Any.pm line 1738: install([ from_to => {@ARGV}, verbose => '$(VERBINST)', uninstall_shadows => '$(UNINST)', dir_mode => '$(PERM_DIR)' ]); but until EU::I 1.47, install() only took a list of parameter values in specific order, not an array-ref of named parameters. I don't know the best solution here. The POD for EU::I::install() says the simple parameter list is deprecated, so who knows how long that syntax will be supported. Other solution is for EU::MM to specify a dependency on EU::I >= 1.47. It makes functional sense that EU::I, which is called by EU::MM, would be a dependency of EU::MM. But EU::I currently specified a dependency on EU::MM (no idea why), so that's circular. dan -- Daniel Macks dmacks@netspace.org http://www.netspace.org/~dmacks

Thu Jun 04 13:53:42 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #46658] Incompatible with older ExtUtils::Install
Date:	Thu, 04 Jun 2009 10:53:20 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

dmacks@netspace.org via RT wrote: Show quoted text

> ExtUtils::MakeMaker 6.52 creates a Makefile recipe that uses a > recently-implemented feature of ExtUtils::Install and that fails if > ExtUtils::Install is an older version. EU::I 1.33 (what ships with > perl5.8.8), 'perl Makefile.PL && make && make install' will fail when > EU::I::install() is called with a parameter style that isn't known.

Thanks for your report. You're right. I can reproduce with perl5.8.8. The tests don't even run. I need a real smoke server. MakeMaker ships with a new version of EUI and it supposed to use it, but it seems that's not always the case. I suspect that some of the tests and the install process aren't looking at blib/lib (where EUI is put) but in lib/ (where EUI is not). I'll try to look at it tonight, this weekend the latest. -- Life is like a sewer - what you get out of it depends on what you put into it. - Tom Lehrer

Thu Jun 04 13:53:43 2009 The RT System itself - Status changed from 'new' to 'open'

Sat Jun 06 21:47:50 2009 mschwern [...] cpan.org - Correspondence added

Subject:

pm_to_blib does not run if Makefile is rebuilt

Upon investigating, I've figured out the problem. First off, you didn't run the tests. They would have failed and saved you from installing a broken Perl build system. If there's one module you should always run the tests on before installing its MakeMaker. So now I don't feel so bad. Second, did you build MakeMaker with a different version of Perl? Perhaps 5.10? Perhaps one which already had a new ExtUtils::Install? If so then the work around is to simply "make clean" before re-running the installer for 5.8.8. So there's your work around. Alternatively, apply this patch. --- a/lib/ExtUtils/MM_Unix.pm +++ b/lib/ExtUtils/MM_Unix.pm @@ -2800,7 +2800,7 @@ sub pm_to_blib { my $self = shift; my($autodir) = $self->catdir('$(INST_LIB)','auto'); my $r = q{ -pm_to_blib : $(TO_INST_PM) +pm_to_blib : $(FIRST_MAKEFILE) $(TO_INST_PM) }; # VMS will swallow '' and PM_FILTER is often empty. So use q[] MakeMaker will test and install on a clean 5.6 and 5.8. Its only if the source has already been built with a perl that has a new ExtUtils::Install that it will fail. Details follow. The pm_to_blib target rebuilds blib. It only fires if any of the pm files have changed since the last pm_to_blib run. It doesn't depend on anything else. So, install MakeMaker on 5.10 or something which already has an up to date ExtUtils::Install and it will copy things to blib, but not ExtUtils::Install. Its already up to date. Then, without running clean, rerun Makefile.PL with 5.8.8 and run the tests WITHOUT RUNNING MAKE. None of the pm files have changed to blib does not get rebuilt. ExtUtils::Install is not copied into blib and the tests fail. To replicate: make realclean perl5.10.0 Makefile.PL make perl5.8.8 Makefile.PL make make test Solution: Have pm_to_blib depend on the Makefile. If the Makefile gets rebuilt so does blib. This will probably fix a number of other subtle bugs. This will be fixed shortly.

Sun Jun 07 17:29:43 2009 dmacks [...] netspace.org - Correspondence added

Subject:	Re: [rt.cpan.org #46658] Had passed self-test
Date:	Sun, 7 Jun 2009 17:29:22 -0400
To:	Michael G Schwern via RT <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
From:	Daniel Macks <dmacks [...] netspace.org>

On Sat, Jun 06, 2009 at 09:47:51PM -0400, Michael G Schwern via RT wrote: Show quoted text

> > First off, you didn't run the tests. They would have failed and saved > you from installing a broken Perl build system. If there's one module > you should always run the tests on before installing its MakeMaker. So > now I don't feel so bad.

Nope, self-test ran and "All tests successful." using perl5.8.6 and using perl5.8.8 (explicit path used when running Makefile.PL and also passed as the PERL variable to it). Only ones that were not "ok" were the ones "skipped: This is not $NOT_MY_PLATFORM". Show quoted text

> Second, did you build MakeMaker with a different version of Perl? > Perhaps 5.10? Perhaps one which already had a new ExtUtils::Install? > If so then the work around is to simply "make clean" before re-running > the installer for 5.8.8. So there's your work around.

I have perl5.8.6 (with EU::I 1.32 EU::MM 6.17) via OS X 10.4 and perl5.8.8 (with EU::I 1.33 EU::MM 6.30) via fink. I also have EU::MM 6.50 installed for each of those two perls. Never had perl5.8.10 on this machine, and there's no other Install.pm file anywhere. dan -- Daniel Macks dmacks@netspace.org http://www.netspace.org/~dmacks

Sun Jun 07 18:18:44 2009 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #46658] Had passed self-test
Date:	Sun, 07 Jun 2009 15:18:23 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

dmacks@netspace.org via RT wrote: Show quoted text

> Queue: ExtUtils-MakeMaker > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=46658 > > > On Sat, Jun 06, 2009 at 09:47:51PM -0400, Michael G Schwern via RT wrote:

>> First off, you didn't run the tests. They would have failed and saved >> you from installing a broken Perl build system. If there's one module >> you should always run the tests on before installing its MakeMaker. So >> now I don't feel so bad.

> > Nope, self-test ran and "All tests successful." using perl5.8.6 and > using perl5.8.8 (explicit path used when running Makefile.PL and also > passed as the PERL variable to it). Only ones that were not "ok" were > the ones "skipped: This is not $NOT_MY_PLATFORM".

Your original message said "perl Makefile.PL && make && make install" so I figured you didn't run the tests. Also I can reproduce your problem in the tests at my end. Apologies. Show quoted text

>> Second, did you build MakeMaker with a different version of Perl? >> Perhaps 5.10? Perhaps one which already had a new ExtUtils::Install? >> If so then the work around is to simply "make clean" before re-running >> the installer for 5.8.8. So there's your work around.

> > I have perl5.8.6 (with EU::I 1.32 EU::MM 6.17) via OS X 10.4 and > perl5.8.8 (with EU::I 1.33 EU::MM 6.30) via fink. I also have EU::MM > 6.50 installed for each of those two perls. Never had perl5.8.10 on > this machine, and there's no other Install.pm file anywhere.

Then something went wrong with the installation. Or the installation was altered afterwards. If the tests passed then the new ExtUtils::Install was staged and should have been installed. Its possible fink overwrote it later, since it will overlay the fink installed modules, or its possible it was shadowed by a pre-existing installed ExtUtils::Install. When you install MakeMaker, do you get any messages about "shadowing"? Do you see any mention of ExtUtils/Install.pm when building or installing MakeMaker? Does blib/lib/ExtUtils/Install.pm exist after testing MakeMaker? When you ran Makefile.PL, did you pass it any arguments such as INSTALLDIRS? Could you please attach the complete output of all steps of building, testing and installing MakeMaker along with your Makefile? Please check all the of above with the unaltered MakeMaker. Then please try the attached patch and see if that makes a difference. -- 31. Not allowed to let sock puppets take responsibility for any of my actions. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/

diff --git a/lib/ExtUtils/MM_Unix.pm b/lib/ExtUtils/MM_Unix.pm index 6cc1424..1fe1182 100644 --- a/lib/ExtUtils/MM_Unix.pm +++ b/lib/ExtUtils/MM_Unix.pm @@ -2800,7 +2800,7 @@ sub pm_to_blib { my $self = shift; my($autodir) = $self->catdir('$(INST_LIB)','auto'); my $r = q{ -pm_to_blib : $(TO_INST_PM) +pm_to_blib : $(FIRST_MAKEFILE) $(TO_INST_PM) }; # VMS will swallow '' and PM_FILTER is often empty. So use q[]

Sun Jun 07 20:45:46 2009 mschwern [...] cpan.org - Correspondence added

I've pushed a fix for this into the repo. Waiting on user info.

Sun Jun 07 20:45:50 2009 mschwern [...] cpan.org - Status changed from 'open' to 'stalled'

Wed Aug 28 17:10:26 2013 BINGOS [...] cpan.org - Correspondence added 5 min

EUMM will bootstrap itself including all prereqs. Resolving this ticket.

Wed Aug 28 17:10:26 2013 The RT System itself - Status changed from 'stalled' to 'open'

Wed Aug 28 17:10:26 2013 BINGOS [...] cpan.org - Status changed from 'open' to 'resolved'

Wed Aug 28 17:10:27 2013 BINGOS [...] cpan.org - Fixed in 6.74 added