On Thu, Jan 5, 2023, at 6:47 PM, Karl Berry wrote: > Please excuse my curmudgeonness, but it's not clear to me that avoiding > sed is worth these hassles in working around the implementation-specific > bugs in the automatic variables.
It seems to me that this would be worth doing *if* we could get it to the point where gmake (and any other implementation with similar optimizations) didn't need to invoke a shell for the command at all. I thought the rules for that were documented but I can't find them at the moment, and I got lost in gmake's job.c's maze of #ifdefs; anyone know what they are? It might also be worth doing if we could guarantee that `sed` would not be used by *any* rules, as that would be a solid step in the direction of removing `sed` from the set of shell utilities potentially needed at build time for a generic package (of course, if the package's own build logic uses sed, there's nothing we can do about that). ISTR there are several existing automake rules with complex embedded shell scripts that use sed, though. zw
