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 [email protected].
For more options, visit https://groups.google.com/d/optout.
