Re: Order of expansion of recipe lines

[Paul Smith]

On Mon, 2016-03-14 at 10:24 -0600, Brian Vandenberg wrote:
> This could be remedied by making it fork before recipe expansion so
> the expansion happened in a sub-process.  On the plus side it
> eliminates concerns of macros slowing down the parent make process
> but it breaks backward compatibility for recipes using $(eval) that
> can induce dynamic behavior during the recipe execution phase (eg,
> update variables during the recipe expansion).

As you say, done simply this would be a major backward-incompatibility
and very complicated to explain as well.  To avoid the backward
-incompatibility we'd need to do some kind of semi-evaluation that only
processed functions we know (a) might have side-effects, and (b) will
expand to the empty string.

Also complicating things could be the printing of the command line to
be invoked (which can only happen after expansion), combined with
output sync: maybe this would just work, not sure.  It would need to be
checked.  Definitely output sync would be even more critical than
previously because at least today (for non-recursive builds) you know
that all the command lines are printed serially, even if command output
appears in parallel.

Another concern is that running significant code in the forked process
before the exec would mean we'd have to give up the performance gains
achieved by switching back to vfork(), and switch permanently to
fork().  See the discussion in https://savannah.gnu.org/bugs/?44555