On Mon, Jun 30, 2025, at 2:21 PM, Paul D. Smith wrote:
> Follow-up Comment #6, bug #67265 (group make):
>> If you are determined that anything that looks like $(...) or ${...} must be
>> consumed by expansion, you could get the same effect by having $(file
>> REDIRECTION, CONTENTS) expand to a different sequence of characters, which
>> would then be recognized by the command processor as a built-in command.
> 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!!!"
But maybe we don't need to pursue this part of the conversation any more.
Expanding recipes line-by-line, only after all previous lines have been
executed, is sufficient to fix the bug in all the situations I can think of, so
I'm fine with dropping the idea of making $(file) itself be different.
>> If there is a regular stream of people being surprised by the existing
>> behavior of expanding all lines up front, that suggests pretty strongly that
>> nobody actually wants the existing behavior.
> I would not agree with that statement. Just because new makefile authors are
> surprised by some behavior, doesn't mean that *nobody* wants it. In this
> particular case I am more worried about whether there are situations in the
> probably millions of makefiles out there where this behavior is relied on and
> changing it would break things, than how unexpected the behavior is.
Hmm. Can we think of any constructs _besides_ $(file) where it matters?
$(file)
is not very often used according to
<https://codesearch.debian.net/search?q=%5C%24%5B(%7B%5Dfile%5Cs%20-filetype%3Ac%20-filetype%3Ac%2B%2B%20-filetype%3Aobjc%20-filetype%3Aobjc%2B%2B%20-filetype%3Aperl%20-filetype%3Apython%20-filetype%3Ago%20-filetype%3Ajava%20-filetype%3Aruby%20-filetype%3Avala%20-filetype%3Ajavascript%20-filetype%3Ajson&literal=0>
-- there's 79 pages of hits
but that's out of "130 GB of source code" and also a lot of the hits are
actually
*shell* constructs of the form
filetype=$(file foo)
which does something different (i.e. run the `file` command and stuff its
output into the `filetype` variable).
Notably, within the first two pages I see
https://sources.debian.org/src/libreoffice/4:25.2.3-2/solenv/gbuild/DotnetLibrary.mk/?hl=26#L26
and
https://sources.debian.org/src/libreoffice/4:25.2.3-2/solenv/gbuild/LinkTarget.mk/?hl=924#L924
both of which are doing the same thing as my test Makefile, expecting $(file)
within a multi-command recipe to execute _after_ previous commands in that
recipe. (I imagine that no one has noticed because the directory is usually
created some other way before the recipe runs.)
>> p.s. I do insist that this is a bug, not a feature request. The existing
>> behavior is strictly less useful than the requested behavior, and surprising
>> to boot.
> This is a definition disagreement, I suppose. For GNU Make I define a bug to
> be something that doesn't work the way it was intended to work. Being "less
> useful" doesn't make it a bug, it means it could be enhanced to be more
> useful.
We don't need to keep arguing about this either.
zw
