Skip Menu |
Report information
Id: 123440
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: kmxx <kmx [at] volny.cz>
Cc:
AdminCc:

Operating System: mswin32
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.20.1
Fixed In: (no value)



Date: Tue, 16 Dec 2014 09:49:36 +0100
From: kmx <kmx [...] volny.cz>
To: perlbug [...] perl.org
Subject: Adding win32/GNUmakefile
This is a bug report for perl from kmx@atlas.cz,
generated with the help of perlbug 1.40 running under perl 5.20.1.


-----------------------------------------------------------------
[Please describe your issue here]

With ExtUtils::MakeMaker v7 there is an option to use GNU make on
MS Windows instead of traditional dmake.

I would like to ask for opinions about an idea of creating a new
win32/GNUmakefile which will support building perl core on MS Windows
with GNU make + gcc

If you find it a good idea I am ready to do the work.

Thanks

--
kmx

[Please do not change anything below this line]
-----------------------------------------------------------------
---
Flags:
    category=core
    severity=low
---
Site configuration information for perl 5.20.1:

Configured by strawberry-perl at Mon Sep 15 13:28:28 2014.

Summary of my perl5 (revision 5 version 20 subversion 1) configuration:
   
  Platform:
    osname=MSWin32, osvers=6.3, archname=MSWin32-x64-multi-thread
    uname='Win32 strawberry-perl 5.20.1.1 #1 Mon Sep 15 13:26:45 2014 x64'
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    useithreads=define, usemultiplicity=define
    use64bitint=define, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags =' -s -O2 -DWIN32 -DWIN64 -DCONSERVATIVE  -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -fwrapv -fno-strict-aliasing -mms-bitfields',
    optimize='-s -O2',
    cppflags='-DWIN32'
    ccversion='', gccversion='4.8.3', gccosandvers=''
    intsize=4, longsize=4, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++.exe', ldflags ='-s -L"C:\tmp64\perl\lib\CORE" -L"C:\tmp64\c\lib"'
    libpth=C:\tmp64\c\lib C:\tmp64\c\x86_64-w64-mingw32\lib C:\tmp64\c\lib\gcc\x86_64-w64-mingw32\4.8.3
    libs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    perllibs=-lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32 -lcomctl32
    libc=, so=dll, useshrplib=true, libperl=libperl520.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=xs.dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-mdll -s -L"C:\tmp64\perl\lib\CORE" -L"C:\tmp64\c\lib"'


---
@INC for perl 5.20.1:
    C:/tmp64/perl/site/lib
    C:/tmp64/perl/vendor/lib
    C:/tmp64/perl/lib
    .

---
Environment for perl 5.20.1:
    HOME=C:\tmp64\data
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\tmp64\perl\site\bin;C:\tmp64\perl\bin;C:\tmp64\c\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
    PERL_BADLANG (unset)
    SHELL (unset)

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.7k
On Tue Dec 16 00:49:53 2014, kmxx wrote: Show quoted text
> This is a bug report for perl from kmx@atlas.cz, > generated with the help of perlbug 1.40 running under perl 5.20.1. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > With ExtUtils::MakeMaker v7 there is an option to use GNU make on > MS Windows instead of traditional dmake. > > I would like to ask for opinions about an idea of creating a new > win32/GNUmakefile which will support building perl core on MS Windows > with GNU make + gcc > > If you find it a good idea I am ready to do the work. >
Sounds like a good idea to me, except for slight concerns over maintenance troubles. We already have two makefiles (three if you count WinCE) in win32/, which often both need to have similar patches applied. Would you envisage adding a third flavour to the mix, or *replacing* the dmake makefile.mk with your new GNUmakefile? The latter would be preferable from a maintenance viewpoint, but I don't know how many people would be inconvenienced by dropping dmake. Probably not a huge number since it's fairly obscure and GNU make is readily available anyway. If there was any way to have some means of (re)generating the two makefiles from some common code (I'm thinking of a "regen" step that porters can run when making changes to makefiles; perl distros would still be shipped with both versions in them) then that would be great (and conceivably we could then even keep on dmake support since it *might* not be such an extra overhead). I've always wanted to have a look at doing this, but I've never found the time. If this was part of your plan then that would be awesome; if not then it's not a problem if we end up with two makefiles like we have now -- the "regen" idea can still be done sometime in the future.
Date: Tue, 16 Dec 2014 10:39:49 +0100
Subject: Re: [perl #123440] Adding win32/GNUmakefile
From: kmx <kmx [...] atlas.cz>
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.2k
On 16.12.2014 10:23, Steve Hay via RT wrote: Show quoted text
> On Tue Dec 16 00:49:53 2014, kmxx wrote:
>> This is a bug report for perl from kmx@atlas.cz, >> generated with the help of perlbug 1.40 running under perl 5.20.1. >> >> >> ----------------------------------------------------------------- >> [Please describe your issue here] >> >> With ExtUtils::MakeMaker v7 there is an option to use GNU make on >> MS Windows instead of traditional dmake. >> >> I would like to ask for opinions about an idea of creating a new >> win32/GNUmakefile which will support building perl core on MS Windows >> with GNU make + gcc >> >> If you find it a good idea I am ready to do the work. >>
> Sounds like a good idea to me, except for slight concerns over maintenance troubles. We already have two makefiles (three if you count WinCE) in win32/, which often both need to have similar patches applied. Would you envisage adding a third flavour to the mix, or *replacing* the dmake makefile.mk with your new GNUmakefile? > > The latter would be preferable from a maintenance viewpoint, but I don't know how many people would be inconvenienced by dropping dmake. Probably not a huge number since it's fairly obscure and GNU make is readily available anyway. > > If there was any way to have some means of (re)generating the two makefiles from some common code (I'm thinking of a "regen" step that porters can run when making changes to makefiles; perl distros would still be shipped with both versions in them) then that would be great (and conceivably we could then even keep on dmake support since it *might* not be such an extra overhead). I've always wanted to have a look at doing this, but I've never found the time. If this was part of your plan then that would be awesome; if not then it's not a problem if we end up with two makefiles like we have now -- the "regen" idea can still be done sometime in the future.
My suggestion is to: 1/ have both GNUmakefile + makefile.mk in 5.22 (May 2015) 2/ (maybe) drop makefile.mk in 5.24 (May 2016) The other thing is that makefile.mk supports also msvc whereas my plan for GNUmakefile is to support gcc only. I am not sure if I can say something about "regen" idea. Maybe let's first have "some" GNUmakefile then we can analyse if some parts may be generated or not. -- kmx
From: Steve Hay <steve.m.hay [...] googlemail.com>
To: kmx <kmx [...] atlas.cz>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Date: Tue, 16 Dec 2014 12:57:29 +0000
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 3.1k
On 16 December 2014 at 09:39, kmx <kmx@atlas.cz> wrote: Show quoted text
> > On 16.12.2014 10:23, Steve Hay via RT wrote:
>> >> On Tue Dec 16 00:49:53 2014, kmxx wrote:
>>> >>> This is a bug report for perl from kmx@atlas.cz, >>> generated with the help of perlbug 1.40 running under perl 5.20.1. >>> >>> >>> ----------------------------------------------------------------- >>> [Please describe your issue here] >>> >>> With ExtUtils::MakeMaker v7 there is an option to use GNU make on >>> MS Windows instead of traditional dmake. >>> >>> I would like to ask for opinions about an idea of creating a new >>> win32/GNUmakefile which will support building perl core on MS Windows >>> with GNU make + gcc >>> >>> If you find it a good idea I am ready to do the work. >>>
>> Sounds like a good idea to me, except for slight concerns over maintenance >> troubles. We already have two makefiles (three if you count WinCE) in >> win32/, which often both need to have similar patches applied. Would you >> envisage adding a third flavour to the mix, or *replacing* the dmake >> makefile.mk with your new GNUmakefile? >> >> The latter would be preferable from a maintenance viewpoint, but I don't >> know how many people would be inconvenienced by dropping dmake. Probably not >> a huge number since it's fairly obscure and GNU make is readily available >> anyway. >> >> If there was any way to have some means of (re)generating the two >> makefiles from some common code (I'm thinking of a "regen" step that porters >> can run when making changes to makefiles; perl distros would still be >> shipped with both versions in them) then that would be great (and >> conceivably we could then even keep on dmake support since it *might* not be >> such an extra overhead). I've always wanted to have a look at doing this, >> but I've never found the time. If this was part of your plan then that would >> be awesome; if not then it's not a problem if we end up with two makefiles >> like we have now -- the "regen" idea can still be done sometime in the >> future.
> > > My suggestion is to: > 1/ have both GNUmakefile + makefile.mk in 5.22 (May 2015) > 2/ (maybe) drop makefile.mk in 5.24 (May 2016)
Ok, sounds reasonable to me. It means that we'll have three makefiles to maintain for a while, but it won't be for too long. Show quoted text
> > The other thing is that makefile.mk supports also msvc whereas my plan for > GNUmakefile is to support gcc only.
I think that's reasonable too. Unless we ever switch over to GNU make entirely and drop nmake support (which I don't see happening any time soon, if at all, since nmake is the obvious choice for VC++ users) then there's little point in GNUmakefile also supporting VC++. In theory it might occasionally be useful to try a VC++ build with a different make tool in case of some suspected problem with nmake, but in practice I can't think of an occasion that I've ever done that with the existing dmake makefile.mk. I've only ever built using VC++/nmake and gcc/dmake. Show quoted text
> > I am not sure if I can say something about "regen" idea. Maybe let's first > have "some" GNUmakefile then we can analyse if some parts may be generated > or not.
Yes, creating a regen script will be much easier when we can see the GNUmakefile that we're trying to generate :-)
CC: "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Date: Tue, 16 Dec 2014 16:14:13 +0100
From: Leon Timmermans <fawaka [...] gmail.com>
To: Perl5 Porters <perl5-porters [...] perl.org>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 640b
Download (untitled) / with headers
text/html 1011b
On Tue, Dec 16, 2014 at 9:49 AM, kmx <perlbug-followup@perl.org> wrote: Show quoted text
With ExtUtils::MakeMaker v7 there is an option to use GNU make on
MS Windows instead of traditional dmake.

I would like to ask for opinions about an idea of creating a new
win32/GNUmakefile which will support building perl core on MS Windows
with GNU make + gcc

If you find it a good idea I am ready to do the work.

I had proposed just that in #121214. Given the state of dmake I'd prefer this happening yesterday. I suspect making it support both gcc and msvc would be feasable, given we already have the logic (it just needs translation).

Leon

 
Subject: Re: [perl #123440] Adding win32/GNUmakefile
From: Jan Dubois <jand [...] activestate.com>
To: Leon Timmermans <fawaka [...] gmail.com>
CC: Perl5 Porters <perl5-porters [...] perl.org>, "bugs-bitbucket [...] rt.perl.org" <bugs-bitbucket [...] rt.perl.org>
Date: Tue, 16 Dec 2014 11:08:04 -0800
Download (untitled) / with headers
text/plain 881b
On Tue, Dec 16, 2014 at 7:14 AM, Leon Timmermans <fawaka@gmail.com> wrote: Show quoted text
> On Tue, Dec 16, 2014 at 9:49 AM, kmx <perlbug-followup@perl.org> wrote:
>> >> I would like to ask for opinions about an idea of creating a new >> win32/GNUmakefile which will support building perl core on MS Windows >> with GNU make + gcc >>
> > I had proposed just that in #121214. Given the state of dmake I'd prefer > this happening yesterday.
+1 Show quoted text
> I suspect making it support both gcc and msvc > would be feasable, given we already have the logic (it just needs > translation).
Is there any benefit to it? I actually prefer to limit the variation in build tools, i.e. either use VC/nmake, or GCC/GNUmake for building Perl and modules. Supporting different make utilities with different compilers just adds complexities in modules down the toolchain with no obvious (to me) benefit. Cheers, -Jan
To: perl5-porters [...] perl.org
From: kmx <kmx [...] atlas.cz>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Date: Wed, 17 Dec 2014 16:07:31 +0100
Download (untitled) / with headers
text/plain 1.2k
On 16.12.2014 20:08, Jan Dubois wrote: Show quoted text
> On Tue, Dec 16, 2014 at 7:14 AM, Leon Timmermans <fawaka@gmail.com> wrote:
>> On Tue, Dec 16, 2014 at 9:49 AM, kmx <perlbug-followup@perl.org> wrote:
>>> I would like to ask for opinions about an idea of creating a new >>> win32/GNUmakefile which will support building perl core on MS Windows >>> with GNU make + gcc >>>
>> I had proposed just that in #121214. Given the state of dmake I'd prefer >> this happening yesterday.
> +1
Sorry, I should have done better research. These tickets can be merged. Show quoted text
>> I suspect making it support both gcc and msvc >> would be feasable, given we already have the logic (it just needs >> translation).
> Is there any benefit to it? I actually prefer to limit the variation > in build tools, i.e. either use VC/nmake, or GCC/GNUmake for building > Perl and modules. Supporting different make utilities with different > compilers just adds complexities in modules down the toolchain with no > obvious (to me) benefit.
I agree with keeping separate makefiles for 1/ VC+nmake and 2/ GCC+GNUmake. Here is the first version - https://gist.github.com/kmx/b5805847b6485c5c3a65 Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32 subdir. It seems to work but definitely needs thorough testing. -- kmx
Date: Thu, 18 Dec 2014 10:06:23 +1100
From: <sisyphus1 [...] optusnet.com.au>
To: "kmx" <kmx [...] atlas.cz>, <perl5-porters [...] perl.org>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 705b
Show quoted text
-----Original Message----- From: kmx Sent: Thursday, December 18, 2014 2:07 AM To: perl5-porters@perl.org Subject: Re: [perl #123440] Adding win32/GNUmakefile
> Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32 > subdir. > It seems to work but definitely needs thorough testing.
Nice !! I'll certainly be using this makefile to build 5.21.7 (and various perl extensions) when it comes out. I take it that the GNU make utility must be named 'gmake' - that using a GNU make utility of any other name (eg 'mingw32-make' or 'make') is disallowed. I think this should be spelled out clearly somewhere .... that is, of course, if it hasn't *already* been done :-) Cheers, Rob
CC: Perl5 Porters <perl5-porters [...] perl.org>
Date: Thu, 18 Dec 2014 00:13:55 +0100
Subject: Re: [perl #123440] Adding win32/GNUmakefile
To: kmx <kmx [...] atlas.cz>
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 368b
On Wed, Dec 17, 2014 at 4:07 PM, kmx <kmx@atlas.cz> wrote:
Show quoted text
Here is the first version - https://gist.github.com/kmx/b5805847b6485c5c3a65
Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32 subdir.
It seems to work but definitely needs thorough testing.

Line 323 is wrong (should be a ifneq), other than that it looks good to me.

Leon

Date: Wed, 17 Dec 2014 15:30:00 -0800
CC: kmx <kmx [...] atlas.cz>, Perl 5 Porters <perl5-porters [...] perl.org>
From: Jan Dubois <jand [...] activestate.com>
To: Sisyphus <sisyphus1 [...] optusnet.com.au>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 359b
On Wed, Dec 17, 2014 at 3:06 PM, <sisyphus1@optusnet.com.au> wrote: Show quoted text
> I take it that the GNU make utility must be named 'gmake' - that using a GNU > make utility of any other name (eg 'mingw32-make' or 'make') is disallowed.
I see that 'gmake' is hard-coded in one place, but replacing that with $(MAKE) should make it work for any name, no? Cheers, -Jan
Subject: Re: [perl #123440] Adding win32/GNUmakefile
To: Jan Dubois <jand [...] activestate.com>
From: Leon Timmermans <fawaka [...] gmail.com>
CC: Sisyphus <sisyphus1 [...] optusnet.com.au>, kmx <kmx [...] atlas.cz>, Perl 5 Porters <perl5-porters [...] perl.org>
Date: Thu, 18 Dec 2014 00:40:07 +0100
Download (untitled) / with headers
text/plain 606b
On Thu, Dec 18, 2014 at 12:30 AM, Jan Dubois <jand@activestate.com> wrote: Show quoted text
On Wed, Dec 17, 2014 at 3:06 PM,  <sisyphus1@optusnet.com.au> wrote:
> I take it that the GNU make utility must be named 'gmake' - that using a GNU
> make utility of any other name (eg 'mingw32-make' or 'make') is disallowed.

I see that 'gmake' is hard-coded in one place, but replacing that with
$(MAKE) should make it work for any name, no?

That's just the configuration value. It's telling MakeMaker what brand of make you're using (on Unix it's always "make"), but shouldn't be used otherwise AFAIK.

Leon
 
From: "Craig A. Berry" <craig.a.berry [...] gmail.com>
To: Leon Timmermans <fawaka [...] gmail.com>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Date: Wed, 17 Dec 2014 22:44:18 -0600
CC: Jan Dubois <jand [...] activestate.com>, Sisyphus <sisyphus1 [...] optusnet.com.au>, kmx <kmx [...] atlas.cz>, Perl 5 Porters <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1019b
On Wed, Dec 17, 2014 at 5:40 PM, Leon Timmermans <fawaka@gmail.com> wrote: Show quoted text
> On Thu, Dec 18, 2014 at 12:30 AM, Jan Dubois <jand@activestate.com> wrote:
>> >> On Wed, Dec 17, 2014 at 3:06 PM, <sisyphus1@optusnet.com.au> wrote:
>> > I take it that the GNU make utility must be named 'gmake' - that using a >> > GNU >> > make utility of any other name (eg 'mingw32-make' or 'make') is >> > disallowed.
>> >> I see that 'gmake' is hard-coded in one place, but replacing that with >> $(MAKE) should make it work for any name, no?
> > > That's just the configuration value. It's telling MakeMaker what brand of > make you're using (on Unix it's always "make"), but shouldn't be used > otherwise AFAIK.
It looks to me like $(MAKE) is a built-in variable and will expand to whatever make you're actually running: $ make -p | grep MAKE_COMMAND make: *** No targets specified and no makefile found. Stop. MAKE = $(MAKE_COMMAND) MAKE_COMMAND := /Applications/Xcode.app/Contents/Developer/usr/bin/make That's GNU make 3.81.
CC: Leon Timmermans <fawaka [...] gmail.com>, Sisyphus <sisyphus1 [...] optusnet.com.au>, kmx <kmx [...] atlas.cz>, Perl 5 Porters <perl5-porters [...] perl.org>
Date: Wed, 17 Dec 2014 21:38:31 -0800
To: "Craig A. Berry" <craig.a.berry [...] gmail.com>
From: Jan Dubois <jand [...] activestate.com>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 652b
On Wed, Dec 17, 2014 at 8:44 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote: Show quoted text
> > It looks to me like $(MAKE) is a built-in variable and will expand to > whatever make you're actually running:
Yes, it is make's equivalent of perl's $^X. I misunderstood the issue; I assumed the problem was that the top-level Makefile needed to pass the name of the make utility to $Config{make}, and thought $(MAKE) would be a way to do this. Maybe this is still the issue, and the value is hard-coded in some other place. I've only searched kmx's gist for occurances of 'gmake', and that was the only one I spotted; I haven't looked any deeper. Cheers, -Jan
Date: Thu, 18 Dec 2014 08:21:33 +0100
Subject: Re: [perl #123440] Adding win32/GNUmakefile
From: kmx <kmx [...] volny.cz>
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 527b
On 18.12.2014 0:14, Leon Timmermans via RT wrote: Show quoted text
> On Wed, Dec 17, 2014 at 4:07 PM, kmx <kmx@atlas.cz> wrote: >
>> Here is the first version - >> https://gist.github.com/kmx/b5805847b6485c5c3a65 >> Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32 >> subdir. >> It seems to work but definitely needs thorough testing. >>
> Line 323 is wrong (should be a ifneq), other than that it looks good to me.
You are right, fixed. https://gist.github.com/kmx/b5805847b6485c5c3a65#file-gnumakefile-L323 -- kmx
Subject: Re: [perl #123440] Adding win32/GNUmakefile
To: perlbug-followup [...] perl.org
From: kmx <kmx [...] volny.cz>
Date: Thu, 18 Dec 2014 08:32:49 +0100
Download (untitled) / with headers
text/plain 1.1k
On 18.12.2014 6:39, Jan Dubois via RT wrote: Show quoted text
> On Wed, Dec 17, 2014 at 8:44 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote:
>> It looks to me like $(MAKE) is a built-in variable and will expand to >> whatever make you're actually running:
> Yes, it is make's equivalent of perl's $^X. > > I misunderstood the issue; I assumed the problem was that the > top-level Makefile needed to pass the name of the make utility to > $Config{make}, and thought $(MAKE) would be a way to do this. Maybe > this is still the issue, and the value is hard-coded in some other > place. I've only searched kmx's gist for occurances of 'gmake', and > that was the only one I spotted; I haven't looked any deeper.
I have changed it to $(MAKE) https://gist.github.com/kmx/b5805847b6485c5c3a65#file-gnumakefile-L691 Yes, it is used for setting $Config{make} value, it overrides predefined "make='dmake'" line from win32\config.gc. The only downside of using $(MAKE) is that it might happen that absolute path to gmake.exe is stored in $Config{make}. Other thing I am not sure about is whether the GNUmakefile is correctly using recursively expanded (= assignment) and simply expanded variables (:= assignment). -- kmx
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 702b
On Tue Dec 16 00:49:53 2014, kmxx wrote: Show quoted text
> This is a bug report for perl from kmx@atlas.cz, > generated with the help of perlbug 1.40 running under perl 5.20.1. > > > ----------------------------------------------------------------- > [Please describe your issue here] > > With ExtUtils::MakeMaker v7 there is an option to use GNU make on > MS Windows instead of traditional dmake. > > I would like to ask for opinions about an idea of creating a new > win32/GNUmakefile which will support building perl core on MS Windows > with GNU make + gcc
I dont like the name "GNUmakefile". Too much to type. Can it please be all lowercase or "makefile.g" or "gmakefile"? -- bulk88 ~ bulk88 at hotmail.com
CC: Perl5 Porters <perl5-porters [...] perl.org>
Date: Thu, 18 Dec 2014 23:10:23 +0100
From: Leon Timmermans <fawaka [...] gmail.com>
To: Father Chrysostomos via RT <perlbug-followup [...] perl.org>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 296b
On Thu, Dec 18, 2014 at 11:06 PM, bulk88 via RT <perlbug-followup@perl.org> wrote: Show quoted text
I dont like the name "GNUmakefile". Too much to type. Can it please be all lowercase or "makefile.g" or "gmakefile"?

It's a GNUism. GNU make will try to run GNUmakefile before makefile or Makefile.

Leon

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 436b
On Thu Dec 18 14:11:20 2014, LeonT wrote: Show quoted text
> On Thu, Dec 18, 2014 at 11:06 PM, bulk88 via RT <perlbug-followup@perl.org> > wrote:
> > > > I dont like the name "GNUmakefile". Too much to type. Can it please be all > > lowercase or "makefile.g" or "gmakefile"? > >
> > It's a GNUism. GNU make will try to run GNUmakefile before makefile or > Makefile. > > Leon
NVM then. It is less typing, much less. -- bulk88 ~ bulk88 at hotmail.com
Date: Fri, 19 Dec 2014 00:00:58 +0100
Subject: Re: [perl #123440] Adding win32/GNUmakefile
To: perl5-porters [...] perl.org
From: kmx <kmx [...] atlas.cz>
Download (untitled) / with headers
text/plain 519b

On 18.12.2014 23:10, Leon Timmermans wrote:
Show quoted text
On Thu, Dec 18, 2014 at 11:06 PM, bulk88 via RT <perlbug-followup@perl.org> wrote:
I dont like the name "GNUmakefile". Too much to type. Can it please be all lowercase or "makefile.g" or "gmakefile"?

It's a GNUism. GNU make will try to run GNUmakefile before makefile or Makefile.

Exactly, here is the relevant GNU make doc part:

https://www.gnu.org/software/make/manual/html_node/Makefile-Names.html

--
kmx
To: "kmx" <kmx [...] atlas.cz>, <perl5-porters [...] perl.org>
From: <sisyphus1 [...] optusnet.com.au>
Date: Sun, 21 Dec 2014 15:01:39 +1100
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 997b
Show quoted text
-----Original Message----- From: kmx Sent: Thursday, December 18, 2014 2:07 AM To: perl5-porters@perl.org Subject: Re: [perl #123440] Adding win32/GNUmakefile
> Here is the first version - > https://gist.github.com/kmx/b5805847b6485c5c3a65 > Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32 > subdir.
Sorry for the dumb question, but how does one get a usable copy of that file ? I first tried copy'n'paste from the IE8 browser window, but that wants to make every second line a blank line (which buggers up "\" line continuations). So I fired up Ubuntu and copy'n'pasted from the FF browser window, but that fails to reproduce leading tabs which also makes the file nonsensical in the eyes of gmake. Is there a direct link to the file ? (I tried "saving target as" from the kmx directory, but that just gave me the whole lot - html and all.) I guess there's some simple procedure for grabbing it .... if not, then I think there needs to be ;-) Cheers, Rob
To: sisyphus1 [...] optusnet.com.au, perl5-porters [...] perl.org
From: kmx <kmx [...] atlas.cz>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Date: Sun, 21 Dec 2014 10:57:49 +0100
Download (untitled) / with headers
text/plain 1.4k
On 21.12.2014 5:01, sisyphus1@optusnet.com.au wrote: Show quoted text
> -----Original Message----- From: kmx > Sent: Thursday, December 18, 2014 2:07 AM > To: perl5-porters@perl.org > Subject: Re: [perl #123440] Adding win32/GNUmakefile > >
>> Here is the first version - >> https://gist.github.com/kmx/b5805847b6485c5c3a65 >> Just save it as perl-src-dir/win32/GNUmakefile and run gmake from win32 >> subdir.
> > Sorry for the dumb question, but how does one get a usable copy of that > file ? > I first tried copy'n'paste from the IE8 browser window, but that wants to > make every second line a blank line (which buggers up "\" line > continuations). > So I fired up Ubuntu and copy'n'pasted from the FF browser window, but > that fails to reproduce leading tabs which also makes the file > nonsensical in the eyes of gmake. > > Is there a direct link to the file ? > (I tried "saving target as" from the kmx directory, but that just gave me > the whole lot - html and all.) > > I guess there's some simple procedure for grabbing it .... if not, then I > think there needs to be ;-)
Click "Raw" button or go to: https://gist.githubusercontent.com/kmx/b5805847b6485c5c3a65/raw/c8d64aa2c4b51edb6b47a5a1023976d04eda91e4/GNUmakefile then "save as" should work (perhaps use something else than IE as IE converts newlines to CRLF) Or try "Download Gist" button or go to: https://gist.github.com/kmx/b5805847b6485c5c3a65/download then extract the file from downloaded tarball -- kmx
Date: Fri, 26 Dec 2014 13:58:46 +1100
Subject: Re: [perl #123440] Adding win32/GNUmakefile
From: <sisyphus1 [...] optusnet.com.au>
To: "kmx" <kmx [...] atlas.cz>, <perl5-porters [...] perl.org>
Download (untitled) / with headers
text/plain 1.7k
Hi, (cc'ing p5p again) In an offlist discussion, we found that gmake will use sh.exe if it's found anywhere in the path - and this results in failure. This will happen if (eg) msys or Cygwin are in the path. It's apparently a feature of gmake, and kmx dug up this link: https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html As regards the implication of this for EU::MM, I've submitted: https://rt.cpan.org/Ticket/Display.html?id=101132 But it also has implications for the building of perl itself - and I propose (something like) the attached patch to the GNUmakefile that kmx posted at the start of this thread (at https://gist.github.com/kmx/b5805847b6485c5c3a65). There was already a (commented out) SHELL entry in that GNUmakefile, so I changed that to specify: SHELL := cmd.exe However, I then found it necessary to move it to the beginning of the GNUmakefile. Leaving it where it was worked ok, but resulted in some confusing output at the start (iff sh.exe was in the path): C:\_32\comp\perl-5.21.7\win32>gmake /usr/bin/sh: -c: line 0: syntax error near unexpected token `"delims=. tokens=1,2,3"' /usr/bin/sh: -c: line 0: `for /f "delims=. tokens=1,2,3" %%i in ('gcc -dumpversion') do echo %%i' /usr/bin/sh: -c: line 0: syntax error near unexpected token `"delims=. tokens=1,2,3"' /usr/bin/sh: -c: line 0: `for /f "delims=. tokens=1,2,3" %%i in ('gcc -dumpversion') do echo %%j' /usr/bin/sh: -c: line 0: syntax error near unexpected token `"delims=. tokens=1,2,3"' /usr/bin/sh: -c: line 0: `for /f "delims=. tokens=1,2,3" %%i in ('gcc -dumpversion') do echo %%k' # GCCBIN=gcc [all fine from then until the building of Archive::Tar - which fails iff sh.exe is in PATH && EU::MM has not been corrected] Cheers, Rob
Download gmake.diff.txt
text/plain 775b

Message body is not shown because sender requested not to inline it.

Subject: Re: [perl #123440] Adding win32/GNUmakefile
From: kmx <kmx [...] atlas.cz>
To: Perl 5 Porters <perl5-porters [...] perl.org>
Date: Fri, 26 Dec 2014 07:28:27 +0100
Download (untitled) / with headers
text/plain 1.9k
On 26.12.2014 3:58, sisyphus1@optusnet.com.au wrote: Show quoted text
> Hi, > > (cc'ing p5p again) > > In an offlist discussion, we found that gmake will use sh.exe if it's > found anywhere in the path - and this results in failure. > This will happen if (eg) msys or Cygwin are in the path. > > It's apparently a feature of gmake, and kmx dug up this link: > https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html > > As regards the implication of this for EU::MM, I've submitted: > https://rt.cpan.org/Ticket/Display.html?id=101132 > > But it also has implications for the building of perl itself - and I > propose (something like) the attached patch to the GNUmakefile that kmx > posted at the start of this thread (at > https://gist.github.com/kmx/b5805847b6485c5c3a65). > > There was already a (commented out) SHELL entry in that GNUmakefile, so > I changed that to specify: > SHELL := cmd.exe > > However, I then found it necessary to move it to the beginning of the > GNUmakefile. Leaving it where it was worked ok, but resulted in some > confusing output at the start (iff sh.exe was in the path): > > C:\_32\comp\perl-5.21.7\win32>gmake > /usr/bin/sh: -c: line 0: syntax error near unexpected token `"delims=. > tokens=1,2,3"' > /usr/bin/sh: -c: line 0: `for /f "delims=. tokens=1,2,3" %%i in ('gcc > -dumpversion') do echo %%i' > /usr/bin/sh: -c: line 0: syntax error near unexpected token `"delims=. > tokens=1,2,3"' > /usr/bin/sh: -c: line 0: `for /f "delims=. tokens=1,2,3" %%i in ('gcc > -dumpversion') do echo %%j' > /usr/bin/sh: -c: line 0: syntax error near unexpected token `"delims=. > tokens=1,2,3"' > /usr/bin/sh: -c: line 0: `for /f "delims=. tokens=1,2,3" %%i in ('gcc > -dumpversion') do echo %%k' > # GCCBIN=gcc > [all fine from then until the building of Archive::Tar - which fails iff > sh.exe is in PATH && EU::MM has not been corrected] > > Cheers, > Rob
I have updated my gist with Rob's patch -- kmx
From: kmx <kmx [...] atlas.cz>
Date: Wed, 04 Mar 2015 10:31:50 +0100
To: perl5-porters [...] perl.org
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Any chance to have win32/GNUmakefile in 5.22?

--
kmx
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 501b
On Tue Dec 16 11:08:31 2014, jdb wrote: Show quoted text
> Is there any benefit to it? I actually prefer to limit the variation > in build tools, i.e. either use VC/nmake, or GCC/GNUmake for building > Perl and modules. Supporting different make utilities with different > compilers just adds complexities in modules down the toolchain with no > obvious (to me) benefit.
gmake can do parallel builds. nmake can't. Given bulk88's work in #123867 it would be nice if we had a way to do parallel builds for MSVC. Tony
RT-Send-CC: perl5-porters [...] perl.org
On Sun May 24 23:07:07 2015, tonyc wrote: Show quoted text
> On Tue Dec 16 11:08:31 2014, jdb wrote:
> > Is there any benefit to it? I actually prefer to limit the variation > > in build tools, i.e. either use VC/nmake, or GCC/GNUmake for building > > Perl and modules. Supporting different make utilities with different > > compilers just adds complexities in modules down the toolchain with no > > obvious (to me) benefit.
> > gmake can do parallel builds. nmake can't. > > Given bulk88's work in #123867 it would be nice if we had a way to do > parallel builds for MSVC. > > Tony
I think the best plan is to get a non-parallel gnu makefile into the repo for 5.23, and Ill try to modify it the same way as the parallel dmake makefile. long part: The architecture (dep tree, order of operations, what each target makes) of the dmake parallel makefile is wildly different from regular dmake makefile. I dont think that gnu makefile will run in parallel as written on gist. config.h target would be broken which means no miniperl. all : info .\config.h ..\git_version.h $(GLOBEXE) $(MINIPERL) \ $(CONFIGPM) $(UNIDATAFILES) MakePPPort \ $(PERLEXE) Extensions Extensions_nonxs $(PERLSTATIC) For example, ..\git_version.h deps on miniperl, so why have $(MINIPERL) as a dep in target all? The gnu makefile makes as much sense as the non parallel dmake makefile today (little) which it is based off of. I think the best plan is to get a non-parallel gnu makefile into the repo for 5.23, and Ill try to modify it the same way as the parallel dmake makefile. My parallel dmake makefile builds Extensions and Extensions_nonxs in parallel. In the legacy dmake (and nmake) makefile, Extensions deps on DynaLoader which deps on Extensions_nonxs so there is nothing to do in parallel since its specifically coded to be serial. You can't get perl522.dll without running the very long (relatively) Extensions_nonxs target to allow the DynaLoader target to run. I fixed that in parallel dmake file. There are just so many many flaws in the existing makefiles. The build process in my parallel makefile is NO_Perl_interp_available(non Perl C programs and win32 batch lang 1 liners) ->raw_miniperl_available(aka buildcustomize.pl) -> Category:no Config.pm needed targets there is like 1 or 2 of these I dont remember them off my head Category:Config.pm needed XS headers/ppport.h needed Dynaloader static_exts DLL_extensions PP_extensions fullperl core .c files utils & pod linking miniperl and generating Config.pm are the main serialized/choke points, since the moment Config.pm is created there is an explosion of work available to do in parallel. The next performance problem is targets that take orders of magnitude different times to build (av.c takes less than 1/2 second, but it is built in parallel with DynaLoader which takes 5 seconds to build, limiting perl522.dll linking target to 5 seconds. Most of the 5 second delay is how slow EUMM is in generating a Makefile.PL, and EUMM doing "%EUMMConfig =%Config" which means that tied %Config lazy FETCH feature is useless because of what EUMM does. -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
On Sun May 24 23:07:07 2015, tonyc wrote: Show quoted text
> On Tue Dec 16 11:08:31 2014, jdb wrote:
> > Is there any benefit to it? I actually prefer to limit the variation > > in build tools, i.e. either use VC/nmake, or GCC/GNUmake for building > > Perl and modules. Supporting different make utilities with different > > compilers just adds complexities in modules down the toolchain with no > > obvious (to me) benefit.
> > gmake can do parallel builds. nmake can't. > > Given bulk88's work in #123867 it would be nice if we had a way to do > parallel builds for MSVC. > > Tony
I think the best plan is to get a non-parallel gnu makefile into the repo for 5.23, and Ill try to modify it the same way as the parallel dmake makefile. long part: The architecture (dep tree, order of operations, what each target makes) of the dmake parallel makefile is wildly different from regular dmake makefile. I dont think that gnu makefile will run in parallel as written on gist. config.h target would be broken which means no miniperl. all : info .\config.h ..\git_version.h $(GLOBEXE) $(MINIPERL) \ $(CONFIGPM) $(UNIDATAFILES) MakePPPort \ $(PERLEXE) Extensions Extensions_nonxs $(PERLSTATIC) For example, ..\git_version.h deps on miniperl, so why have $(MINIPERL) as a dep in target all? The gnu makefile makes as much sense as the non parallel dmake makefile today (little) which it is based off of. I think the best plan is to get a non-parallel gnu makefile into the repo for 5.23, and Ill try to modify it the same way as the parallel dmake makefile. My parallel dmake makefile builds Extensions and Extensions_nonxs in parallel. In the legacy dmake (and nmake) makefile, Extensions deps on DynaLoader which deps on Extensions_nonxs so there is nothing to do in parallel since its specifically coded to be serial. You can't get perl522.dll without running the very long (relatively) Extensions_nonxs target to allow the DynaLoader target to run. I fixed that in parallel dmake file. There are just so many many flaws in the existing makefiles. The build process in my parallel makefile is NO_Perl_interp_available(non Perl C programs and win32 batch lang 1 liners) ->raw_miniperl_available(aka buildcustomize.pl) -> Category:no Config.pm needed targets there is like 1 or 2 of these I dont remember them off my head Category:Config.pm needed XS headers/ppport.h needed Dynaloader static_exts DLL_extensions PP_extensions fullperl core .c files utils & pod linking miniperl and generating Config.pm are the main serialized/choke points, since the moment Config.pm is created there is an explosion of work available to do in parallel. The next performance problem is targets that take orders of magnitude different times to build (av.c takes less than 1/2 second, but it is built in parallel with DynaLoader which takes 5 seconds to build, limiting perl522.dll linking target to 5 seconds. Most of the 5 second delay is how slow EUMM is in generating a Makefile.PL, and EUMM doing "%EUMMConfig =%Config" which means that tied %Config lazy FETCH feature is useless because of what EUMM does. -- bulk88 ~ bulk88 at hotmail.com
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 911b
On Mon May 25 09:37:28 2015, bulk88 wrote: Show quoted text
> On Sun May 24 23:07:07 2015, tonyc wrote:
> > On Tue Dec 16 11:08:31 2014, jdb wrote:
> > > Is there any benefit to it? I actually prefer to limit the > > > variation > > > in build tools, i.e. either use VC/nmake, or GCC/GNUmake for > > > building > > > Perl and modules. Supporting different make utilities with > > > different > > > compilers just adds complexities in modules down the toolchain with > > > no > > > obvious (to me) benefit.
> > > > gmake can do parallel builds. nmake can't. > > > > Given bulk88's work in #123867 it would be nice if we had a way to do > > parallel builds for MSVC. > > > > Tony
> > > I think the best plan is to get a non-parallel gnu makefile into the > repo for 5.23, and Ill try to modify it the same way as the parallel > dmake makefile.
Here's patches for the the original file, and backported updates from blead. Tony
Subject: 0001-kmx-s-original-GNUmakefile.patch

Message body is not shown because it is too large.

Subject: 0002-update-to-5.22.0-and-update-with-changes-from-the-ot.patch
From 5b808537142bce731ef8abbd0b8fa1d81978463c Mon Sep 17 00:00:00 2001 From: Tony Cook <tony@develop-help.com> Date: Tue, 26 May 2015 11:54:23 +1000 Subject: [PATCH 2/2] update to 5.22.0 and update with changes from the other makefiles --- win32/GNUmakefile | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/win32/GNUmakefile b/win32/GNUmakefile index 928672c..3335a99 100644 --- a/win32/GNUmakefile +++ b/win32/GNUmakefile @@ -2,7 +2,7 @@ # Makefile to build perl on Windows using GNU make + gcc + MinGW. # # This is set up to build a perl.exe that runs off a shared library -# (perl521.dll). Also makes individual DLLs for the XS extensions. +# (perl522.dll). Also makes individual DLLs for the XS extensions. # # The easiest way to customize the build process is to use parameters like this: # @@ -66,7 +66,7 @@ INST_TOP := $(INST_DRV)\perl # versioned installation can be obtained by setting INST_TOP above to a # path that includes an arbitrary version string. # -#INST_VER := \5.21.7 +#INST_VER := \5.22.0 # # Comment this out if you DON'T want your perl installation to have @@ -173,7 +173,7 @@ USE_LARGE_FILES := define # set this to additionally provide a statically linked perl-static.exe. # Note that dynamic loading will not work with this perl, so you must # include required modules statically using the STATIC_EXT or ALL_STATIC -# variables below. A static library perl521s.lib will also be created. +# variables below. A static library perl522s.lib will also be created. # Ordinary perl.exe is not affected by this option. # #BUILD_STATIC := define @@ -413,6 +413,7 @@ EXEOUT_FLAG = -o LIBOUT_FLAG = BUILDOPT += -fno-strict-aliasing -mms-bitfields +MINIBUILDOPT += -fno-strict-aliasing CFLAGS_O = $(CFLAGS) $(BUILDOPT) # used to allow local linking flags that are not propogated into Config.pm, @@ -518,13 +519,13 @@ UTILS = \ CFGSH_TMPL = config.gc CFGH_TMPL = config_H.gc -PERLIMPLIB = ..\libperl521$(a) -PERLSTATICLIB = ..\libperl521s$(a) +PERLIMPLIB = ..\libperl522$(a) +PERLSTATICLIB = ..\libperl522s$(a) INT64 = long long # makedef.pl must be updated if this changes, and this should normally # only change when there is an incompatible revision of the public API. -PERLDLL = ..\perl521.dll +PERLDLL = ..\perl522.dll XCOPY = xcopy /f /r /i /d /y RCOPY = xcopy /f /r /i /e /d /y @@ -539,7 +540,7 @@ MICROCORE_SRC = \ ..\dump.c \ ..\globals.c \ ..\gv.c \ - ..\mro.c \ + ..\mro_core.c \ ..\hv.c \ ..\locale.c \ ..\keywords.c \ @@ -1127,7 +1128,7 @@ utils: $(PERLEXE) ..\utils\Makefile copy ..\README.tw ..\pod\perltw.pod copy ..\README.vos ..\pod\perlvos.pod copy ..\README.win32 ..\pod\perlwin32.pod - copy ..\pod\perldelta.pod ..\pod\perl5217delta.pod + copy ..\pod\perldelta.pod ..\pod\perl5220delta.pod $(PERLEXE) $(PL2BAT) $(UTILS) $(MINIPERL) -I..\lib ..\autodoc.pl .. $(MINIPERL) -I..\lib ..\pod\perlmodlib.PL -q .. @@ -1222,7 +1223,7 @@ distclean: realclean -if exist $(LIBDIR)\Win32API rmdir /s /q $(LIBDIR)\Win32API -if exist $(LIBDIR)\XS rmdir /s /q $(LIBDIR)\XS -cd $(PODDIR) && del /f *.html *.bat roffitall \ - perl5217delta.pod perlaix.pod perlamiga.pod perlandroid.pod \ + perl5220delta.pod perlaix.pod perlamiga.pod perlandroid.pod \ perlapi.pod perlbs2000.pod perlce.pod perlcn.pod perlcygwin.pod \ perldos.pod perlfreebsd.pod perlhaiku.pod perlhpux.pod \ perlhurd.pod perlintern.pod perlirix.pod perljp.pod perlko.pod \ -- 1.9.5.msysgit.0
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 320b
On Thu Dec 25 22:29:01 2014, kmx@atlas.cz wrote: Show quoted text
> I have updated my gist with Rob's patch
GNUmakefile is now in blead. Your original GNUmakefile was added as 342634f3c8ce34b27ed1ba93ae7eb1c52ca438b2 and patches to bring it to 5.23.0 and some backported changes are in 16d5aac12f61ea3658d20dd0963c60867513408e. Tony
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 824b
On Sun Jun 07 19:19:26 2015, tonyc wrote: Show quoted text
> On Thu Dec 25 22:29:01 2014, kmx@atlas.cz wrote:
> > I have updated my gist with Rob's patch
> > GNUmakefile is now in blead. > > Your original GNUmakefile was added as > 342634f3c8ce34b27ed1ba93ae7eb1c52ca438b2 and patches to bring it to > 5.23.0 and some backported changes are in > 16d5aac12f61ea3658d20dd0963c60867513408e. > > Tony
TonyC, did you ever try building Win32 gmake perl before you committed that code? And did the gmake build, build to completion? I have a problem with blead's EUMM that prevents any EUMM Win32 gmake makefiles from being able to build anything since the EUMM fixes mentioned in https://rt.perl.org/Ticket/Display.html?id=123440#txn-1324040 never made it into blead due to EUMM's development stall on CPAN. -- bulk88 ~ bulk88 at hotmail.com
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Date: Sat, 7 Nov 2015 23:31:13 +0000
CC: perl5-porters [...] perl.org
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
To: bulk88 via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1020b


On 7 Nov 2015 23:02, "bulk88 via RT" <perlbug-followup@perl.org> wrote:
Show quoted text

>
> On Sun Jun 07 19:19:26 2015, tonyc wrote:
> > On Thu Dec 25 22:29:01 2014, kmx@atlas.cz wrote:
> > > I have updated my gist with Rob's patch
> >
> > GNUmakefile is now in blead.
> >
> > Your original GNUmakefile was added as
> > 342634f3c8ce34b27ed1ba93ae7eb1c52ca438b2 and patches to bring it to
> > 5.23.0 and some backported changes are in
> > 16d5aac12f61ea3658d20dd0963c60867513408e.
> >
> > Tony
>
> TonyC, did you ever try building Win32 gmake perl before you committed that code? And did the gmake build, build to completion? I have a problem with blead's EUMM that prevents any EUMM Win32 gmake makefiles from being able to build anything since the EUMM fixes mentioned in https://rt.perl.org/Ticket/Display.html?id=123440#txn-1324040 never made it into blead due to EUMM's development stall on CPAN.
>

I tested the gmake build only the other day when I pushed 771d08d04402e3fb2c253e6bf8b46524b761a020, and it built to completion ok.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.3k
On Sat Nov 07 15:31:51 2015, shay wrote: Show quoted text
> On 7 Nov 2015 23:02, "bulk88 via RT" <perlbug-followup@perl.org> wrote:
> > > > On Sun Jun 07 19:19:26 2015, tonyc wrote:
> > > On Thu Dec 25 22:29:01 2014, kmx@atlas.cz wrote:
> > > > I have updated my gist with Rob's patch
> > > > > > GNUmakefile is now in blead. > > > > > > Your original GNUmakefile was added as > > > 342634f3c8ce34b27ed1ba93ae7eb1c52ca438b2 and patches to bring it to > > > 5.23.0 and some backported changes are in > > > 16d5aac12f61ea3658d20dd0963c60867513408e. > > > > > > Tony
> > > > TonyC, did you ever try building Win32 gmake perl before you committed
> that code? And did the gmake build, build to completion? I have a problem > with blead's EUMM that prevents any EUMM Win32 gmake makefiles from being > able to build anything since the EUMM fixes mentioned in > https://rt.perl.org/Ticket/Display.html?id=123440#txn-1324040 never made it > into blead due to EUMM's development stall on CPAN.
> >
> > I tested the gmake build only the other day when I pushed > 771d08d04402e3fb2c253e6bf8b46524b761a020, and it built to completion ok.
Do you allow gmake/your build console's PATH to see (msys) git.exe (and therefore sh.exe) when you build with gmake? I always have git in my path so t/porting tests like cmp_version.t run instead of being skipped. -- bulk88 ~ bulk88 at hotmail.com
CC: perl5-porters [...] perl.org
From: Tony Cook <tony [...] develop-help.com>
To: bulk88 via RT <perlbug-followup [...] perl.org>
Date: Sun, 8 Nov 2015 12:37:07 +1100
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 927b
On Sat, Nov 07, 2015 at 03:02:40PM -0800, bulk88 via RT wrote: Show quoted text
> On Sun Jun 07 19:19:26 2015, tonyc wrote:
> > On Thu Dec 25 22:29:01 2014, kmx@atlas.cz wrote:
> > > I have updated my gist with Rob's patch
> > > > GNUmakefile is now in blead. > > > > Your original GNUmakefile was added as > > 342634f3c8ce34b27ed1ba93ae7eb1c52ca438b2 and patches to bring it to > > 5.23.0 and some backported changes are in > > 16d5aac12f61ea3658d20dd0963c60867513408e. > > > > Tony
> > TonyC, did you ever try building Win32 gmake perl before you
committed that code? And did the gmake build, build to completion? I have a problem with blead's EUMM that prevents any EUMM Win32 gmake makefiles from being able to build anything since the EUMM fixes mentioned in https://rt.perl.org/Ticket/Display.html?id=123440#txn-1324040 never made it into blead due to EUMM's development stall on CPAN. Yes, and git is in my PATH. Tony
From: <sisyphus1 [...] optusnet.com.au>
Date: Mon, 9 Nov 2015 11:32:14 +1100
To: <perlbug-followup [...] perl.org>
CC: <perl5-porters [...] perl.org>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 651b
Show quoted text
-----Original Message----- From: bulk88 via RT Sent: Sunday, November 08, 2015 11:22 AM To: OtherRecipients of perl Ticket #123440: Cc: perl5-porters@perl.org Subject: [perl #123440] Adding win32/GNUmakefile
> Do you allow gmake/your build console's PATH to see (msys) git.exe (and > therefore sh.exe) when you build with gmake? I always have git in my path > so t/porting tests like cmp_version.t run instead of being skipped.
Near the beginning of GNUmakefile you'll find: SHELL := cmd.exe That should take care of the impasse that would otherwise arise if sh.exe is in your path. Are you overriding that "SHELL" setting ? Cheers, Rob
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 9.3k
On Sun Nov 08 16:33:18 2015, sisyphus wrote: Show quoted text
> Near the beginning of GNUmakefile you'll find: > > SHELL := cmd.exe > > That should take care of the impasse that would otherwise arise if > sh.exe is > in your path. > Are you overriding that "SHELL" setting ? > > Cheers, > Rob
I am using --------------------------------- C:\p523\src\win32>gmake -v GNU Make 4.0.90 Built for Windows32 Copyright (C) 1988-2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. C:\p523\src\win32> --------------------------------- from Strawberry 5.20. I am not overriding SHELL env var and it is not set in my env vars, that line in the makefile seems to only applies to the ROOT makefile, not all the EUMM makefiles running from make_ext.pl. I dont think the SHELL mkf var is passed on the children processes through env vars. Msys git comes with a [ba]"sh.exe" next to "git.exe" and per gmake's docs gmake always prefers sh.exe instead of cmd.exe https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html ------------------------------------------------- C:\p523\src\win32>"C:/Program Files/Git/bin/sh.exe" -c "echo $BASH_VERSION" 3.1.23(6)-release C:\p523\src\win32> ------------------------------------------------- If I have git in my win32 cmd console PATH and try to build perl I get a failure as the EUMM gmake finds and launches sh.exe. ------------------------------------------------- ..\miniperl.exe -I..\lib create_perllibst_h.pl ..\miniperl.exe -I..\lib -w ..\makedef.pl PLATFORM=win32 -s -O2 -DWIN32 \ -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLI O -fwrapv -fno-strict-aliasing -mms-bitfields CCTYPE=GCC TARG_DIR=..\ > perldll. def Options: (HAS_TIMES HAVE_INTERP_INTERN PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_DIS ABLE_PMC PERL_DONT_CREATE_GVSV PERL_EXTERNAL_GLOB PERL_HASH_FUNC_ONE_AT_A_TIME_H ARD PERL_IS_MINIPERL PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_LOCALE USE_LOCALE_C OLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_NO_REGISTRY USE_P ERLIO USE_PERL_ATOF USE_SITECUSTOMIZE) Defines: (HAS_ACCESS HAS_ALARM HAS_CHSIZE HAS_CRYPT HAS_DBL_DIG HAS_DIFFTIME HAS _DLERROR HAS_DUP2 HAS_FAST_STDIO HAS_FD_SET HAS_FGETPOS HAS_FLOCK HAS_FLOCK_PROT O HAS_FSETPOS HAS_GETCWD HAS_GETHOSTBYADDR HAS_GETHOSTBYNAME HAS_GETHOSTNAME HAS _GETHOST_PROTOS HAS_GETLOGIN HAS_GETPROTOBYNAME HAS_GETPROTOBYNUMBER HAS_GETPROT O_PROTOS HAS_GETSERVBYNAME HAS_GETSERVBYPORT HAS_GETSERV_PROTOS HAS_GETTIMEOFDAY HAS_HTONL HAS_HTONS HAS_ISASCII HAS_ISNAN HAS_KILLPG HAS_LDBL_DIG HAS_LINK HAS_ LOCALECONV HAS_LONG_DOUBLE HAS_LONG_LONG HAS_LSEEK_PROTO HAS_MBLEN HAS_MBSTOWCS HAS_MBTOWC HAS_MEMCHR HAS_MEMCMP HAS_MEMCPY HAS_MEMMOVE HAS_MEMSET HAS_MKDIR HAS _MKTIME HAS_NTOHL HAS_NTOHS HAS_PAUSE HAS_PIPE HAS_PSEUDOFORK HAS_PTRDIFF_T HAS_ QUAD HAS_READDIR HAS_RENAME HAS_REWINDDIR HAS_RMDIR HAS_SANE_MEMCMP HAS_SEEKDIR HAS_SELECT HAS_SETLOCALE HAS_SETVBUF HAS_SIN6_SCOPE_ID HAS_SNPRINTF HAS_SOCKET H AS_STAT HAS_STATIC_INLINE HAS_STRCHR HAS_STRCOLL HAS_STRERROR HAS_STRFTIME HAS_S TRTOD HAS_STRTOL HAS_STRTOUL HAS_STRXFRM HAS_SYSTEM HAS_SYS_ERRLIST HAS_TELLDIR HAS_TELLDIR_PROTO HAS_TIME HAS_TIMES HAS_TZNAME HAS_UMASK HAS_UNAME HAS_UNION_SE MUN HAS_VPRINTF HAS_VSNPRINTF HAS_WAITPID HAS_WCSCMP HAS_WCSTOMBS HAS_WCSXFRM HA S_WCTOMB HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_D ISABLE_PMC PERL_DONT_CREATE_GVSV PERL_EXTERNAL_GLOB PERL_HASH_FUNC_ONE_AT_A_TIME _HARD PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_IS_MINIPERL PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_RELOCATABLE_INC PERL_STATIC_INLINE PERL_TARGETARCH PERL_ TEXTMODE_SCRIPTS SPRINTF_RETURNS_STRLEN USE_DYNAMIC_LOADING USE_ITHREADS USE_LAR GE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_L OCALE_TIME USE_NO_REGISTRY USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE USE_STDIO_ BASE USE_STDIO_PTR USE_STRUCT_COPY USE_THREADS WIN32) xcopy /f /r /i /d /y "..\*.h" ..\lib\CORE\ 0 File(s) copied ..\miniperl.exe -I..\lib ..\make_ext.pl "MAKE=gmake" --dir=..\cpan --dir=..\dist --dir=..\ext --nonxs Generating a gmake-style Makefile Writing Makefile for Archive::Tar gmake[1]: Entering directory 'C:/p523/src/cpan/Archive-Tar' "C:/Program Files/Git/bin/sh.exe": C:p523srcminiperl.exe: command not found Makefile:334: recipe for target '..\..\lib\Archive/.exists' failed gmake[1]: *** [..\..\lib\Archive/.exists] Error 127 gmake[1]: Leaving directory 'C:/p523/src/cpan/Archive-Tar' gmake[1]: Entering directory 'C:/p523/src/cpan/Archive-Tar' "C:/Program Files/Git/bin/sh.exe": C:p523srcminiperl.exe: command not found Makefile:334: recipe for target '..\..\lib\Archive/.exists' failed gmake[1]: *** [..\..\lib\Archive/.exists] Error 127 gmake[1]: Leaving directory 'C:/p523/src/cpan/Archive-Tar' Unsuccessful make(cpan/Archive-Tar): code=512 at ..\make_ext.pl line 578. GNUmakefile:1070: recipe for target 'Extensions_nonxs' failed gmake: *** [Extensions_nonxs] Error 25 C:\p523\src\win32>set path Path=C:\sp520\c\bin;C:\Windows\system32;C:\Program Files\Microsoft Visual Studio 12.0\VC\BIN;C:\Program Files\Windows Kits\8.1\bin\x86;C:\Windows;C:\Program Files\ActiveState Komodo Edit 9;C:\Program Files\Git\bin; -------------------------------------------------- If I remove git from my path, everything works fine. -------------------------------------------------- ..\miniperl.exe -I..\lib create_perllibst_h.pl ..\miniperl.exe -I..\lib -w ..\makedef.pl PLATFORM=win32 -s -O2 -DWIN32 \ -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLI O -fwrapv -fno-strict-aliasing -mms-bitfields CCTYPE=GCC TARG_DIR=..\ > perldll. def Options: (HAS_TIMES HAVE_INTERP_INTERN PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_DIS ABLE_PMC PERL_DONT_CREATE_GVSV PERL_EXTERNAL_GLOB PERL_HASH_FUNC_ONE_AT_A_TIME_H ARD PERL_IS_MINIPERL PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_LOCALE USE_LOCALE_C OLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LOCALE_TIME USE_NO_REGISTRY USE_P ERLIO USE_PERL_ATOF USE_SITECUSTOMIZE) Defines: (HAS_ACCESS HAS_ALARM HAS_CHSIZE HAS_CRYPT HAS_DBL_DIG HAS_DIFFTIME HAS _DLERROR HAS_DUP2 HAS_FAST_STDIO HAS_FD_SET HAS_FGETPOS HAS_FLOCK HAS_FLOCK_PROT O HAS_FSETPOS HAS_GETCWD HAS_GETHOSTBYADDR HAS_GETHOSTBYNAME HAS_GETHOSTNAME HAS _GETHOST_PROTOS HAS_GETLOGIN HAS_GETPROTOBYNAME HAS_GETPROTOBYNUMBER HAS_GETPROT O_PROTOS HAS_GETSERVBYNAME HAS_GETSERVBYPORT HAS_GETSERV_PROTOS HAS_GETTIMEOFDAY HAS_HTONL HAS_HTONS HAS_ISASCII HAS_ISNAN HAS_KILLPG HAS_LDBL_DIG HAS_LINK HAS_ LOCALECONV HAS_LONG_DOUBLE HAS_LONG_LONG HAS_LSEEK_PROTO HAS_MBLEN HAS_MBSTOWCS HAS_MBTOWC HAS_MEMCHR HAS_MEMCMP HAS_MEMCPY HAS_MEMMOVE HAS_MEMSET HAS_MKDIR HAS _MKTIME HAS_NTOHL HAS_NTOHS HAS_PAUSE HAS_PIPE HAS_PSEUDOFORK HAS_PTRDIFF_T HAS_ QUAD HAS_READDIR HAS_RENAME HAS_REWINDDIR HAS_RMDIR HAS_SANE_MEMCMP HAS_SEEKDIR HAS_SELECT HAS_SETLOCALE HAS_SETVBUF HAS_SIN6_SCOPE_ID HAS_SNPRINTF HAS_SOCKET H AS_STAT HAS_STATIC_INLINE HAS_STRCHR HAS_STRCOLL HAS_STRERROR HAS_STRFTIME HAS_S TRTOD HAS_STRTOL HAS_STRTOUL HAS_STRXFRM HAS_SYSTEM HAS_SYS_ERRLIST HAS_TELLDIR HAS_TELLDIR_PROTO HAS_TIME HAS_TIMES HAS_TZNAME HAS_UMASK HAS_UNAME HAS_UNION_SE MUN HAS_VPRINTF HAS_VSNPRINTF HAS_WAITPID HAS_WCSCMP HAS_WCSTOMBS HAS_WCSXFRM HA S_WCTOMB HAVE_INTERP_INTERN MULTIPLICITY PERLIO_LAYERS PERL_COPY_ON_WRITE PERL_D ISABLE_PMC PERL_DONT_CREATE_GVSV PERL_EXTERNAL_GLOB PERL_HASH_FUNC_ONE_AT_A_TIME _HARD PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS PERL_IS_MINIPERL PERL_MALLOC_WRAP PERL_PRESERVE_IVUV PERL_RELOCATABLE_INC PERL_STATIC_INLINE PERL_TARGETARCH PERL_ TEXTMODE_SCRIPTS SPRINTF_RETURNS_STRLEN USE_DYNAMIC_LOADING USE_ITHREADS USE_LAR GE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_L OCALE_TIME USE_NO_REGISTRY USE_PERLIO USE_PERL_ATOF USE_SITECUSTOMIZE USE_STDIO_ BASE USE_STDIO_PTR USE_STRUCT_COPY USE_THREADS WIN32) xcopy /f /r /i /d /y "..\*.h" ..\lib\CORE\ 0 File(s) copied ..\miniperl.exe -I..\lib ..\make_ext.pl "MAKE=gmake" --dir=..\cpan --dir=..\dist --dir=..\ext --nonxs Generating a gmake-style Makefile Writing Makefile for Archive::Tar gmake[1]: Entering directory 'C:/p523/src/cpan/Archive-Tar' gmake[1]: Leaving directory 'C:/p523/src/cpan/Archive-Tar' Generating a gmake-style Makefile Writing Makefile for CPAN gmake[1]: Entering directory 'C:/p523/src/cpan/CPAN' gmake[1]: Leaving directory 'C:/p523/src/cpan/CPAN' Generating a gmake-style Makefile Writing Makefile for Errno gmake[1]: Entering directory 'C:/p523/src/ext/Errno' Terminating on signal SIGINT(2) Terminating on signal SIGINT(2) GNUmakefile:1070: recipe for target 'Extensions_nonxs' failed Makefile:355: recipe for target 'blib\script/.exists' failed gmake: *** [Extensions_nonxs] Error 2 gmake[1]: *** [blib\script/.exists] Error 2 C:\p523\src\win32>set path Path=C:\sp520\c\bin;C:\Windows\system32;C:\Program Files\Microsoft Visual Studio 12.0\VC\BIN;C:\Program Files\Windows Kits\8.1\bin\x86;C:\Windows;C:\Program Fil es\ActiveState Komodo Edit 9; ------------------------------------------------------- I've included 4 procmon logs showing gmake finding or not finding sh.exe, and launching sh.exe (wrong) or cmd.exe (correct) while building a core module. If sh.exe is launches, everything breaks, IDK how you tonyc dont see this problem, unless you have a git.exe without a sh.exe next to it or you copied git.exe to a non-standard location like "C:/Windows" from its "Program Files" location. -- bulk88 ~ bulk88 at hotmail.com
Subject: gmakelaunch-via-cmd.CSV
Download gmakelaunch-via-cmd.CSV
application/octet-stream 23.2k

Message body not shown because it is not plain text.

Subject: gmakeshlaunch.CSV
Download gmakeshlaunch.CSV
application/octet-stream 8.3k

Message body not shown because it is not plain text.

Subject: gmakeshsearch.CSV
Download gmakeshsearch.CSV
application/octet-stream 5.1k

Message body not shown because it is not plain text.

Subject: gmaketrystofind-sh-butfails.CSV
Download gmaketrystofind-sh-butfails.CSV
application/octet-stream 3.9k

Message body not shown because it is not plain text.

Subject: Re: [perl #123440] Adding win32/GNUmakefile
Date: Mon, 9 Nov 2015 18:58:02 +1100
CC: ;, perl5-porters [...] perl.org
From: Tony Cook <tony [...] develop-help.com>
To: bulk88 via RT <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 709b
On Sun, Nov 08, 2015 at 11:40:14PM -0800, bulk88 via RT wrote: Show quoted text
> IDK how you tonyc dont see this problem, unless you have a git.exe without a sh.exe next to it or you copied git.exe to a non-standard location like "C:/Windows" from its "Program Files" location.
J:\dev\perl\git\perl\win32>bash 'bash' is not recognized as an internal or external command, operable program or batch file. J:\dev\perl\git\perl\win32>sh 'sh' is not recognized as an internal or external command, operable program or batch file. J:\dev\perl\git\perl\win32>git --version git version 1.9.5.msysgit.0 When I installed git I chose to have only git in PATH, not all the tools. I didn't reorganize any of the msysgit files. Tony
To: bulk88 via RT <perlbug-followup [...] perl.org>
From: Steve Hay via perl5-porters <perl5-porters [...] perl.org>
CC: "perl5-porters [...] perl.org" <perl5-porters [...] perl.org>
Date: Mon, 9 Nov 2015 08:21:47 +0000
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 1.7k
On 8 November 2015 at 00:22, bulk88 via RT <perlbug-followup@perl.org> wrote: Show quoted text
> On Sat Nov 07 15:31:51 2015, shay wrote:
>> On 7 Nov 2015 23:02, "bulk88 via RT" <perlbug-followup@perl.org> wrote:
>> > >> > On Sun Jun 07 19:19:26 2015, tonyc wrote:
>> > > On Thu Dec 25 22:29:01 2014, kmx@atlas.cz wrote:
>> > > > I have updated my gist with Rob's patch
>> > > >> > > GNUmakefile is now in blead. >> > > >> > > Your original GNUmakefile was added as >> > > 342634f3c8ce34b27ed1ba93ae7eb1c52ca438b2 and patches to bring it to >> > > 5.23.0 and some backported changes are in >> > > 16d5aac12f61ea3658d20dd0963c60867513408e. >> > > >> > > Tony
>> > >> > TonyC, did you ever try building Win32 gmake perl before you committed
>> that code? And did the gmake build, build to completion? I have a problem >> with blead's EUMM that prevents any EUMM Win32 gmake makefiles from being >> able to build anything since the EUMM fixes mentioned in >> https://rt.perl.org/Ticket/Display.html?id=123440#txn-1324040 never made it >> into blead due to EUMM's development stall on CPAN.
>> >
>> >> I tested the gmake build only the other day when I pushed >> 771d08d04402e3fb2c253e6bf8b46524b761a020, and it built to completion ok.
> > Do you allow gmake/your build console's PATH to see (msys) git.exe (and therefore sh.exe) when you build with gmake? I always have git in my path so t/porting tests like cmp_version.t run instead of being skipped. >
Yes, git is in the path, but as with Tony's setup, I also chose to have only git in PATH, not all the tools, i.e. C:\Program Files (x86)\Git\cmd but not C:\Program Files (x86)\Git\bin . (I think in the first instance I did this to avoid ending up with the wrong 'find' program in the path, which I've also had trouble with in the past.)
From: <sisyphus1 [...] optusnet.com.au>
Date: Mon, 9 Nov 2015 21:00:08 +1100
To: "Steve Hay" <steve.m.hay [...] googlemail.com>, "bulk88 via RT" <perlbug-followup [...] perl.org>
CC: <perl5-porters [...] perl.org>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 2.8k
Show quoted text
-----Original Message----- From: Steve Hay via perl5-porters Sent: Monday, November 09, 2015 7:21 PM To: bulk88 via RT Cc: perl5-porters@perl.org Subject: Re: [perl #123440] Adding win32/GNUmakefile
>> Do you allow gmake/your build console's PATH to see (msys) git.exe (and >> therefore sh.exe) when you build with gmake? I always have git in my path >> so t/porting tests like cmp_version.t run instead of being skipped.
> > Yes, git is in the path, but as with Tony's setup, I also chose to have > only git in PATH, not all the tools, i.e. C:\Program Files (x86)\Git\cmd > but not C:\Program Files (x86)\Git\bin . (I think in the first instance I > did this to avoid ending up with the wrong 'find'
program in the path, which I've also had trouble with in the past.) 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 !! ..\miniperl.exe -I..\lib -f ..\write_buildcustomize.pl .. Use of uninitialized value $pwd in scalar chomp at dist/PathTools/Cwd.pm line 623. Use of uninitialized value $pwd in substitution (s///) at dist/PathTools/Cwd.pm line 624. Use of uninitialized value $pwd in scalar chomp at dist/PathTools/Cwd.pm line 623. Use of uninitialized value $pwd in substitution (s///) at dist/PathTools/Cwd.pm line 624. Use of uninitialized value $path in pattern match (m//) at dist/PathTools/lib/File/Spec/Win32.pm line 214. . . Use of uninitialized value $pwd in substitution (s///) at dist/PathTools/Cwd.pm line 624. Use of uninitialized value $path in pattern match (m//) at dist/PathTools/lib/File/Spec/Win32.pm line 214. Use of uninitialized value $pwd in scalar chomp at dist/PathTools/Cwd.pm line 623. Use of uninitialized value $pwd in substitution (s///) at dist/PathTools/Cwd.pm line 624. Use of uninitialized value $path in pattern match (m//) at dist/PathTools/lib/File/Spec/Win32.pm line 214. Can't locate strict.pm in @INC (you may need to install the strict module) (@INC contains: \lib \cpan\AutoLoader\lib \dist\Carp\lib \dist\PathTools \dist\PathTools\lib \cpan\ExtUtils-Install\lib \cpan\ExtUtils-MakeMaker\lib \cpan\ExtUtils-Manifest\lib \cpan\File-Path\lib \ext\re \dist\Term-ReadLine\lib \dist\Exporter\lib \ext\File-Find\lib \cpan\Text-Tabs\lib \dist\constant\lib \cpan\Text-ParseWords\lib \dist\ExtUtils-ParseXS\lib \cpan\Getopt-Long\lib \cpan\parent\lib \cpan\ExtUtils-Constant\lib .) at make_patchnum.pl line 3. BEGIN failed--compilation aborted at make_patchnum.pl line 3. GNUmakefile:923: recipe for target '..\git_version.h' failed make: *** [..\git_version.h] Error 2 That's with last month's perl-5.23.4. Is there a POV that justifies this breakaqge ? Cheers, Rob
Subject: Re: [perl #123440] Adding win32/GNUmakefile
To: perlbug-followup [...] perl.org
Date: Mon, 9 Nov 2015 11:21:01 +0100
From: kmx <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 299b
Show quoted text
> Use of uninitialized value $pwd in scalar chomp at dist/PathTools/Cwd.pm > line 623.
The trouble is IMO here: http://perl5.git.perl.org/perl.git/blob/28aaeb3b24f750f72f0505fc311412e0fa8a29f4:/dist/PathTools/Cwd.pm#l621 The command `cd` gives different output under cmd.exe and sh.exe -- kmx
Date: Mon, 9 Nov 2015 21:42:59 +1100
From: <sisyphus1 [...] optusnet.com.au>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
To: <perlbug-followup [...] perl.org>, "kmx" <kmx [...] volny.cz>
Download (untitled) / with headers
text/plain 1.8k
Show quoted text
-----Original Message----- From: kmx Sent: Monday, November 09, 2015 9:21 PM To: perlbug-followup@perl.org Subject: Re: [perl #123440] Adding win32/GNUmakefile
>> Use of uninitialized value $pwd in scalar chomp at dist/PathTools/Cwd.pm >> line 623.
> > The trouble is IMO here: > http://perl5.git.perl.org/perl.git/blob/28aaeb3b24f750f72f0505fc311412e0fa8a29f4:/dist/PathTools/Cwd.pm#l621 > >The command `cd` gives different output under cmd.exe and sh.exe
Yes - and it arises because I placed sh.exe fairly early on in the PATH ... which can perhaps be considered to be a PEBCAK. I'm not so sure that we should expect perl to build if sh.exe's "cd" gets found ahead of cmd.exe's version. However, even if I place msys/bin (and hence sh.exe) at the end of the path, I still get: C:\comp\blead\win32>make ..... .... ..\miniperl.exe -I..\lib ..\make_ext.pl "MAKE=make" --dir=..\cpan --dir=..\dis --dir=..\ext --nonxs Generating a make-style Makefile Writing Makefile for Archive::Tar make[1]: Entering directory 'C:/comp/blead/cpan/Archive-Tar' /usr/bin/sh: C:compbleadminiperl.exe: command not found Makefile:334: recipe for target '..\..\lib\Archive/.exists' failed make[1]: *** [..\..\lib\Archive/.exists] Error 127 make[1]: Leaving directory 'C:/comp/blead/cpan/Archive-Tar' make[1]: Entering directory 'C:/comp/blead/cpan/Archive-Tar' /usr/bin/sh: C:compbleadminiperl.exe: command not found Makefile:334: recipe for target '..\..\lib\Archive/.exists' failed make[1]: *** [..\..\lib\Archive/.exists] Error 127 make[1]: Leaving directory 'C:/comp/blead/cpan/Archive-Tar' Unsuccessful make(cpan/Archive-Tar): code=512 at ..\make_ext.pl line 578. GNUmakefile:1070: recipe for target 'Extensions_nonxs' failed make: *** [Extensions_nonxs] Error 25 Am I still in PEBCAK territory ? (This is now with current blead as source.) Cheers, Rob
To: perlbug-followup [...] perl.org
Subject: Re: [perl #123440] Adding win32/GNUmakefile
From: kmx <kmx [...] volny.cz>
Date: Mon, 9 Nov 2015 12:06:22 +0100
Download (untitled) / with headers
text/plain 176b
Perhaps patching "sub _win32_cwd_simple" (in dist/PathTools/Cwd.pm) like this: - my $pwd = `cd`; + my $pwd = `cmd /c cd`; # stolen from _os2_cwd might do the trick. -- kmx
Subject: Re: [perl #123440] Adding win32/GNUmakefile
CC: <perl5-porters [...] perl.org>
To: "Steve Hay" <steve.m.hay [...] googlemail.com>, "bulk88 via RT" <perlbug-followup [...] perl.org>
Date: Tue, 10 Nov 2015 10:08:23 +1100
From: <sisyphus1 [...] optusnet.com.au>
Show quoted text
-----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
Date: Tue, 10 Nov 2015 12:48:19 +1100
From: <sisyphus1 [...] optusnet.com.au>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
CC: <perl5-porters [...] perl.org>
To: "Steve Hay" <steve.m.hay [...] googlemail.com>, "bulk88 via RT" <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.3k
Show quoted text
-----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
Date: Tue, 10 Nov 2015 13:01:27 +1100
From: <sisyphus1 [...] optusnet.com.au>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
CC: <perl5-porters [...] perl.org>
To: "Steve Hay" <steve.m.hay [...] googlemail.com>, "bulk88 via RT" <perlbug-followup [...] perl.org>
Download (untitled) / with headers
text/plain 1.5k
And now ... the patch :-) Show quoted text
-----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
Download EU-MM.diff
application/octet-stream 1.1k

Message body not shown because it is not plain text.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 4.3k
On Mon Nov 09 15:09:14 2015, sisyphus wrote: Show quoted text
> -----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
Subject: 0001-Cache-is_make_type.patch
From 0a9c31fed9356c659cfd4631354732de957f6922 Mon Sep 17 00:00:00 2001 From: Ed J <mohawk2@users.noreply.github.com> Date: Mon, 19 Jan 2015 00:17:31 +0000 Subject: [PATCH 1/4] Cache is_make_type --- cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm | 19 ++++++++++++++----- cpan/ExtUtils-MakeMaker/t/cd.t | 2 ++ 2 files changed, 16 insertions(+), 5 deletions(-) diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm index 570ea72..154f784 100644 --- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm +++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm @@ -202,19 +202,28 @@ Returns true if C<<$self->make>> is the given type; possibilities are: =cut +my %maketype2true; +# undocumented - so t/cd.t can still do its thing +sub _clear_maketype_cache { %maketype2true = () } + sub is_make_type { my($self, $type) = @_; + return $maketype2true{$type} if defined $maketype2true{$type}; (undef, undef, my $make_basename) = $self->splitpath($self->make); - return 1 if $make_basename =~ /\b$type\b/i; # executable's filename - return 0 if $make_basename =~ /\b(dmake|nmake)\b/i; # Never fall through for dmake/nmake + return $maketype2true{$type} = 1 + if $make_basename =~ /\b$type\b/i; # executable's filename + return $maketype2true{$type} = 0 + if $make_basename =~ /\b(dmake|nmake|gmake)\b/i; # Never fall through for dmake/nmake/gmake # now have to run with "-v" and guess my $redirect = $self->can_redirect_error ? '2>&1' : ''; my $make = $self->make || $self->{MAKE}; my $minus_v = `"$make" -v $redirect`; - return 1 if $type eq 'gmake' and $minus_v =~ /GNU make/i; - return 1 if $type eq 'bsdmake' + return $maketype2true{$type} = 1 + if $type eq 'gmake' and $minus_v =~ /GNU make/i; + return $maketype2true{$type} = 1 + if $type eq 'bsdmake' and $minus_v =~ /^usage: make \[-BeikNnqrstWwX\]/im; - 0; # it wasn't whatever you asked + $maketype2true{$type} = 0; # it wasn't whatever you asked } diff --git a/cpan/ExtUtils-MakeMaker/t/cd.t b/cpan/ExtUtils-MakeMaker/t/cd.t index 16f6667..67dfd98 100644 --- a/cpan/ExtUtils-MakeMaker/t/cd.t +++ b/cpan/ExtUtils-MakeMaker/t/cd.t @@ -26,6 +26,7 @@ my @cd_args = ($dir, "command1", "command2"); { local *make = sub { "nmake" }; + $mm->_clear_maketype_cache; my @dirs = (File::Spec->updir) x 2; my $expected_updir = File::Spec->catdir(@dirs); @@ -39,6 +40,7 @@ qq{cd $dir { local *make = sub { "dmake" }; + $mm->_clear_maketype_cache; ::is $mm->cd(@cd_args), qq{cd $dir && command1 -- 1.9.5.msysgit.1
Subject: 0002-Optimise-is_make_type-RE.patch
From c450a5eda4dfd78cc244aa7b8214e70f2fce5448 Mon Sep 17 00:00:00 2001 From: Ed J <mohawk2@users.noreply.github.com> Date: Mon, 19 Jan 2015 13:09:09 +0000 Subject: [PATCH 2/4] Optimise is_make_type RE --- cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm index 154f784..bd8ab3b 100644 --- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm +++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm @@ -213,7 +213,7 @@ sub is_make_type { return $maketype2true{$type} = 1 if $make_basename =~ /\b$type\b/i; # executable's filename return $maketype2true{$type} = 0 - if $make_basename =~ /\b(dmake|nmake|gmake)\b/i; # Never fall through for dmake/nmake/gmake + if $make_basename =~ /\b[gdn]make\b/i; # Never fall through for dmake/nmake/gmake # now have to run with "-v" and guess my $redirect = $self->can_redirect_error ? '2>&1' : ''; my $make = $self->make || $self->{MAKE}; -- 1.9.5.msysgit.1
Subject: 0003-Win32-gmake-needs-SHELL-to-be-specified.patch
From ee7026b2d574e3d97fda23ad92acbb700e795243 Mon Sep 17 00:00:00 2001 From: Sisyphus <sisyphus@cpan.org> Date: Tue, 30 Dec 2014 12:56:58 +1100 Subject: [PATCH 3/4] Win32 gmake needs SHELL to be specified Signed-off-by: Ed J <mohawk2@users.noreply.github.com> --- cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm | 17 ++++++++++++++--- cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm | 11 +++++++++++ 2 files changed, 25 insertions(+), 3 deletions(-) diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm index 535b1f3..d0e4410 100644 --- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm +++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm @@ -317,8 +317,8 @@ sub const_cccmd { =item const_config (o) -Defines a couple of constants in the Makefile that are imported from -%Config. +Sets SHELL if needed, then defines a couple of constants in the Makefile +that are imported from %Config. =cut @@ -326,7 +326,8 @@ sub const_config { # --- Constants Sections --- my($self) = shift; - my @m = <<"END"; + my @m = $self->specify_shell(); # Usually returns empty string + push @m, <<"END"; # These definitions are from config.sh (via $INC{'Config.pm'}). # They may have been overridden via Makefile.PL or on the command line. @@ -3176,6 +3177,16 @@ MAKE_FRAG return $m; } +=item specify_shell + +Specify SHELL if needed - not done on Unix. + +=cut + +sub specify_shell { + return ''; +} + =item quote_paren Backslashes parentheses C<()> in command line arguments. diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm index 47ce479..852223b 100644 --- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm +++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm @@ -232,6 +232,17 @@ sub platform_constants { return $make_frag; } +=item specify_shell + +Set SHELL to $ENV{COMSPEC} only if make is type 'gmake'. + +=cut + +sub specify_shell { + my $self = shift; + return '' unless $self->is_make_type('gmake'); + "\nSHELL = $ENV{COMSPEC}\n"; +} =item constants -- 1.9.5.msysgit.1
Subject: 0004-backport-EUMM-commits.patch

Message body is not shown because it is too large.

Subject: eumm-many-make-v-launches.CSV
Download eumm-many-make-v-launches.CSV
application/octet-stream 8.9k

Message body not shown because it is not plain text.

Subject: Re: [perl #123440] Adding win32/GNUmakefile
Date: Tue, 10 Nov 2015 10:11:57 +0100
CC: Steve Hay <steve.m.hay [...] googlemail.com>, perlbug <perlbug-followup [...] perl.org>, Perl5 Porters <perl5-porters [...] perl.org>
To: Sisyphus <sisyphus1 [...] optusnet.com.au>
From: Leon Timmermans <fawaka [...] gmail.com>
Download (untitled) / with headers
text/plain 1.3k

On Tue, Nov 10, 2015 at 12:08 AM, <sisyphus1@optusnet.com.au> wrote:
Show quoted text

>
> -----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 ??

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: <sisyphus1 [...] optusnet.com.au>
Date: Tue, 10 Nov 2015 20:59:03 +1100
CC: "perlbug" <perlbug-followup [...] perl.org>, "Perl5 Porters" <perl5-porters [...] perl.org>
To: "Leon Timmermans" <fawaka [...] gmail.com>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 914b
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 Show quoted text
>> 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
CC: "perlbug" <perlbug-followup [...] perl.org>, "Perl5 Porters" <perl5-porters [...] perl.org>
To: "Leon Timmermans" <fawaka [...] gmail.com>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
From: <sisyphus1 [...] optusnet.com.au>
Date: Mon, 23 Nov 2015 15:40:26 +1100
Download (untitled) / with headers
text/plain 183b
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
From: <sisyphus1 [...] optusnet.com.au>
Date: Mon, 28 Dec 2015 10:19:39 +1100
To: "perlbug" <perlbug-followup [...] perl.org>
CC: "Perl5 Porters" <perl5-porters [...] perl.org>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 414b
Show quoted text
> -----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
From: <sisyphus1 [...] optusnet.com.au>
Date: Thu, 21 Jan 2016 15:59:08 +1100
To: "perlbug" <perlbug-followup [...] perl.org>
CC: "Perl5 Porters" <perl5-porters [...] perl.org>
Subject: Re: [perl #123440] Adding win32/GNUmakefile
Download (untitled) / with headers
text/plain 403b
Show quoted text
-----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
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 813b
On Wed Jan 20 21:00:11 2016, sisyphus wrote: Show quoted text
> > > -----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.perl.org/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
Subject: Re: [perl #123440] Adding win32/GNUmakefile
To: <perlbug-followup [...] perl.org>
CC: <perl5-porters [...] perl.org>
Date: Mon, 25 Jan 2016 12:49:49 +1100
From: <sisyphus1 [...] optusnet.com.au>
Download (untitled) / with headers
text/plain 773b
Show quoted text
-----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.perl.org/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
Download (untitled) / with headers
text/plain 252b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org