Hi, 2018/8/7 Tue 10:48:19 UTC+9 Michael Soyka wrote: > On 8/6/2018 8:45 PM, Ken Takata wrote: > > Hi, > > > > 2018/8/7 Tue 5:58:56 UTC+9 Bram Moolenaar wrote: > >>> Problem > >>> ------- > >>> The if-tests in the makefile src/po/Make_ming.mak do not do what is > >>> intended. Furthermore, they do not allow for the possibility that the > >>> value of the make variable SHELL might include a path specification. > >>> > >>> > >>> Issues > >>> ------ > >>> 1. The if-tests that reference the SHELL make variable do not do what is > >>> intended. > >>> > >>> There are four if-tests in the file Make-ming.mak of the form: > >>> > >>> ifeq (sh.exe, $(SHELL)) > >>> > >>> As coded, this condition will be true if and only if the value of > >>> SHELL is "sh.exe". However, in all four cases, the if-else blocks > >>> are > >>> incorrectly ordered. For example, in the current makefile: > >>> > >>> ifeq (sh.exe, $(SHELL)) > >>> VIMRUNTIME = ..\..\runtime > >>> else > >>> VIMRUNTIME = ../../runtime > >>> endif > >>> > >>> should instead be: > >>> > >>> ifeq (sh.exe, $(SHELL)) > >>> VIMRUNTIME = ../../runtime > >>> else > >>> VIMRUNTIME = ..\..\runtime > >>> endif > >>> > >>> Perhaps when these if-tests were added in commit 8889a5c305, > >>> "ifneq" was intended. However, see the next point. > >>> > >>> 2. The if-tests do not allow for the possibility that the value of SHELL > >>> might include a path specification. > >>> > >>> Using the version of mingw/msys I've downloaded from Source Forge, my > >>> version of make defines SHELL to be "C:\MinGW\msys\1.0\bin\sh.exe". > >>> The above if-tests will report that this value is not equal to > >>> "sh.exe" even though we would like it to report a unix shell is being > >>> provided. A way to address this would be to use the gnu make > >>> function > >>> "notdir", which leads us to rewriting the above as: > >>> > >>> ifeq (sh.exe, $(notdir $(SHELL))) > >>> VIMRUNTIME = ../../runtime > >>> else > >>> VIMRUNTIME = ..\..\runtime > >>> endif > >>> > >>> The other three if-tests should be modified in the same way. > >>> > >>> I'll point out that SHELL can also be specified on the make command > >>> line and so its value could include a path. > >>> > >>> > >>> Proposed patch > >>> -------------- > >>> I've attached a patch that addresses the if-test issues I've raised. > >> It appears src/Make_cyg_ming.mak also does this: > >> > >> ifneq (sh.exe, $(SHELL)) > >> DEL = rm > >> MKDIR = mkdir -p > >> DIRSLASH = / > >> else > >> DEL = del > >> MKDIR = mkdir > >> DIRSLASH = \\ > >> endif > >> > >> And src/GvimExt/Make_ming.mak > >> > >> ifneq (sh.exe, $(SHELL)) > >> DEL = rm > >> else > >> DEL = del > >> endif > >> > >> Is this really wrong? > > No. This is really confusing, but this is correct. > > > > If the makefile is executed by the "mingw32-make" command from cmd.exe, > > $SHELL is set to "sh.exe" (without any path). In this case, unix-like > > commands > > might not work and dos-style path is needed. > I run mingw32-make from a command window and, as I've stated, the value > of SHELL includes a path specification.
Ah, running from cmd.exe or bash was not the cause of the difference. The difference is caused by the $PATH. If sh.exe is found in the $PATH, $SHELL is set to the full path of the sh.exe. If it isn't found, $SHELL is set to "sh.exe" without the path specification. So the conclusion is still not changed. The makefiles are correct. If $SHELL is exactly same as "sh.exe", unix-like commands are not available and paths must be dos-style, otherwise unix-like commands and unix-style paths can be used. > > If it is executed by the "mingw32-make" command from a unix-like shell, > > $SHELL is set with the actual path of sh.exe (e.g. > > "C:/msys64/usr/bin/sh.exe"). > > In this case, unix-like commands can be used. > > > > If it is executed by the "make" command from cmd.exe, $SHELL is set to > > "/bin/sh". If the "make" command is in the $PATH, other unix-like commands > > might also work. > > > > If it is executed by the "make" command from a unix-like shell, > > $SHELL is set with the unix-style path (e.g. "/bin/bash"). > > In this case, unix-like commands can be used. > I don't mean to be argumentative but if you're testing for the use of a > unix shell, the result should be the same whether or not SHELL includes > a path specification. I'm proposing not only a fix but improved clarity > as well. > > > > > > BTW, > > > >>> Using the version of mingw/msys I've downloaded from Source Forge, my > >>> version of make defines SHELL to be "C:\MinGW\msys\1.0\bin\sh.exe". > > MinGW and msys-1.0 seems to be abandoned. New features like DirectWrite and > > color emoji cannot be compiled by them. > > I recommend using MinGW-w64 and MSYS2. > > > > Regards, > > Ken Takata > > > OK but I use MinGW-w64 and msys/1.0 and have no build issues. Just curious, how did you install them? MinGW-w64 from https://sourceforge.net/projects/mingw-w64/ doesn't have msys-1.0 nor MSYS2. 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.
