[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

[Paul D. Smith]

Follow-up Comment #4, bug #63650 (project make):

I don't think this is a bug.  Or, at least I don't think we can fix it.

In previous versions of GNU Make we did not add make variables to the
environment of the shell function regardless of their export status.  So for
example this makefile:

export FOO = bar
BAR = $(shell echo $$FOO)
all: ; @echo BAR=$(BAR)

would print *BAR=* in older versions of GNU Make.  In GNU Make 4.4 it will
print *BAR=bar*.


This was a problem for many reasons and was unexpected.  In GNU Make 4.4 we
changed this; from the NEWS file:

* 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.


In your situation this means that every time make wants to invoke a shell
using the $(shell ...) function it must expand all the makefile variables (the
same way that it would when invoking a recipe).  If makefile variables take a
long time to expand (for example, they require invoking a lot of other shell
functions) you get this sort of pathological behavior.

I'm not sure I see any way to address this, other than writing more reasonable
makefiles.  For example if you use this instead:

AAA := $(shell echo 1)
AAB := $(shell echo 2)
AAC := $(shell echo 3)
AAD := $(shell echo 4)
AAE := $(shell echo 5)
AAF := $(shell echo 6)

then you won't see this problem because variables will only ever be expanded
one time.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63650>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/