On 8/7/2018 1:26 PM, Ken Takata wrote:
Hi,
2018/8/8 Wed 1:46:02 UTC+9 Michael Soyka wrote:
On 8/7/2018 11:46 AM, Ken Takata wrote:
Hi,
2018/8/8 Wed 0:39:08 UTC+9 Bram Moolenaar wrote:
Ken Takata wrote:
2018/8/7 Tue 10:48:19 UTC+9 Michael Soyka wrote:
On 8/6/2018 8:45 PM, Ken Takata wrote:
[...]
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 someone specifies SHELL=sh.exe on the make command line then it is
not correct.
Even if someone set $SHELL explicitly, it is overwritten by mingw32-make.exe.
I am running mingw32-make.exe version 4.2.1 in a cmd window under
Windows 10. If i create a makefile with an "all" target and "echo
$(SHELL) recipe, here's what I see:
1. If I run mingw32-make with no arguments, SHELL is displayed as
C:/MinGW/msys/1.0/bin/sh.exe
2. If I run mingw32-make with the argument SHELL=sh.exe, SHELL is
displayed as C:/MinGW/msys/1.0/bin/sh.exe
3. If I run mingw32-make with argument SHELL=cmd.exe, SHELL is
displayed as cmd.exe.
If sh.exe is not on the path, case 1 instead displays "sh.exe" and case
2 results in a make exception abort.
Case number 3 displays the same result whether or not cmd.exe is on the
path.
This behavior is somewhat inconsistent with gnu make documented behavior
which states that variables specified on the command line override those
specified in the makefile, unless the override directive is used:
https://www.gnu.org/software/make/manual/html_node/Overriding.html#Overriding
It is also inconsistent with gnu make documented behavior which says
that %COMSPEC% is used if SHELL is not defined:
https://www.gnu.org/software/make/manual/html_node/Choosing-the-Shell.html#index-shell_002c-in-DOS-and-Windows
How does one proceed when documented behavior appears to conflict with
actual behavior? Apparently, mingw behavior is different.
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.
Since this is confusing, it would be good to add an explanation. How
about this:
# About the "sh.exe" condition, as explained by Ken Takata:
Well, my name is not important here. ;-)
So we have someone to blame^Wask when it turns out wrong :-).
I didn't know how to detect if unix-like commands can be used from a
makefile before seeing these makefiles.
#
# If the makefile is executed and sh.exe is not found in $PATH, then
$SHELL is
Isn't it better to mention the "mingw32-make" command?
# set to "sh.exe" (without any path). In this case, unix-like commands
might
# not work and a dos-style path is needed.
#
# If the makefile is executed and sh.exe IS found in $PATH, then $SHELL
is set
This is the same.
# 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.
#
ifneq (sh.exe, $(SHELL))
Do you mean like this:
# About the "sh.exe" condition, as explained by Ken Takata:
#
# If the makefile is executed with mingw32-make and sh.exe is not found
in
# $PATH, then $SHELL is set to "sh.exe" (without any path). In this
case,
# unix-like commands might not work and a dos-style path is needed.
#
# If the makefile is executed with mingw32-make and sh.exe IS found in
$PATH,
# then $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.
Yeah, it's okay.
Regards,
Ken Takata
I don't see the need for this. If the purpose of the if-tests is to
determine which shell is being used, what's wrong with using the notdir
function to remove any path information that might be there, yielding
either "sh.exe" or "cmd.exe" in the conditional? Doing this would
appear to make the above list of special cases irrelevant, unnecessary
and reduce confusion.
When "cmd.exe" is used as a shell, $SHELL is exactly set to "sh.exe".
When "sh.exe" is used as a shell, $SHELL includes its path.
From my perspective, the makefiles should not care how SHELL was set,
only which shell it is.
I must be missing something but I don't know what.
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.
