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

[Paul Smith]

On Thu, 2022-03-17 at 18:27 +0000, Martin Dorey wrote:
> That coped with -nj --no-print-directory on the one version of Make
> that I tested it with, but I don't know how portable that would
> prove.

Modern versions of make guarantee a canonical format of MAKEFLAGS such
that you can parse them relatively easily, and with confidence.

The details are in the manual I believe but the short is:

 * All options that have "short" variants with no arguments (for
   example --dry-run -> -n) are converted to the short variants and put
   into the first word, with no leading "-"
 * All other options are added after that.
 * Short options have a single dash prefix and if they have an argument
   it's attached to the option
 * Long options have a double-dash prefix (obviously) and if they have
   an argument it's attached to the option with an "="
 * Options that have both short and long forms, prefer the short form.

So, for -n, you can use:

$(findstring n,$(word 1,$(MAKEFLAGS)))

and it will expand to "n" if dry run is enabled (regardless of which
form the option was given in), or empty if not.

So, the OP could use something like this:

DRYRUN = $(findstring n,$(word 1,$(MAKEFLAGS)))

 main_target: create_logdirs
 $(MAKE) external_target $(if $(DRYRUN),,| tee logs/external_task.log)

There are other alternatives. For example, you could add "+" as a
prefix to the recipe in the create_logdirs so that the directories are
created even when "-n" is given.


But ultimately Martin's comment is correct: this is not a bug in make
and there's no possible way that make could do anything "better" than
what it does. At some level, especially if you're writing recursive
makefile environments, your recipes have to be written to be resilient
to the possibility that make was invoked with "-n".