Re: Changes to --printf-directory handling in Make 4.4

[Paul Smith]

On Mon, 2023-07-03 at 16:32 +0100, Jonathan Wakely wrote:
> This left me puzzled for a while, but what's happening is that the output of
> $(shell $(MAKE) bar)
> now includes the --print-directory output, so where the recipe for
> 'foo' used to do simply `make baz` now it is `make make[1] Entering
> directory etc.`
> 
> Is this an intended consequence of the changes to --print-directory
> handling in 4.4?

I don't think it's related to that.

I think it's related to this change:

> * WARNING: Backward-incompatibility!
>   Previously makefile variables marked as export were not exported to commands
>   started by the $(shell ...) function.  Now, all exported variables are
>   exported to $(shell ...).  If this leads to recursion during expansion, then
>   for backward-compatibility the value from the original environment is used.
>   To detect this change search for 'shell-export' in the .FEATURES variable.

Previously the only environment variables passed to $(shell ...)
commands were the ones inherited from the parent environment; changes
made in the makefile were not sent to $(shell ...).  Now, exported
variables (such as MAKEFLAGS) set in the makefile itself are also
passed to $(shell ...) commands.

You can verify this by modifying the $(shell ...) to echo $$MAKEFLAGS
and see what the difference is between the two versions.

> I can restore the old behaviour of my makefile by adding -s to the
> make command invoked using $(shell), is that the expected way to fix
> this problem?

I'm not 100% sure I know what you want to do, but I do recommend that
if you want your make invoked by $(shell ...) to behave a certain way
you explicitly ask for that behavior; so if you don't want it to show
directory changes adding -s is the right way IMO.