Closed p5pRT closed 8 years ago
-----Original Message----- From: sisyphus1@optusnet.com.au Sent: Monday\, November 09\, 2015 9:00 PM To: Steve Hay ; bulk88 via RT Cc: perl5-porters@perl.org Subject: Re: [perl #123440] Adding win32/GNUmakefile
But surely it should be allowable to have sh.exe in your path ? That's why the "SHELL := cmd.exe" entry was placed in GNUmakefile in the first place - and I'm sure that used to work. But I've just checked (for the first time in a while) whether I can build recent perl if I have sh.exe in the path\, and I can't !!
One problem (probably *the* problem) is that the gmake-style Makefile that EU::MM generates does not specify a SHELL. I don't know how or why that omission has come about.
Last December I opened an EU::MM ticket about this: https://rt.cpan.org/Public/Bug/Display.html?id=101132
I ultimately provided a patch that was accepted and applied to EU::MM master as https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/06aeb803cccb2643e1e1cd8edcbcaf966981e05c
The ticket was then closed\, but I don't see any remnant of that patch in current EU::MM.
WTF ??
Cheers\, Rob
-----Original Message----- From: sisyphus1@optusnet.com.au
One problem (probably *the* problem) is that the gmake-style Makefile that EU::MM generates does not specify a SHELL.
For me\, the attached patch allows blead (as of last night) to build fine when sh.exe is in the path\, but *following* cmd.exe. I had to apply the patch in a fresh cloning of blead. For some reason running 'make distclean' was insufficient.
This patch (or something similar) is needed not just for building perl\, but for building modules after that perl has been installed.
I don't have any sympathy with anyone who would want to use the cmd.exe shell to build perl\, yet have sh.exe *precede* cmd.exe in the path - and I therefore haven't investigated that scenario. kmx's patch would certainly be needed\, though I suspect the required patching wouldn't stop there.
I'll ensure that sh.exe is in my path whenever I build future devel releases. (I invariably run my stable perls with sh.exe in the path - so this will matter to me when 5.24 is released.)
I'll re-open https://rt.cpan.org/Public/Bug/Display.html?id=101132 and see if I can find out why the fix is missing from EU-MM-7.10. Having to re-visit this is really annoying - though I guess I've only got myself to blame for not keeping C:\MinGW\msys\1.0\bin in my path.
Cheers\, Rob
And now ... the patch :-)
-----Original Message----- From: sisyphus1@optusnet.com.au Sent: Tuesday\, November 10\, 2015 12:48 PM To: Steve Hay ; bulk88 via RT Cc: perl5-porters@perl.org Subject: Re: [perl #123440] Adding win32/GNUmakefile
-----Original Message----- From: sisyphus1@optusnet.com.au
One problem (probably *the* problem) is that the gmake-style Makefile that EU::MM generates does not specify a SHELL.
For me\, the attached patch allows blead (as of last night) to build fine when sh.exe is in the path\, but *following* cmd.exe. I had to apply the patch in a fresh cloning of blead. For some reason running 'make distclean' was insufficient.
This patch (or something similar) is needed not just for building perl\, but for building modules after that perl has been installed.
I don't have any sympathy with anyone who would want to use the cmd.exe shell to build perl\, yet have sh.exe *precede* cmd.exe in the path - and I therefore haven't investigated that scenario. kmx's patch would certainly be needed\, though I suspect the required patching wouldn't stop there.
I'll ensure that sh.exe is in my path whenever I build future devel releases. (I invariably run my stable perls with sh.exe in the path - so this will matter to me when 5.24 is released.)
I'll re-open https://rt.cpan.org/Public/Bug/Display.html?id=101132 and see if I can find out why the fix is missing from EU-MM-7.10. Having to re-visit this is really annoying - though I guess I've only got myself to blame for not keeping C:\MinGW\msys\1.0\bin in my path.
Cheers\, Rob
On Mon Nov 09 15:09:14 2015\, sisyphus wrote:
-----Original Message----- From: sisyphus1@optusnet.com.au Sent: Monday\, November 09\, 2015 9:00 PM To: Steve Hay ; bulk88 via RT Cc: perl5-porters@perl.org Subject: Re: [perl #123440] Adding win32/GNUmakefile
But surely it should be allowable to have sh.exe in your path ? That's why the "SHELL := cmd.exe" entry was placed in GNUmakefile in the first place - and I'm sure that used to work. But I've just checked (for the first time in a while) whether I can build recent perl if I have sh.exe in the path\, and I can't !!
One problem (probably *the* problem) is that the gmake-style Makefile that EU::MM generates does not specify a SHELL. I don't know how or why that omission has come about.
Last December I opened an EU::MM ticket about this: https://rt.cpan.org/Public/Bug/Display.html?id=101132
I ultimately provided a patch that was accepted and applied to EU::MM master as https://github.com/Perl-Toolchain-Gang/ExtUtils- MakeMaker/commit/06aeb803cccb2643e1e1cd8edcbcaf966981e05c
The ticket was then closed\, but I don't see any remnant of that patch in current EU::MM.
WTF ??
TLDR: EUMM died\, along with 1-1.5 years of bug fixes in its repo this summer (for details see http://www.nntp.perl.org/group/perl.cpan.workers/2015/10/msg1320.html ).
I've extracted the patches from EUMM on GH master into blead in the attached 4 patches (it is really a branch).
The gmake build now builds to completion for me\, just 1 test fails for me with gmake Win32 perl above baseline (regular test failures on my box for months/years now).
C:\p523\src\win32>cd ..\t & perl harness -v ../cpan/ExtUtils-MakeMaker/t/echo. t & cd ..\win32 ../cpan/ExtUtils-MakeMaker/t/echo.t .. Use of uninitialized value in concatenati on (.) or string at C:\p523\src\lib/ExtUtils/MM_Win32.pm line 158.
# Testing simple echo # Temp dir: C:\Users\Owner\AppData\Local\Temp\jfnmo2RnpP ok 1 - make: simple echo ok 2 - bar.txt exists ok 3 - contents # Testing multiline echo # Temp dir: C:\Users\Owner\AppData\Local\Temp\Tde5mbFlFu ok 4 - make: multiline echo ok 5 - something.txt exists ok 6 - contents # Testing dollar signs escaped # Temp dir: C:\Users\Owner\AppData\Local\Temp\yrVeAmgSUu ok 7 - make: dollar signs escaped ok 8 - something.txt exists
not ok 9 - contents# Failed test 'contents'
# at t/echo.t line 69. # got: '$ # ' # expected: '$something$ # ' # Testing variables escaped # Temp dir: C:\Users\Owner\AppData\Local\Temp\k65aneG7OZ ok 10 - make: variables escaped ok 11 - something.txt exists # Failed test 'contents'
# at t/echo.t line 69. not ok 12 - contents # got: ' # ' # expected: '$(something) # ' # Testing allow_variables # Temp dir: C:\Users\Owner\AppData\Local\Temp\UfMlMWInIv ok 13 - make: allow_variables ok 14 - bar.txt exists ok 15 - contents # Testing append # Temp dir: C:\Users\Owner\AppData\Local\Temp\91EWAJpFI_ # Looks like you failed 2 tests of 18. ok 16 - make: append ok 17 - bar.txt exists ok 18 - contents 1..18 Dubious\, test returned 2 (wstat 512\, 0x200) Failed 2/18 subtests
Test Summary Report
../cpan/ExtUtils-MakeMaker/t/echo.t (Wstat: 512 Tests: 18 Failed: 2) Failed tests: 9\, 12 Non-zero exit status: 2 Files=1\, Tests=18\, 2 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU) Result: FAIL
C:\p523\src\win32>
This test fails with gmake both in the EUMM GH master branch\, and in my backport to blead branch. The reason it fails is the ultra tiny makefiles (not EUMM makefiles\, but handrolled ones) that are written by echo.t to disk do not include "SHELL =" anywhere\, and therefore are launching bash/sh.exe instead of cmd.exe and the "$"s have different escaping/quoting/whatever by bash vs cmd.exe. There is no fix in EUMM GH master for this so I am not writing a fix for a very small test fail today/tonight. I need gmake win32 perl to build in blead before I can try making GNUmakefile parallel friendly (which is why i resurrected this ticket since I couldn't get blead with gmake on win32 to build).
I've also attached a backported fix for "make -v" being called/shelled out dozens of times inside each Makefile.PL. I've attached a syscall log showing the excessive process launches.
-- bulk88 ~ bulk88 at hotmail.com
On Tue\, Nov 10\, 2015 at 12:08 AM\, \sisyphus1@​optusnet\.com\.au wrote:
-----Original Message----- From: sisyphus1@optusnet.com.au Sent: Monday\, November 09\, 2015 9:00 PM To: Steve Hay ; bulk88 via RT Cc: perl5-porters@perl.org Subject: Re: [perl #123440] Adding win32/GNUmakefile
But surely it should be allowable to have sh.exe in your path ? That's why the "SHELL := cmd.exe" entry was placed in GNUmakefile in the first place - and I'm sure that used to work. But I've just checked (for the first time in a while) whether I can build recent perl if I have sh.exe in the path\, and I can't !!
One problem (probably *the* problem) is that the gmake-style Makefile that EU::MM generates does not specify a SHELL. I don't know how or why that omission has come about.
Last December I opened an EU::MM ticket about this: https://rt.cpan.org/Public/Bug/Display.html?id=101132
I ultimately provided a patch that was accepted and applied to EU::MM master as
The ticket was then closed\, but I don't see any remnant of that patch in current EU::MM.
WTF ??
EUMM is currently in a weird state of limbo\, after 7.06 suffering from regressions and a revert had to be released. The issue was rather stalled for the past two months\, but I hope/think it will start moving again soon.
Leon
From: Leon Timmermans Sent: Tuesday\, November 10\, 2015 8:11 PM To: Sisyphus Cc: Steve Hay ; perlbug ; Perl5 Porters Subject: Re: [perl #123440] Adding win32/GNUmakefile
I ultimately provided a patch that was accepted and applied to EU::MM master as https://github.com/Perl-Toolchain-Gang/ExtUtils-MakeMaker/commit/06aeb803cccb2643e1e1cd8edcbcaf966981e05c
The ticket was then closed\, but I don't see any remnant of that patch in current EU::MM.
WTF ??
EUMM is currently in a weird state of limbo\, after 7.06 suffering from regressions and a revert had to be released. The issue was rather stalled for the past two months\, but I hope/think it will start moving again soon.
I now remember seeing notices about that reversion - but I'm too dim to have appreciated the extent of the impact it would have\, and promptly forgot about it.
Thanks for the explanation.
Cheers\, Rob
Just a reminder that the problem still remains as of the release of perl-5.23.5. That is\, perl-5.23.5 will not build on Windows using gmake if sh.exe is in the path.
Cheers\, Rob
-----Original Message----- From: sisyphus1@optusnet.com.au Sent: Monday\, November 23\, 2015 3:40 PM Subject: Re: [perl #123440] Adding win32/GNUmakefile Just a reminder that the problem still remains as of the release of perl-5.23.5. That is\, perl-5.23.5 will not build on Windows using gmake if sh.exe is in the path.
Still the same brokenness in perl-5.23.6 (released on 21 Dec).
Cheers\, Rob
-----Original Message----- From: sisyphus1@optusnet.com.au Subject: Re: [perl #123440] Adding win32/GNUmakefile
Just a reminder that the problem still remains as of the release of perl-5.23.5. That is\, perl-5.23.5 will not build on Windows using gmake if sh.exe is in the path.
Still the same brokenness in perl-5.23.6 (released on 21 Dec).
Still broken in 5.23.7.
Cheers\, Rob
On Wed Jan 20 21:00:11 2016\, sisyphus wrote:
-----Original Message----- From: sisyphus1@optusnet.com.au Subject: Re: [perl #123440] Adding win32/GNUmakefile
Just a reminder that the problem still remains as of the release of perl-5.23.5. That is\, perl-5.23.5 will not build on Windows using gmake if sh.exe is in the path.
Still the same brokenness in perl-5.23.6 (released on 21 Dec).
Still broken in 5.23.7.
Cheers\, Rob
My gmake parallel branch https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126632 which has the .SHELL fix for gmake still hasn't been applied. It is a forgone conclusion TonyC will apply it since no other active committer touches Win32 code. So take it up with TonyC or rjbs why it is still broken.
-- bulk88 ~ bulk88 at hotmail.com
-----Original Message----- From: bulk88 via RT Sent: Saturday\, January 23\, 2016 7:02 AM To: OtherRecipients of perl Ticket #123440: Cc: perl5-porters@perl.org Subject: [perl #123440] Adding win32/GNUmakefile
My gmake parallel branch https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126632 which has the .SHELL fix for gmake still hasn't been applied. It is a forgone conclusion TonyC will apply it since no other active committer touches Win32 code. So take it up with TonyC or rjbs why it is still broken.
It's not such a big issue for me that it hasn't been fixed yet - so long as it's fixed in 5.24.
Seems that TonyC has just today applied your #126632 fixes - so that should shut me up :-) Thanks to both of you for your continued efforts.
Cheers\, Rob
Thank you for submitting this report. You have helped make Perl better.
With the release of Perl 5.24.0 on May 9\, 2016\, this and 149 other issues have been resolved.
Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0
@khwilliamson - Status changed from 'pending release' to 'resolved'
Migrated from rt.perl.org#123440 (status was 'resolved')
Searchable as RT123440$