On Mon, Jun 30, 2025, 9:14 AM Zack Weinberg <invalid.nore...@gnu.org> wrote:
> Follow-up Comment #5, bug #67265 (group make):
>
>
> > We're not going to make $(file...) a special case that expands
> differently
> > than everything else.
>
> I'm surprised you insist on this. There is plenty of precedent for using
> the
> same notation for expandable and non-expandable primitives: both Lisp and
> TeX
> do this and nobody minds.
>
> 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.
> For
> example
>
>
> goal:
> $(file > dest, contents)
>
> could become
>
> goal:
> //gnumake-builtins/file > dest contents
>
>
> I think this is an inferior alternative to special casing $(file) within
>
This sounds really inconsistent and confusing to me.
You can make a case for not expanding all the recipe lines up front, but it
would also lead to a behavior difference in .ONESHELL versus normal
recipes, and IMO one shell is the more useful behavior and supporting it
well is something to make should try to do.
commands, though, because it means inventing a second construct like
> //gnumake-builtins/ and worrying about what happens if someone writes that
> manually. Not to mention that the contents now have to be quoted somehow.
>
> > There's an argument to be made that the way make handles expansion of
> recipes
> > is wrong, and that it should expand each line in a recipe separately just
> > before it's going to be executed, instead of all lines being expanded up
> > front.
>
> I would also be fine with that as a resolution. 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.
>
> 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.
>
No, not true. Shell is richer than make functions, and it's easy to get
what you want that way. The reverse is not true in your expansion model.
Britton
