Re: Bug: make cannot run testdir/Make_ming.mak using a unix shell under Windows 10
Hi mike,
2016/9/5 Mon 23:34:05 UTC+9 Michael Soyka wrote:
> Hi Ken,
>
> On 9/5/2016 12:26 AM, Ken Takata wrote:
> > Hi mike,
> >
> > 2016/9/5 Mon 10:07:00 UTC+9 Michael Soyka wrote:
> >> The makefile testdir/Make_ming.mak contains statements of the form:
> >>
> >> if exist test.ok $(DEL) test.ok
> >>
> >> which can only be executed by one of the DOS/Windows command shells such
> >> as command.com or cmd.exe
> >>
> >> My version of make, gnu 3.82.90, sets the SHELL make variable to the
> >> value "C:/MinGW/msys/1.0/sh.exe", a unix shell, and so all such
> >> if-statements fail.
> >>
> >> This can be sidestepped by setting SHELL=cmd.exe on the make command
> >> line but then unix utilities such as "rm" are used instead of "del" and
> >> DIRSLASH is set to "/" instead of "\" and so vim.exe cannot be launched
> >> to run the test (cmd.exe does not accept forward slashes in paths).
> >> This new problem is caused by an incorrectly constructed if-test in the
> >> makefile:
> >>
> >> ifneq(sh.exe,$(SHELL))
> >>
> >> followed by unix-style definitions. I think that the author had
> >> intended this
> >>
> >> ifeq(sh.exe, $(SHELL))
> > No, this is confusing but intended. Please try the following Makefile:
> >
> >all:
> > echo $(SHELL)
> >
> > If you run mingw32-make.exe (not make.exe) on cmd.exe, you will see the
> > following result:
> >
> >C:\tmp>\msys32\mingw32\bin\mingw32-make.exe
> >echo sh.exe
> >sh.exe
> No, this is not what I see. I see "C:/MinGW/msys/1.0/sh.exe"
> >
> > Other results are...
> >
> > make.exe on cmd.exe:
> >
> >C:\tmp>\msys32\usr\bin\make.exe
> >echo /bin/sh
> >make: echo: Command not found
> >make: *** [Makefile.mingw:2: all] Error 127
> >
> > This doesn't work as expected.
> >
> > mingw32-make.exe on bash.exe:
> >
> >$ mingw32-make
> >echo C:/msys32/usr/bin/sh.exe
> >C:/msys32/usr/bin/sh.exe
> >
> > make.exe on bash.exe:
> >
> >$ make
> >echo /bin/sh
> >/bin/sh
> >
> >
> > Normally, mingw32-make should be used when the shell is cmd.exe.
> > (I don't know when the shell is bash.exe.)
>
> My apologies for not being clearer. I am running mingw32-make. I did
> exactly what you suggested above and got "C:/MinGW/msys/1.0/sh.exe" for
> SHELL. In the interest of full disclosure, I'm using TDM-GCC-64 to build
> Vim and run the tests. It does not include a unix shell. Its version of
> make apparently looks for and finds one in my MinGW/msys installation
> which is on my path.
Ah, reproduced.
When I add the msys2 directory to the PATH, mingw32-make finds sh.exe and
the SHELL becomes a full path of the sh.exe (e.g. c:/msys64/usr/bin/sh.exe)
even if I run mingw32-make on cmd.exe, and the sh.exe is used as a shell.
If mingw32-make cannot find sh.exe from the PATH, the SHELL is set to "sh.exe"
(without path) and actually cmd.exe is used as a shell.
So the following condition is still correct (if a user doesn't set the SHELL
explicitly):
ifneq (sh.exe, $(SHELL))
# The shell is sh.exe.
else
# The shell is cmd.exe.
endif
> Given all your examples above, if the makefile must include unix shell
> support, wouldn't the better implementation have been:
>ifeq("cmd.exe", $(SHELL))
> followed by the DOS definitions? This covers SHELL being "sh", "/bin/sh" or
> whatever. That said, I still claim that
>ifeq("cmd.exe", $(notdir $(SHELL)))
> is the right thing to do in case the value of SHELL includes a path.
>
> Again, I see this discussion if ifneq/ifeq statements as somewhat irrelevant
> since the "if exist" statements in the makefile assume/demand a cmd shell.
Yeah, I understand that the actual problem is that "if exist ..." doesn't work
when sh.exe is used as a shell, but I wanted to make clear about the SHELL
condition at first.
> >> This is all interesting but mostly irrelevant. The bottom line is that
> >> a DOS shell must be used and so my suggestion is:
> >>
> >> 1. remove the if-block that defines the unix utilities and retain
> >> the else-block, and
> >>
> >> 2. define SHELL=cmd.exe in the makefile.
If you write a patch for this, I will test it.
> Believe me, I fully understand that it's far-fetched that no one else
> has seen this problem before. I can't explain that either!
Maybe, most Windows developers here use MSVC mainly?
Regards,
Ken Takata
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Bug: make cannot run testdir/Make_ming.mak using a unix shell under Windows 10
Hi Ken,
On 9/5/2016 12:26 AM, Ken Takata wrote:
Hi mike,
2016/9/5 Mon 10:07:00 UTC+9 Michael Soyka wrote:
The makefile testdir/Make_ming.mak contains statements of the form:
if exist test.ok $(DEL) test.ok
which can only be executed by one of the DOS/Windows command shells such
as command.com or cmd.exe
My version of make, gnu 3.82.90, sets the SHELL make variable to the
value "C:/MinGW/msys/1.0/sh.exe", a unix shell, and so all such
if-statements fail.
This can be sidestepped by setting SHELL=cmd.exe on the make command
line but then unix utilities such as "rm" are used instead of "del" and
DIRSLASH is set to "/" instead of "\" and so vim.exe cannot be launched
to run the test (cmd.exe does not accept forward slashes in paths).
This new problem is caused by an incorrectly constructed if-test in the
makefile:
ifneq(sh.exe,$(SHELL))
followed by unix-style definitions. I think that the author had
intended this
ifeq(sh.exe, $(SHELL))
No, this is confusing but intended. Please try the following Makefile:
all:
echo $(SHELL)
If you run mingw32-make.exe (not make.exe) on cmd.exe, you will see the
following result:
C:\tmp>\msys32\mingw32\bin\mingw32-make.exe
echo sh.exe
sh.exe
No, this is not what I see. I see "C:/MinGW/msys/1.0/sh.exe"
Other results are...
make.exe on cmd.exe:
C:\tmp>\msys32\usr\bin\make.exe
echo /bin/sh
make: echo: Command not found
make: *** [Makefile.mingw:2: all] Error 127
This doesn't work as expected.
mingw32-make.exe on bash.exe:
$ mingw32-make
echo C:/msys32/usr/bin/sh.exe
C:/msys32/usr/bin/sh.exe
make.exe on bash.exe:
$ make
echo /bin/sh
/bin/sh
Normally, mingw32-make should be used when the shell is cmd.exe.
(I don't know when the shell is bash.exe.)
My apologies for not being clearer. I am running mingw32-make. I did
exactly what you suggested above and got "C:/MinGW/msys/1.0/sh.exe" for
SHELL. In the interest of full disclosure, I'm using TDM-GCC-64 to build
Vim and run the tests. It does not include a unix shell. Its version of
make apparently looks for and finds one in my MinGW/msys installation
which is on my path.
Given all your examples above, if the makefile must include unix shell support,
wouldn't the better implementation have been:
ifeq("cmd.exe", $(SHELL))
followed by the DOS definitions? This covers SHELL being "sh", "/bin/sh" or
whatever. That said, I still claim that
ifeq("cmd.exe", $(notdir $(SHELL)))
is the right thing to do in case the value of SHELL includes a path.
Again, I see this discussion if ifneq/ifeq statements as somewhat irrelevant since the
"if exist" statements in the makefile assume/demand a cmd shell.
but this won't work either because the value of SHELL will include a
full path, if make is allowed to define it.
The correct construct is this:
ifeq(sh.exe, $(notdir $(SHELL)))
which strips the path information from SHELL before the comparison.
This is all interesting but mostly irrelevant. The bottom line is that
a DOS shell must be used and so my suggestion is:
1. remove the if-block that defines the unix utilities and retain
the else-block, and
2. define SHELL=cmd.exe in the makefile.
I haven't tried this yet.
Does this work both on cmd.exe and bash.exe?
Regards,
Ken Takata
I build Vim and run the tests in a cmd.exe shell. My experience is that
the two suggestions I make above make it possible for me to run all the
tests without error. If I don't go out of my way to specify SHELL
somehow, either in the makefile or on the command line, mingw32-make
generates errors when it tries to execute the "if exist" statements.
Believe me, I fully understand that it's far-fetched that no one else
has seen this problem before. I can't explain that either!
-mike
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Bug: make cannot run testdir/Make_ming.mak using a unix shell under Windows 10
Hi mike, 2016/9/5 Mon 10:07:00 UTC+9 Michael Soyka wrote: > The makefile testdir/Make_ming.mak contains statements of the form: > >if exist test.ok $(DEL) test.ok > > which can only be executed by one of the DOS/Windows command shells such > as command.com or cmd.exe > > My version of make, gnu 3.82.90, sets the SHELL make variable to the > value "C:/MinGW/msys/1.0/sh.exe", a unix shell, and so all such > if-statements fail. > > This can be sidestepped by setting SHELL=cmd.exe on the make command > line but then unix utilities such as "rm" are used instead of "del" and > DIRSLASH is set to "/" instead of "\" and so vim.exe cannot be launched > to run the test (cmd.exe does not accept forward slashes in paths). > This new problem is caused by an incorrectly constructed if-test in the > makefile: > >ifneq(sh.exe,$(SHELL)) > > followed by unix-style definitions. I think that the author had > intended this > >ifeq(sh.exe, $(SHELL)) No, this is confusing but intended. Please try the following Makefile: all: echo $(SHELL) If you run mingw32-make.exe (not make.exe) on cmd.exe, you will see the following result: C:\tmp>\msys32\mingw32\bin\mingw32-make.exe echo sh.exe sh.exe Other results are... make.exe on cmd.exe: C:\tmp>\msys32\usr\bin\make.exe echo /bin/sh make: echo: Command not found make: *** [Makefile.mingw:2: all] Error 127 This doesn't work as expected. mingw32-make.exe on bash.exe: $ mingw32-make echo C:/msys32/usr/bin/sh.exe C:/msys32/usr/bin/sh.exe make.exe on bash.exe: $ make echo /bin/sh /bin/sh Normally, mingw32-make should be used when the shell is cmd.exe. (I don't know when the shell is bash.exe.) > but this won't work either because the value of SHELL will include a > full path, if make is allowed to define it. > > The correct construct is this: > >ifeq(sh.exe, $(notdir $(SHELL))) > > which strips the path information from SHELL before the comparison. > > This is all interesting but mostly irrelevant. The bottom line is that > a DOS shell must be used and so my suggestion is: > >1. remove the if-block that defines the unix utilities and retain > the else-block, and > >2. define SHELL=cmd.exe in the makefile. I haven't tried this yet. Does this work both on cmd.exe and bash.exe? Regards, Ken Takata -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Bug: make cannot run testdir/Make_ming.mak using a unix shell under Windows 10
The makefile testdir/Make_ming.mak contains statements of the form: if exist test.ok $(DEL) test.ok which can only be executed by one of the DOS/Windows command shells such as command.com or cmd.exe My version of make, gnu 3.82.90, sets the SHELL make variable to the value "C:/MinGW/msys/1.0/sh.exe", a unix shell, and so all such if-statements fail. This can be sidestepped by setting SHELL=cmd.exe on the make command line but then unix utilities such as "rm" are used instead of "del" and DIRSLASH is set to "/" instead of "\" and so vim.exe cannot be launched to run the test (cmd.exe does not accept forward slashes in paths). This new problem is caused by an incorrectly constructed if-test in the makefile: ifneq(sh.exe,$(SHELL)) followed by unix-style definitions. I think that the author had intended this ifeq(sh.exe, $(SHELL)) but this won't work either because the value of SHELL will include a full path, if make is allowed to define it. The correct construct is this: ifeq(sh.exe, $(notdir $(SHELL))) which strips the path information from SHELL before the comparison. This is all interesting but mostly irrelevant. The bottom line is that a DOS shell must be used and so my suggestion is: 1. remove the if-block that defines the unix utilities and retain the else-block, and 2. define SHELL=cmd.exe in the makefile. -mike -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
