[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled

From: Paul D. Smith
Subject: [bug #63650] Performance regression with EXPORT_ALL_VARIABLES enabled
Date: Fri, 13 Jan 2023 13:17:18 -0500 (EST)

Update of bug #63650 (project make):

              Item Group:                     Bug => Enhancement            


Follow-up Comment #5:

What about this idea: we would create a new environment when needed with all
variables expanded, as in current GNU Make 4.4.  Then instead of re-computing
it every time we want to run another command, we would only recompute it if
some make operation happened that might change it.  For example if we entered
a new rule (due to target-specific variables) or we modified a make variable
value, that would invalidate the environment.  If not, we could just re-use
the existing environment.

Running a shell command in itself, without setting a make variable, cannot
change the environment of a subsequent shell command.  At least, I can't think
of a way it could happen.

In that case, the example makefile below with the rule:

        echo ${AAA}
        echo ${AAB}
        echo ${AAC}
        echo ${AAD}
        echo ${AAE}
        echo ${AAF}

would still invoke the shell more often in order to compute the environment
for the first *echo* line above, but then, since none of these lines alter any
state in make itself, we could re-use that same environment.

But, actually maybe that's not good enough.  The value of the variable could
refer to functions like *$(wildcard ...)*, which would depend on the state of
the filesystem and so expand differently in the second line of the recipe than
they did for the first line of the recipe, if we didn't recompute the

Hm.  I'm going to convert this to an enhancement request.  I can't see a way
to fix it right now.


Reply to this item at:


Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]