Bug #100159 for ExtUtils-MakeMaker: EUMM 7.00 breaks SREZIC/Tk-804.032.tar.gz

Thu Nov 06 13:16:50 2014 SREZIC [...] cpan.org - Ticket created

Subject:

EUMM 7.00 breaks SREZIC/Tk-804.032.tar.gz

Building stops with make[1]: *** No rule to make target `pTk/tkInt.h', needed by `Xlib.o'. Stop. make[1]: Leaving directory `/home/eserte/src/perl-tk/Xlib' make: *** [subdirs] Error 2 On the same system (Debian 7, perl 5.18.4) it works fine with EUMM 6.98. It seems that the crucial difference in the generated Xlib/Makefile is Xlib$(OBJ_EXT) : Xlib.c ../pTk/tkOption.h ../pTk/tkOption.m \ ../pTk/tkOption.t ../pTk/tkOption_f.h ../pTk/tkVMacro.h ../tkGlue.def \ ../tkGlue.h ../tkGlue.m ../tkGlue.t ../tkGlue_f.h ../vtab.def GC.def \ pTk/tkInt.h pTk/tkPort.h vs. Xlib$(OBJ_EXT) : Xlib.c ../pTk/Lang.h ../pTk/Lang.m ../pTk/Lang.t \ ../pTk/Lang_f.h ../pTk/Xlib.m ../pTk/Xlib.t ../pTk/Xlib_f.h \ ../pTk/tcl.h ../pTk/tclDecls.h ../pTk/tclDecls.m ../pTk/tclDecls.t \ ../pTk/tclDecls_f.h ../pTk/tclPlatDecls.h ../pTk/tk.h ../pTk/tk.m \ ../pTk/tk.t ../pTk/tkConfig.h ../pTk/tkDecls.h ../pTk/tkDecls.m \ ../pTk/tkDecls.t ../pTk/tkDecls_f.h ../pTk/tkEvent.h ../pTk/tkEvent.m \ ../pTk/tkEvent.t ../pTk/tkEvent_f.h ../pTk/tkInt.h ../pTk/tkInt.m \ ../pTk/tkInt.t ../pTk/tkIntDecls.h ../pTk/tkIntDecls.m \ ../pTk/tkIntDecls.t ../pTk/tkIntDecls_f.h ../pTk/tkInt_f.h \ ../pTk/tkOption.h ../pTk/tkOption.m ../pTk/tkOption.t \ ../pTk/tkOption_f.h ../pTk/tkPort.h ../pTk/tkUnixPort.h \ ../pTk/tkVMacro.h ../pTk/tk_f.h ../tkGlue.def ../tkGlue.h ../tkGlue.m \ ../tkGlue.t ../tkGlue_f.h ../vtab.def GC.def First variant is the EUMM 7.00 variant, and looks incomplete and has some wrong paths.

Thu Nov 06 13:19:22 2014 SREZIC [...] cpan.org - Broken in 7.01_08 added

Thu Nov 06 13:39:54 2014 SREZIC [...] cpan.org - Broken in 6.99_10 added

Thu Nov 06 14:56:11 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-11-06 13:16:50, SREZIC wrote: Show quoted text

> Building stops with > > make[1]: *** No rule to make target `pTk/tkInt.h', needed by `Xlib.o'. > Stop. > make[1]: Leaving directory `/home/eserte/src/perl-tk/Xlib' > make: *** [subdirs] Error 2 > > On the same system (Debian 7, perl 5.18.4) it works fine with EUMM > 6.98. It seems that the crucial difference in the generated > Xlib/Makefile is > > Xlib$(OBJ_EXT) : Xlib.c ../pTk/tkOption.h ../pTk/tkOption.m \ > ../pTk/tkOption.t ../pTk/tkOption_f.h ../pTk/tkVMacro.h ../tkGlue.def > \ > ../tkGlue.h ../tkGlue.m ../tkGlue.t ../tkGlue_f.h ../vtab.def GC.def > \ > pTk/tkInt.h pTk/tkPort.h > > vs. > > Xlib$(OBJ_EXT) : Xlib.c ../pTk/Lang.h ../pTk/Lang.m ../pTk/Lang.t \ > ../pTk/Lang_f.h ../pTk/Xlib.m ../pTk/Xlib.t ../pTk/Xlib_f.h \ > ../pTk/tcl.h ../pTk/tclDecls.h ../pTk/tclDecls.m ../pTk/tclDecls.t \ > ../pTk/tclDecls_f.h ../pTk/tclPlatDecls.h ../pTk/tk.h ../pTk/tk.m \ > ../pTk/tk.t ../pTk/tkConfig.h ../pTk/tkDecls.h ../pTk/tkDecls.m \ > ../pTk/tkDecls.t ../pTk/tkDecls_f.h ../pTk/tkEvent.h ../pTk/tkEvent.m > \ > ../pTk/tkEvent.t ../pTk/tkEvent_f.h ../pTk/tkInt.h ../pTk/tkInt.m \ > ../pTk/tkInt.t ../pTk/tkIntDecls.h ../pTk/tkIntDecls.m \ > ../pTk/tkIntDecls.t ../pTk/tkIntDecls_f.h ../pTk/tkInt_f.h \ > ../pTk/tkOption.h ../pTk/tkOption.m ../pTk/tkOption.t \ > ../pTk/tkOption_f.h ../pTk/tkPort.h ../pTk/tkUnixPort.h \ > ../pTk/tkVMacro.h ../pTk/tk_f.h ../tkGlue.def ../tkGlue.h ../tkGlue.m > \ > ../tkGlue.t ../tkGlue_f.h ../vtab.def GC.def > > First variant is the EUMM 7.00 variant, and looks incomplete and has > some wrong paths.

Problem is probably caused by the quoting of PERL. Tk is doing something like the following in Tk/MMutil.pm, subroutine mTk_CHO ($self is probably some MM object): ... my $perl = $self->{'PERL'}; ... system($perl,"$tk/pTk/Tcl-pTk",$mTk->{$file},$file); ... and this fails.

Thu Nov 06 16:05:57 2014 BINGOS [...] cpan.org - Correspondence added 120 min

Hi, I've spent an hour or so bisecting this issue against the EUMM repository and it appears to be this commit that breaks Tk build: https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/5dd48b9ca77e3b8982205dd168b2a0e28526a901 I'm not sure how that pertains to the breakage, but with the commit just before Tk builds okay, that one no dice. I noticed with the many times I ran Makefile.PL in Tk that 'assume made' featured a lot in the output when the build was 'bad'. This text appears to come from Tk/MakeDepend.pm I'm going to ask Mohawk, the commit author, to have a look.

Thu Nov 06 16:05:58 2014 The RT System itself - Status changed from 'new' to 'open'

Thu Nov 06 16:49:01 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-11-06 16:05:57, BINGOS wrote: Show quoted text

> Hi, > > I've spent an hour or so bisecting this issue against the EUMM > repository and it appears to be this commit that > breaks Tk build: > > https://github.com/Perl-Toolchain-Gang/ExtUtils- > MakeMaker/commit/5dd48b9ca77e3b8982205dd168b2a0e28526a901 > > I'm not sure how that pertains to the breakage, but with the commit > just before Tk builds okay, that one > no dice. > > I noticed with the many times I ran Makefile.PL in Tk that 'assume > made' featured a lot in the output > when the build was 'bad'. This text appears to come from > Tk/MakeDepend.pm > > I'm going to ask Mohawk, the commit author, to have a look.

With the following Makefile.PL, one can see the difference before and after: use ExtUtils::MakeMaker; WriteMakefile(NAME => "test"); sub MY::postamble { warn "PERL=" . shift->{PERL}; } Before, output is: PERL=/usr/local/bin/perl at Makefile.PL line 4. After: PERL="/usr/local/bin/perl" at Makefile.PL line 4. For Tk, I fixed the problem by not using $self->{PERL} anymore (it seems that $^X works instead).

Wed Nov 19 19:43:41 2014 ETJ [...] cpan.org - Correspondence added

I am told that using the internals of an EUMM object is undocumented and therefore not a good idea. The purpose of the PERL member of the EUMM hash is to be printable and usable in a string-system/exec. If you wanted to use it, do a string-system in the case you mention. I would suggest this is not a bug in EUMM. Could you close it?

Thu Nov 20 01:36:43 2014 SREZIC [...] cpan.org - Correspondence added

On 2014-11-19 19:43:41, ETJ wrote: Show quoted text

> I am told that using the internals of an EUMM object is undocumented > and therefore not a good idea. The purpose of the PERL member of the > EUMM hash is to be printable and usable in a string-system/exec. If > you wanted to use it, do a string-system in the case you mention. > > I would suggest this is not a bug in EUMM. Could you close it?

In the EUMM documentation "PERL" is at least documented to be settable from commandline when running Makefile.PL. So I tried it with an argument containing spaces and found the result not very useful: $ perl Makefile.PL PERL="/path/with spaces/perl" -> PERL = "/path/with" spaces/perl And with this the generated Makefile looks invalid: $ perl Makefile.PL PERL='"/path/with spaces/perl"' -> PERL = "/path/with" spaces/perl" I think at least this should be fixed, and maybe the documentation amended.

Sun Dec 14 06:10:54 2014 ETJ [...] cpan.org - Correspondence added 30 min

EUMM's t/xs.t's Makefile.PL routinely tests this functionality by setting PERL => "$^X -w". I have just added to the doc this snippet: ---8<--- =item PERL Perl binary for tasks that can be done by miniperl. If it contains spaces or other shell metacharacters, it needs to be quoted in a way that protects them, since this value is intended to be inserted in a shell command line in the Makefile. E.g.: # Perl executable lives in "C:/Program Files/Perl/bin" # Normally you don't need to set this yourself! $ perl Makefile.PL PERL='"C:/Program Files/Perl/bin/perl.exe" -w' ---8<--- I am therefore closing this.

Sun Dec 14 06:10:56 2014 ETJ [...] cpan.org - Status changed from 'open' to 'resolved'

Sun Dec 14 06:10:56 2014 ETJ [...] cpan.org - Taken