(We generally prefer to use inline replies on the GNU lists, rather
than top-posted replies, thanks)
On Mon, 2022-03-21 at 13:22 +0000, Ambrus Sumegi wrote:
> 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`
So if someone runs make -n it would be OK if only the make was invoked,
without actually sending any of the output to the tee (because clearly
the tee would not be invoked)? That idea seems just as fraught, of not
moreso, as the original behavior.
What if your recipe looked like this:
test -f afile || $(MAKE) -C foo
If you change your makefile to use the putative function like this:
test -f afile || $(make -C foo)
Are you saying that if "make -n" is invoked this recipe will ALWAYS run
the sub-make, regardless of whether the "afile" file exists or not?
If you check makefiles out in the world you'll see that many times the
recipe lines that are used to invoke sub-makes are complex with lots of
additional shell operations in the same recipe line. IMO a facility
that reached into the middle of all that scripting and plucked out the
sub-make by itself and ran it without any of that surrounding context,
when make -n was given, would be at least as dangerous as what we have
now.
