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