Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding win32/GNUmakefile #14341

Closed
p5pRT opened this issue Dec 16, 2014 · 69 comments
Closed

Adding win32/GNUmakefile #14341

p5pRT opened this issue Dec 16, 2014 · 69 comments

Comments

@p5pRT
Copy link

p5pRT commented Dec 16, 2014

Migrated from rt.perl.org#123440 (status was 'resolved')

Searchable as RT123440$

@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2014

From @kmx

Created by @kmx

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

Perl Info

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)


@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2014

From @steve-m-hay

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.

@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2014

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2014

From @kmx

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)

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

@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2014

From @steve-m-hay

On 16 December 2014 at 09​:39, kmx <kmx@​atlas.cz> wrote​:

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.

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.

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 :-)

@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2014

From @Leont

On Tue, Dec 16, 2014 at 9​:49 AM, kmx <perlbug-followup@​perl.org> wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Dec 16, 2014

From @jandubois

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

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

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2014

From @kmx

On 16.12.2014 20​:08, Jan Dubois wrote​:

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.

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

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2014

From @sisyphus

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

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2014

From @Leont

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.

Leon

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2014

From @jandubois

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?

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2014

From @Leont

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.

Leon

@p5pRT
Copy link
Author

p5pRT commented Dec 18, 2014

From @craigberry

On Wed, Dec 17, 2014 at 5​:40 PM, Leon Timmermans <fawaka@​gmail.com> wrote​:

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.

@p5pRT
Copy link
Author

p5pRT commented Dec 18, 2014

From @jandubois

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.

Cheers,
-Jan

@p5pRT
Copy link
Author

p5pRT commented Dec 18, 2014

From @kmx

On 18.12.2014 0​:14, Leon Timmermans via RT wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Dec 18, 2014

From @kmx

On 18.12.2014 6​:39, Jan Dubois via RT wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Dec 18, 2014

From @bulk88

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

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

@p5pRT
Copy link
Author

p5pRT commented Dec 18, 2014

From @Leont

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

@p5pRT
Copy link
Author

p5pRT commented Dec 18, 2014

From @bulk88

On Thu Dec 18 14​:11​:20 2014, LeonT wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Dec 18, 2014

From @kmx

On 18.12.2014 23​:10, Leon Timmermans wrote​:

On Thu, Dec 18, 2014 at 11​:06 PM, bulk88 via RT
<perlbug-followup@​perl.org <mailto​: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

@p5pRT
Copy link
Author

p5pRT commented Dec 21, 2014

From @sisyphus

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

@p5pRT
Copy link
Author

p5pRT commented Dec 21, 2014

From @kmx

On 21.12.2014 5​:01, sisyphus1@​optusnet.com.au wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Dec 26, 2014

From @sisyphus

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

@p5pRT
Copy link
Author

p5pRT commented Dec 26, 2014

From @sisyphus

Inline Patch
--- GNUmakefile.orig	2014-12-26 12:29:14 +1100
+++ GNUmakefile	2014-12-26 12:35:31 +1100
@@ -12,7 +12,12 @@
 ##
 ## Make sure you read README.win32 *before* you mess with anything here!
 ##
-
+
+#
+# We set this to point to cmd.exe in case GNU Make finds sh.exe in the
path. \+\# Comment this line out if necessary \+\# \+SHELL := cmd\.exe

# define whether you want to use native gcc compiler or cross-compiler
# possible values​: gcc
@​@​ -237,12 +242,6 @​@​
EXTRALIBDIRS :=

#
-# set this to point to cmd.exe (only needed if you use some
-# alternate shell that doesn't grok cmd.exe style commands)
-#
-#SHELL := g​:\winnt\system32\cmd.exe
-
-#
# set this to your email address (perl will guess a value from
# from your loginname and your hostname, which may not be right)
#

@p5pRT
Copy link
Author

p5pRT commented Dec 26, 2014

From @kmx

On 26.12.2014 3​:58, sisyphus1@​optusnet.com.au wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Mar 4, 2015

From @kmx

Any chance to have win32/GNUmakefile in 5.22?

--
kmx

@p5pRT
Copy link
Author

p5pRT commented May 25, 2015

From @tonycoz

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

@p5pRT
Copy link
Author

p5pRT commented May 25, 2015

From @bulk88

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.

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

1 similar comment
@p5pRT
Copy link
Author

p5pRT commented May 25, 2015

From @bulk88

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.

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

@p5pRT
Copy link
Author

p5pRT commented May 27, 2015

From @tonycoz

On Mon May 25 09​:37​:28 2015, bulk88 wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Nov 9, 2015

From @kmx

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

@p5pRT
Copy link
Author

p5pRT commented Nov 9, 2015

From @sisyphus

-----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
Perl-Toolchain-Gang/ExtUtils-MakeMaker@06aeb80

The ticket was then closed, but I don't see any remnant of that patch in
current EU​::MM.

WTF ??

Cheers,
Rob

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @sisyphus

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

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @sisyphus

And now ... the patch :-)

-----Original Message-----
From​: sisyphus1@​optusnet.com.au
Sent​: Tuesday, November 10, 2015 12​:48 PM
To​: Steve Hay ; bulk88 via RT
Cc​: perl5-porters@​perl.org
Subject​: Re​: [perl #123440] Adding win32/GNUmakefile

-----Original Message-----
From​: sisyphus1@​optusnet.com.au

One problem (probably *the* problem) is that the gmake-style Makefile that
EU​::MM generates does not specify a SHELL.

For me, the attached patch allows blead (as of last night) to build fine
when sh.exe is in the path, but *following* cmd.exe.
I had to apply the patch in a fresh cloning of blead. For some reason
running 'make distclean' was insufficient.

This patch (or something similar) is needed not just for building perl, but
for building modules after that perl has been installed.

I don't have any sympathy with anyone who would want to use the cmd.exe
shell to build perl, yet have sh.exe *precede* cmd.exe in the path - and I
therefore haven't investigated that scenario.
kmx's patch would certainly be needed, though I suspect the required
patching wouldn't stop there.

I'll ensure that sh.exe is in my path whenever I build future devel
releases. (I invariably run my stable perls with sh.exe in the path - so
this will matter to me when 5.24 is released.)

I'll re-open https://rt.cpan.org/Public/Bug/Display.html?id=101132 and see
if I can find out why the fix is missing from EU-MM-7.10.
Having to re-visit this is really annoying - though I guess I've only got
myself to blame for not keeping C​:\MinGW\msys\1.0\bin in my path.

Cheers,
Rob

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @sisyphus

EU-MM.diff

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @bulk88

On Mon Nov 09 15​:09​:14 2015, sisyphus wrote​:

-----Original Message-----
From​: sisyphus1@​optusnet.com.au
Sent​: Monday, November 09, 2015 9​:00 PM
To​: Steve Hay ; bulk88 via RT
Cc​: perl5-porters@​perl.org
Subject​: Re​: [perl #123440] Adding win32/GNUmakefile

But surely it should be allowable to have sh.exe in your path ?
That's why the "SHELL := cmd.exe" entry was placed in GNUmakefile in
the
first place - and I'm sure that used to work.
But I've just checked (for the first time in a while) whether I can
build
recent perl if I have sh.exe in the path, and I can't !!

One problem (probably *the* problem) is that the gmake-style Makefile
that
EU​::MM generates does not specify a SHELL.
I don't know how or why that omission has come about.

Last December I opened an EU​::MM ticket about this​:
https://rt.cpan.org/Public/Bug/Display.html?id=101132

I ultimately provided a patch that was accepted and applied to EU​::MM
master
as
https://github.com/Perl-Toolchain-Gang/ExtUtils-
MakeMaker/commit/06aeb803cccb2643e1e1cd8edcbcaf966981e05c

The ticket was then closed, but I don't see any remnant of that patch
in
current EU​::MM.

WTF ??

TLDR​: EUMM died, along with 1-1.5 years of bug fixes in its repo this summer (for details see http​://www.nntp.perl.org/group/perl.cpan.workers/2015/10/msg1320.html ).

I've extracted the patches from EUMM on GH master into blead in the attached 4 patches (it is really a branch).

The gmake build now builds to completion for me, just 1 test fails for me with gmake Win32 perl above baseline (regular test failures on my box for months/years now).


C​:\p523\src\win32>cd ..\t & perl harness -v ../cpan/ExtUtils-MakeMaker/t/echo.
t & cd ..\win32
../cpan/ExtUtils-MakeMaker/t/echo.t .. Use of uninitialized value in concatenati
on (.) or string at C​:\p523\src\lib/ExtUtils/MM_Win32.pm line 158.

# Testing simple echo
# Temp dir​: C​:\Users\Owner\AppData\Local\Temp\jfnmo2RnpP
ok 1 - make​: simple echo
ok 2 - bar.txt exists
ok 3 - contents
# Testing multiline echo
# Temp dir​: C​:\Users\Owner\AppData\Local\Temp\Tde5mbFlFu
ok 4 - make​: multiline echo
ok 5 - something.txt exists
ok 6 - contents
# Testing dollar signs escaped
# Temp dir​: C​:\Users\Owner\AppData\Local\Temp\yrVeAmgSUu
ok 7 - make​: dollar signs escaped
ok 8 - something.txt exists

not ok 9 - contents# Failed test 'contents'

# at t/echo.t line 69.
# got​: '$
# '
# expected​: '$something$
# '
# Testing variables escaped
# Temp dir​: C​:\Users\Owner\AppData\Local\Temp\k65aneG7OZ
ok 10 - make​: variables escaped
ok 11 - something.txt exists
# Failed test 'contents'

# at t/echo.t line 69.
not ok 12 - contents
# got​: '
# '
# expected​: '$(something)
# '
# Testing allow_variables
# Temp dir​: C​:\Users\Owner\AppData\Local\Temp\UfMlMWInIv
ok 13 - make​: allow_variables
ok 14 - bar.txt exists
ok 15 - contents
# Testing append
# Temp dir​: C​:\Users\Owner\AppData\Local\Temp\91EWAJpFI_
# Looks like you failed 2 tests of 18.
ok 16 - make​: append
ok 17 - bar.txt exists
ok 18 - contents
1..18
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/18 subtests

Test Summary Report


../cpan/ExtUtils-MakeMaker/t/echo.t (Wstat​: 512 Tests​: 18 Failed​: 2)
  Failed tests​: 9, 12
  Non-zero exit status​: 2
Files=1, Tests=18, 2 wallclock secs ( 0.02 usr + 0.00 sys = 0.02 CPU)
Result​: FAIL

C​:\p523\src\win32>


This test fails with gmake both in the EUMM GH master branch, and in my backport to blead branch. The reason it fails is the ultra tiny makefiles (not EUMM makefiles, but handrolled ones) that are written by echo.t to disk do not include "SHELL =" anywhere, and therefore are launching bash/sh.exe instead of cmd.exe and the "$"s have different escaping/quoting/whatever by bash vs cmd.exe. There is no fix in EUMM GH master for this so I am not writing a fix for a very small test fail today/tonight. I need gmake win32 perl to build in blead before I can try making GNUmakefile parallel friendly (which is why i resurrected this ticket since I couldn't get blead with gmake on win32 to build).

I've also attached a backported fix for "make -v" being called/shelled out dozens of times inside each Makefile.PL. I've attached a syscall log showing the excessive process launches.

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @bulk88

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

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @bulk88

0004-backport-EUMM-commits.patch
From bab3f35dd24c0cf28324b418f76b24a195f6e369 Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Tue, 10 Nov 2015 00:57:55 -0500
Subject: [PATCH 4/4] backport EUMM commits

-commit "Cache is_make_type" and "Optimise is_make_type RE" stops 40
 executions of "gmake.exe -v" process for each Makefile.PL run, these 40
 make process launches make it it very difficult to debug make_ext.pl
 and the make tool with a system call logger, see Perl RT #123440 ticket
 for details

-commit "Win32 gmake needs SHELL to be specified" allows Win32 perl to be
 built with gmake, if msysgit is in the PATH env var, without this patch
 gmake will use bash as the shell instead of cmd.exe and no EUMM modules
 can be built during a Win32 perl build, since bash and cmd.exe command
 line strings are not compatible with each other, see Perl RT #123440
 ticket for details
---
 AUTHORS                                                         | 1 +
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm              | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist.pm                 | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm             | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM.pm                      | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_AIX.pm                  | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm                  | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_BeOS.pm                 | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Cygwin.pm               | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_DOS.pm                  | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Darwin.pm               | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_MacOS.pm                | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_NW5.pm                  | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_OS2.pm                  | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_QNX.pm                  | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_UWIN.pm                 | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm                 | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VMS.pm                  | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VOS.pm                  | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm                | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win95.pm                | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MY.pm                      | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm               | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Config.pm        | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/FAQ.pod          | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Tutorial.pod     | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version.pm       | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version/regex.pm | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mkbootstrap.pm             | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mksymlists.pm              | 2 +-
 cpan/ExtUtils-MakeMaker/lib/ExtUtils/testlib.pm                 | 2 +-
 t/porting/customized.dat                                        | 4 ++--
 32 files changed, 33 insertions(+), 32 deletions(-)

diff --git a/AUTHORS b/AUTHORS
index ebd9222..3acc6cf 100644
--- a/AUTHORS
+++ b/AUTHORS
@@ -371,6 +371,7 @@ Duncan Findlay			<duncf@debian.org>
 E. Choroba			<choroba@cpan.org>
 Ed Avis				<eda@waniasset.com>
 Ed J				<etj@cpan.org>
+Ed J				<mohawk2@users.noreply.github.com>
 Ed Mooring			<mooring@Lynx.COM>
 Ed Santiago			<esm@pobox.com>
 Eddy Tan			<eddy.net@gmail.com>
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm
index 6c1898d..9184471 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Command/MM.pm
@@ -10,7 +10,7 @@ our @ISA = qw(Exporter);
 
 our @EXPORT  = qw(test_harness pod2man perllocal_install uninstall
                   warn_if_old_packlist test_s cp_nonempty);
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 my $Is_VMS = $^O eq 'VMS';
 
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist.pm
index f856657..3bb49d2 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist.pm
@@ -2,7 +2,7 @@ package ExtUtils::Liblist;
 
 use strict;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 use File::Spec;
 require ExtUtils::Liblist::Kid;
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm
index c56f539..43d554e 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm
@@ -11,7 +11,7 @@ use 5.006;
 
 use strict;
 use warnings;
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 use ExtUtils::MakeMaker::Config;
 use Cwd 'cwd';
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM.pm
index c58e0a5..fa5f72c 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM.pm
@@ -3,7 +3,7 @@ package ExtUtils::MM;
 use strict;
 use ExtUtils::MakeMaker::Config;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::Liblist;
 require ExtUtils::MakeMaker;
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_AIX.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_AIX.pm
index 2e0739d..ec3a2fc 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_AIX.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_AIX.pm
@@ -1,7 +1,7 @@
 package ExtUtils::MM_AIX;
 
 use strict;
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::MM_Unix;
 our @ISA = qw(ExtUtils::MM_Unix);
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm
index bd8ab3b..129ad9e 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Any.pm
@@ -1,7 +1,7 @@
 package ExtUtils::MM_Any;
 
 use strict;
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 use Carp;
 use File::Spec;
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_BeOS.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_BeOS.pm
index 847d833..801b035 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_BeOS.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_BeOS.pm
@@ -26,7 +26,7 @@ require ExtUtils::MM_Any;
 require ExtUtils::MM_Unix;
 
 our @ISA = qw( ExtUtils::MM_Any ExtUtils::MM_Unix );
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 
 =item os_flavor
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Cygwin.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Cygwin.pm
index 72cccb8..a9331ff 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Cygwin.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Cygwin.pm
@@ -9,7 +9,7 @@ require ExtUtils::MM_Unix;
 require ExtUtils::MM_Win32;
 our @ISA = qw( ExtUtils::MM_Unix );
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 
 =head1 NAME
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_DOS.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_DOS.pm
index ab3e9d8..c6ffc59 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_DOS.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_DOS.pm
@@ -2,7 +2,7 @@ package ExtUtils::MM_DOS;
 
 use strict;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::MM_Any;
 require ExtUtils::MM_Unix;
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Darwin.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Darwin.pm
index 8d189b5..cc52f1d 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Darwin.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Darwin.pm
@@ -7,7 +7,7 @@ BEGIN {
     our @ISA = qw( ExtUtils::MM_Unix );
 }
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 
 =head1 NAME
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_MacOS.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_MacOS.pm
index 27983f4..820ffd1 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_MacOS.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_MacOS.pm
@@ -2,7 +2,7 @@ package ExtUtils::MM_MacOS;
 
 use strict;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 sub new {
     die 'MacOS Classic (MacPerl) is no longer supported by MakeMaker';
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_NW5.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_NW5.pm
index a236d11..0b89a15 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_NW5.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_NW5.pm
@@ -22,7 +22,7 @@ use strict;
 use ExtUtils::MakeMaker::Config;
 use File::Basename;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::MM_Win32;
 our @ISA = qw(ExtUtils::MM_Win32);
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_OS2.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_OS2.pm
index 2730ee3..2c64ac4 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_OS2.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_OS2.pm
@@ -5,7 +5,7 @@ use strict;
 use ExtUtils::MakeMaker qw(neatvalue);
 use File::Spec;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::MM_Any;
 require ExtUtils::MM_Unix;
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_QNX.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_QNX.pm
index 588c7ee..71c4bd5 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_QNX.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_QNX.pm
@@ -1,7 +1,7 @@
 package ExtUtils::MM_QNX;
 
 use strict;
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::MM_Unix;
 our @ISA = qw(ExtUtils::MM_Unix);
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_UWIN.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_UWIN.pm
index 9ff061a..2350482 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_UWIN.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_UWIN.pm
@@ -1,7 +1,7 @@
 package ExtUtils::MM_UWIN;
 
 use strict;
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::MM_Unix;
 our @ISA = qw(ExtUtils::MM_Unix);
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm
index d0e4410..e24a61b 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Unix.pm
@@ -15,7 +15,7 @@ use ExtUtils::MakeMaker qw($Verbose neatvalue);
 
 # If we make $VERSION an our variable parse_version() breaks
 use vars qw($VERSION);
-$VERSION = '7.10';
+$VERSION = '7.10_01';
 $VERSION = eval $VERSION;  ## no critic [BuiltinFunctions::ProhibitStringyEval]
 
 require ExtUtils::MM_Any;
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VMS.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VMS.pm
index 9b2f964..fab18df 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VMS.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VMS.pm
@@ -15,7 +15,7 @@ BEGIN {
 
 use File::Basename;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::MM_Any;
 require ExtUtils::MM_Unix;
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VOS.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VOS.pm
index 77fe4f9..57d5e32 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VOS.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VOS.pm
@@ -1,7 +1,7 @@
 package ExtUtils::MM_VOS;
 
 use strict;
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::MM_Unix;
 our @ISA = qw(ExtUtils::MM_Unix);
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm
index 852223b..1c6921c 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win32.pm
@@ -27,7 +27,7 @@ use ExtUtils::MakeMaker qw( neatvalue );
 require ExtUtils::MM_Any;
 require ExtUtils::MM_Unix;
 our @ISA = qw( ExtUtils::MM_Any ExtUtils::MM_Unix );
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 $ENV{EMXSHELL} = 'sh'; # to run `commands`
 
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win95.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win95.pm
index f36e23f..2c31d7c 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win95.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_Win95.pm
@@ -2,7 +2,7 @@ package ExtUtils::MM_Win95;
 
 use strict;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require ExtUtils::MM_Win32;
 our @ISA = qw(ExtUtils::MM_Win32);
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MY.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MY.pm
index a100b0b..3973e37 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MY.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MY.pm
@@ -3,7 +3,7 @@ package ExtUtils::MY;
 use strict;
 require ExtUtils::MM;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 our @ISA = qw(ExtUtils::MM);
 
 {
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm
index 4f9d46f..f9fb8fe 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm
@@ -24,7 +24,7 @@ my %Recognized_Att_Keys;
 our %macro_fsentity; # whether a macro is a filesystem name
 our %macro_dep; # whether a macro is a dependency
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 $VERSION = eval $VERSION;  ## no critic [BuiltinFunctions::ProhibitStringyEval]
 
 # Emulate something resembling CVS $Revision$
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Config.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Config.pm
index d469870..3b96836 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Config.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Config.pm
@@ -2,7 +2,7 @@ package ExtUtils::MakeMaker::Config;
 
 use strict;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 use Config ();
 
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/FAQ.pod b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/FAQ.pod
index ac14d0d..d3aa100 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/FAQ.pod
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/FAQ.pod
@@ -1,6 +1,6 @@
 package ExtUtils::MakeMaker::FAQ;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 1;
 __END__
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Tutorial.pod b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Tutorial.pod
index d5679a3..7e53baa 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Tutorial.pod
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/Tutorial.pod
@@ -1,6 +1,6 @@
 package ExtUtils::MakeMaker::Tutorial;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 
 =head1 NAME
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version.pm
index 07743f0..35cd2ab 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version.pm
@@ -15,7 +15,7 @@ use strict;
 
 use vars qw(@ISA $VERSION $CLASS $STRICT $LAX *declare *qv);
 
-$VERSION = '7.10';
+$VERSION = '7.10_01';
 $CLASS = 'version';
 
 {
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version/regex.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version/regex.pm
index be083b3..a0213b1 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version/regex.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker/version/regex.pm
@@ -10,7 +10,7 @@ use strict;
 
 use vars qw($VERSION $CLASS $STRICT $LAX);
 
-$VERSION = '7.10';
+$VERSION = '7.10_01';
 
 #--------------------------------------------------------------------------#
 # Version regexp components
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mkbootstrap.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mkbootstrap.pm
index 74c9199..a393329 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mkbootstrap.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mkbootstrap.pm
@@ -3,7 +3,7 @@ package ExtUtils::Mkbootstrap;
 # There's just too much Dynaloader incest here to turn on strict vars.
 use strict 'refs';
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 require Exporter;
 our @ISA = ('Exporter');
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mksymlists.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mksymlists.pm
index 09e058e..b80310e 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mksymlists.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Mksymlists.pm
@@ -10,7 +10,7 @@ use Config;
 
 our @ISA = qw(Exporter);
 our @EXPORT = qw(&Mksymlists);
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 sub Mksymlists {
     my(%spec) = @_;
diff --git a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/testlib.pm b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/testlib.pm
index 74bce3d..6f5d870 100644
--- a/cpan/ExtUtils-MakeMaker/lib/ExtUtils/testlib.pm
+++ b/cpan/ExtUtils-MakeMaker/lib/ExtUtils/testlib.pm
@@ -3,7 +3,7 @@ package ExtUtils::testlib;
 use strict;
 use warnings;
 
-our $VERSION = '7.10';
+our $VERSION = '7.10_01';
 
 use Cwd;
 use File::Spec;
diff --git a/t/porting/customized.dat b/t/porting/customized.dat
index f64c73a..a29d836 100644
--- a/t/porting/customized.dat
+++ b/t/porting/customized.dat
@@ -2,8 +2,8 @@ CPAN cpan/CPAN/lib/CPAN.pm ce62c43d72f101c011184dbbc59e21c2790826f0
 Encode cpan/Encode/Encode.xs ef106510cceba35eaae4c52127116162f5d7260f
 Encode cpan/Encode/encoding.pm 51c19efc9bfe8467d6ae12a4654f6e7f980715bf
 Encode cpan/Encode/Unicode/Unicode.xs c7ab75e09f6b2685060d3c0bd091862fc2d31724
-ExtUtils::MakeMaker cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm fd048a43fc1a53acbe133bd96ddbf1421cfb28cf
-ExtUtils::MakeMaker cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VMS.pm 0c78ba02d6249dfcca12ac9886a7c7cfb60e77fe
+ExtUtils::MakeMaker cpan/ExtUtils-MakeMaker/lib/ExtUtils/MakeMaker.pm 830acdc810e2974d7fd4ec408ea1bfa825c75b69
+ExtUtils::MakeMaker cpan/ExtUtils-MakeMaker/lib/ExtUtils/MM_VMS.pm 1997912b5018970cdeb3dae8fd7e0c24f6e5d567
 ExtUtils::MakeMaker cpan/ExtUtils-MakeMaker/t/prereq.t 53bda2c549fd13a6b6c13a070ca6bc79883081c0
 ExtUtils::MakeMaker cpan/ExtUtils-MakeMaker/t/vstrings.t 90035a2bdbf45f15b9c3196d072d7cba7e662871
 Math::BigRat cpan/Math-BigRat/lib/Math/BigRat.pm 682352dde33638125ce12ca44990bd1cd44af4f8
-- 
1.9.5.msysgit.1

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @Leont

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

-----Original Message----- From​: sisyphus1@​optusnet.com.au
Sent​: Monday, November 09, 2015 9​:00 PM
To​: Steve Hay ; bulk88 via RT
Cc​: perl5-porters@​perl.org
Subject​: Re​: [perl #123440] Adding win32/GNUmakefile

But surely it should be allowable to have sh.exe in your path ?
That's why the "SHELL := cmd.exe" entry was placed in GNUmakefile in the
first place - and I'm sure that used to work.
But I've just checked (for the first time in a while) whether I can
build recent perl if I have sh.exe in the path, and I can't !!

One problem (probably *the* problem) is that the gmake-style Makefile
that EU​::MM generates does not specify a SHELL.
I don't know how or why that omission has come about.

Last December I opened an EU​::MM ticket about this​:
https://rt.cpan.org/Public/Bug/Display.html?id=101132

I ultimately provided a patch that was accepted and applied to EU​::MM
master as

Perl-Toolchain-Gang/ExtUtils-MakeMaker@06aeb80

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

@p5pRT
Copy link
Author

p5pRT commented Nov 10, 2015

From @sisyphus

From​: Leon Timmermans
Sent​: Tuesday, November 10, 2015 8​:11 PM
To​: Sisyphus
Cc​: Steve Hay ; perlbug ; Perl5 Porters
Subject​: Re​: [perl #123440] Adding win32/GNUmakefile

I ultimately provided a patch that was accepted and applied to EU​::MM
master as
Perl-Toolchain-Gang/ExtUtils-MakeMaker@06aeb80

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

@p5pRT
Copy link
Author

p5pRT commented Nov 23, 2015

From @sisyphus

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

@p5pRT
Copy link
Author

p5pRT commented Dec 27, 2015

From @sisyphus

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

@p5pRT
Copy link
Author

p5pRT commented Jan 21, 2016

From @sisyphus

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

@p5pRT
Copy link
Author

p5pRT commented Jan 22, 2016

From @bulk88

On Wed Jan 20 21​:00​:11 2016, sisyphus wrote​:

-----Original Message-----
From​: sisyphus1@​optusnet.com.au
Subject​: Re​: [perl #123440] Adding win32/GNUmakefile

Just a reminder that the problem still remains as of the release of
perl-5.23.5.
That is, perl-5.23.5 will not build on Windows using gmake if sh.exe is
in the path.

Still the same brokenness in perl-5.23.6 (released on 21 Dec).

Still broken in 5.23.7.

Cheers,
Rob

My gmake parallel branch https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126632 which has the .SHELL fix for gmake still hasn't been applied. It is a forgone conclusion TonyC will apply it since no other active committer touches Win32 code. So take it up with TonyC or rjbs why it is still broken.

--
bulk88 ~ bulk88 at hotmail.com

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2016

From @sisyphus

-----Original Message-----
From​: bulk88 via RT
Sent​: Saturday, January 23, 2016 7​:02 AM
To​: OtherRecipients of perl Ticket #123440​:
Cc​: perl5-porters@​perl.org
Subject​: [perl #123440] Adding win32/GNUmakefile

My gmake parallel branch https://rt-archive.perl.org/perl5/Ticket/Display.html?id=126632
which has the .SHELL fix for gmake still hasn't been applied. It is a
forgone conclusion TonyC will apply it since no other active committer
touches Win32 code. So take it up with TonyC or rjbs why it is still
broken.

It's not such a big issue for me that it hasn't been fixed yet - so long as
it's fixed in 5.24.

Seems that TonyC has just today applied your #126632 fixes - so that should
shut me up :-)
Thanks to both of you for your continued efforts.

Cheers,
Rob

@p5pRT
Copy link
Author

p5pRT commented May 13, 2016

From @khwilliamson

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

@p5pRT p5pRT closed this as completed May 13, 2016
@p5pRT
Copy link
Author

p5pRT commented May 13, 2016

@khwilliamson - Status changed from 'pending release' to 'resolved'

xenu added a commit to xenu/perl5 that referenced this issue Jan 28, 2021
Makefile.mk is redundant with GNUmakefile. See
https://www.nntp.perl.org/group/perl.perl5.porters/2021/01/msg258848.html
for more details.

We planned to remove it shortly after the introduction of GNUmakefile
but that slipped through the cracks for some reason:
Perl#14341
xenu added a commit to xenu/perl5 that referenced this issue Jan 28, 2021
Makefile.mk is redundant with GNUmakefile. See
https://www.nntp.perl.org/group/perl.perl5.porters/2021/01/msg258848.html
for more details.

We planned to remove it shortly after the introduction of GNUmakefile
but that slipped through the cracks for some reason:
Perl#14341
steve-m-hay pushed a commit that referenced this issue Jan 28, 2021
Makefile.mk is redundant with GNUmakefile. See
https://www.nntp.perl.org/group/perl.perl5.porters/2021/01/msg258848.html
for more details.

We planned to remove it shortly after the introduction of GNUmakefile
but that slipped through the cracks for some reason:
#14341
Corion pushed a commit to Corion/perl5 that referenced this issue Jun 20, 2021
Makefile.mk is redundant with GNUmakefile. See
https://www.nntp.perl.org/group/perl.perl5.porters/2021/01/msg258848.html
for more details.

We planned to remove it shortly after the introduction of GNUmakefile
but that slipped through the cracks for some reason:
Perl#14341
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant