Closed p5pRT closed 8 years ago
p5pRT
commented
9 years ago 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
p5pRT
commented
9 years ago 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
commented
9 years ago The RT System itself - Status changed from 'new' to 'open'
p5pRT
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago -----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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago -----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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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
commented
9 years ago 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.exeHowever\, 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
commented
9 years ago Any chance to have win32/GNUmakefile in 5.22?
-- kmx
p5pRT
commented
8 years ago 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
commented
8 years ago 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
commented
8 years ago 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
commented
8 years ago 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
commented
8 years ago p5pRT
commented
8 years ago p5pRT
commented
8 years ago 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
p5pRT
commented
8 years ago @tonycoz - Status changed from 'open' to 'pending release'
p5pRT
commented
8 years ago 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-archive.perl.org/perl5/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
p5pRT
commented
8 years ago 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-archive.perl.org/perl5/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.
p5pRT
commented
8 years ago 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-archive.perl.org/perl5/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
p5pRT
commented
8 years ago On Sat\, Nov 07\, 2015 at 03:02:40PM -0800\, bulk88 via RT 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-archive.perl.org/perl5/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
p5pRT
commented
8 years ago -----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
p5pRT
commented
8 years ago On Sun Nov 08 16:33:18 2015\, sisyphus wrote:
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
p5pRT
commented
8 years ago p5pRT
commented
8 years ago p5pRT
commented
8 years ago p5pRT
commented
8 years ago p5pRT
commented
8 years ago On Sun\, Nov 08\, 2015 at 11:40:14PM -0800\, bulk88 via RT wrote:
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
p5pRT
commented
8 years ago On 8 November 2015 at 00:22\, bulk88 via RT \perlbug\-followup@​perl\.org wrote:
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-archive.perl.org/perl5/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.)
p5pRT
commented
8 years ago -----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
p5pRT
commented
8 years ago 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
p5pRT
commented
8 years ago -----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
p5pRT
commented
8 years ago 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
Migrated from rt.perl.org#123440 (status was 'resolved')
Searchable as RT123440$