On Sun, Sep 5, 2021 at 1:16 AM Eli Zaretskii <
eliz@gnu.org> wrote:
This part I don't yet understand. Why invoking 'ls' via PowerShell
works whereas invoking it directly doesn't? You never explained
that. So I don't think I have a clear enough understanding of what you
wanted to do and how.
Because `ls` is a built-in in PowerShell.
If 'ls' in your case is a shell command, then Make doesn't know about
that. Make on Windows only knows about built-in commands of 2 shells:
sh.exe and cmd.exe, and it applies them according to the current
shell. So what you wanted to do (AFAIU) wouldn't work on any Posix
system either, and thus it isn't supposed to work on Windows.
PowerShell has built-ins for many of the coreutils. `ls` is expected to work on POSIX, and does work in PowerShell, as a built-in.
My suggestion for running commands that are only known to some
non-standard shell is either write the commands in recipes to invoke
the shell explicitly, or create a batch file, in your case ls.cmd,
which would call PowerShell internally, and put it somewhere on PATH.
Then everything should work without any tricks.
I'm trying to write a particular Makefile that works on both Windows and Linux without requiring my users to add a bunch of binaries to either system. If Make executed each command in the chosen shell as advertised, my attempt would succeed.
The manual isn't supposed to explain how to trick Make into doing
something it wasn't supposed to do. Of course, if the GNU Make
maintainers decide to document these internals in the manual, it's
their prerogative.
I'm just trying to trick Make into doing what it _says_ it does. This optimization to skip the shell is a regression when Make doesn't sufficiently understand the selected shell. Perhaps the optimization should only be enabled for shells that Make understands. Then no explanation of the optimization would be necessary because it would be completely transparent to users.