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.
