On Mon, 2025-06-30 at 15:03 -0400, Zack Weinberg wrote: > On Mon, Jun 30, 2025, at 2:21 PM, Paul D. Smith wrote: > > Follow-up Comment #6, bug #67265 (group make): > > Make's expansion rules are very simple. When some text undergoes > > expansion, make goes through the text and looks for un-escaped "$", > > and expands it. That's all. > > This part of the conversation is going to continue to go around in > circles as long as you keep responding to me saying "the expander > doesn't have to work the way it does today" with "but this is the way > it works today!!!"
That's not my argument. My argument is specifically that the proposal "treat $(file...) expansion differently" is simply not workable. But I agree we can dispense with the idea. > Can we think of any constructs _besides_ $(file) where it matters? Sure. Anywhere that a make function can interact with the underlying system, can be impacted by this. The most obvious ones other than $(file...) are $(shell...) and $(wildcard...). And that's not to mention Guile or C loadable functions that users might be creating. The problem is not coming up with situations where it _could_ matter. The problem is deciding if there are situations where it _does_ matter. I agree it's unlikely that someone relied on this behavior on purpose (although I've been wrong about this before). But I can envision situations where they are relying on it without really realizing it, such that their makefiles would break if it were changed.
