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
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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67265>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
