RE: GNU Make bug report: broken dry-run functionality with sub-make invocations

[Ambrus Sumegi]

If the invocation is a function, i.e., `$(make,"external_target") | tee 
logs/external_task.log` then Make knows exactly where the call to the sub-make 
ends without having to parse a shell command. So, when running with the -n 
switch, it can simply print "make external_target | tee logs/external_task.log" 
and proceed to show the output of `make external_target -n`

-----Original Message-----
From: Paul Smith <psmith@gnu.org>
Sent: 21 March 2022 14:18
To: Ambrus Sumegi <Ambrus.Sumegi@arm.com>; bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make 
invocations

On Mon, 2022-03-21 at 09:34 +0000, Ambrus Sumegi wrote:
> For the record, I’ve thought of a sort-of-solution to the “would you
> have Make parse the shell command” question over the weekend. If the
> sub-make was called through a function rather than a variable, the
> whole issue could be a lot more contained. Having $(make, “<arguments
> passed to sub-make>”) as the canonical form of invoking other Make
> instances could guarantee that no other program gets called when the
> -n switch is used. This way any elaborate multi-line command
> containing $(MAKE) could more or less be fixed with a sed command to
> completely eliminate this problem class.

I don't see how this would work.

The command you wanted to run was:

    $(MAKE) external_target | tee logs/external_task.log

You wanted to pipe the output of the make command to another command.
How does putting make in a function allow this to happen?

> Of course, one could still do something like $(make, $(shell
> (“some_reckless_command”)), but it would be more obvious, and Make
> could output an explicit warning about a shell being called together
> with the sub-make invocation, or even refuse to execute said shell
> call. Since on Fri 18/03/2022 20:14, psmith@gnu.org pointed out that
> this is also a potential security problem, a future release could
> deprecate the $(MAKE) variable and switch to the function-based
> invocation, with shell calls disabled within it by default for the
> sake of that extra bit of security.

It's simply not possible to make this change.  People want to do all kinds of 
complicated things before or after or instead of invoking the sub-make, so the 
full power of the shell needs to be available.

If you wanted to simply run a make command with no surrounding shell 
operations, then running:

    $(MAKE) ...

all by itself _already_ does exactly what you want.  It's only when you need to 
add extra operations into the same recipe line that you run into problems with 
"-n", and that's exactly the place where using a make function instead won't 
work.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.