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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
