> > 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. >
What about adding something similar to .ONESHELL that optionally enables this functionality? > 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. > It just occurred to me we wouldn't even be able to make use of the feature I stated because I switched to .ONESHELL last week. 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 > hm ... that's a nice optimization, and I don't see an obvious way around it for what I'm suggesting. -brian
_______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
