Re: how to use a different /bin/sh with GNU Make?

[Mark Galeck]

Ha! That's golden Paul , thank you so much for telling me how to hack it.
It's easy for you to know exactly what lines to change, but believe me, for 
someone who is not involved in the maintenance of GNU Make, the code is very 
difficult to read and understand.  

Yes if I had a single "common" makefile included everywhere, yes I could just 
do the SHELL hack, but no...  there isn't one.

The reason why I was confused Sir... is very simple - your manual clearly and 
unequivocally says, that for every recipe line (unless ONESHELL is used) the 
new shell process is spawned.  So please forgive me for believing in the 
literal word of the manual. 

Again, thank you for pointing me how to hack this thing.  I really appreciate.  
Mark


      From: Paul Smith <address@hidden>
 To: Mark Galeck <address@hidden> 
Cc: "address@hidden" <address@hidden> 
 Sent: Tuesday, October 13, 2015 5:42 AM
 Subject: Re: how to use a different /bin/sh with GNU Make?
   
On Tue, 2015-10-13 at 12:11 +0000, Mark Galeck wrote:
> Well, the recipe I am using is the simplest possible recipe:
> 
> all:
>    echo $(SHELL)

Well that's certainly "simple enough" to allow the fast path method to
work.

> OK, what do you mean by "runs the command directly rather than
> invoking a shell" 

I mean that when make sees the command is simple enough, rather than
running a shell then having the shell run the command, make runs the
command directly without invoking the shell.  This saves an entire
fork/exec for simple commands, which is a significant performance
benefit.

> I know that Paul :)  Every child in kindergarten knows the SHELL hack.
> Works with one Makefile.  Does not work on a massively recursive
> system.  That is my problem.

Well, for someone who already knows about this you seemed really
confused about why your shell is not being invoked.

It's not necessarily true that it cannot work for a massively recursive
system.  It's true that it's very difficult for a badly designed
massively recursive system, where there's no common makefile which is
included by all the other makefiles such that you can't make any sort of
centralized change.

> I could (and I am doing it right now) grok the job.c file of GNU Make
> to figure out how to change it to accept my modified shell.  But it's
> not easy and I don't really want to hack GNU Make if I can help it.

All you have to do is change the list of UNIX shells to be empty:

diff --git a/job.c b/job.c
index 244def0..4b345b6 100644
--- a/job.c
+++ b/job.c
@@ -423,6 +423,7 @@ is_bourne_compatible_shell (const char *path)
 {
  /* List of known POSIX (or POSIX-ish) shells.  */
  static const char *unix_shells[] = {
+/*
    "sh",
    "bash",
    "ksh",
@@ -430,6 +431,7 @@ is_bourne_compatible_shell (const char *path)
    "zsh",


    "ash",
    "dash",
+ */
    NULL
  };
  const char **s;

Now make will not consider any shells to be POSIX shells, and it will
never choose the fast path.