> From: "Christian Jullien" <eli...@orange.fr> > Cc: <make-w32@gnu.org> > Date: Thu, 23 Jan 2020 21:07:26 +0100 > > Perhaps my sample was too simple. > If I supply a Makefile that can work with or without sh.exe presence (on any > user machines) I must rely on what make knows about the shell.
I'm saying such strategy is not the best one on Windows, because there are too many variables the name of the shell doesn't capture. Even if you have some sh.exe somewhere, you cannot know what kind of shell is it (Bash? zsh? something else?) and what exactly is it capable of on Windows. Programs that can be expected to be found on Unix might exist on Windows as well, but you cannot be sure. So a better strategy is to leave it up to the user to decide whether to run in Unix mode or in Windows mode, and whether to call, say, 'del' or 'rm'. Another, better method of detecting whether you are on Windows is to probe the $(OS) variable: all modern versions of Windows have it set, so your probability of a correct decision is much higher in that case. (But issues with what commands to employ still apply even in that case.) > Another example, Cygwin which provides a sh.exe also dir.exe which gives a > different output. If SHELL is sh.exe or cmd.exe output is different That's the same problem as the one with having 'find' from GNU Findutils or from Windows. It's part of the "which commands to invoke" issue discussed above, nothing new. > For my need, which is to have a gnumake coming with tcc.exe, I know how to > automatically patch and build make with sh.exe replaced by cmd.exe in source > file. So it's not a problem for me. I just wanted to point out something > which I find not consistency (aka a bug). It is a subtle issue, but I don't consider it a bug, since GNU Make on Windows behaves like that since its first ported version. You need to be aware of that subtlety, but once you are, it is rarely a real issue in practice. Maybe we could remove that nowadays, but I have no way of knowing what, if anything, that will break, and no motivation to work on a change that can potentially destabilize what has been a very stable program.