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. All variable and function references follow this method
(recursively). Also, functions and variables don't have to appear in a
recipe. For example, the $(file...) function can be inside a variable value
which, if assigned via ":=", is expanded when the variable is set. Or, it can
just be sitting in a makefile at the "root" level, with no indentation and
expands as make parses the makefile.
Currently the expansion code in GNU Make doesn't even *know* whether the text
is being expanded as part of a recipe, or for some other reason.
What about the content of the $(file...) function itself? There could be
variables or even functions inside the $(file...) function, like "$(file >
$(shell cat filename.txt), foo)". What if the $(file...) function is used as
part of a conditional, like:
all:
cat $(if $(file <choose.txt),xxx,yyy)
Obviously this can't work if we expand the $(if...), but not the $(file...)!!
Or maybe it appears inside a $(shell...) function. Or, or, or...
Special-casing the $(file...) function to not expand the same way as
everything else, simply cannot be made to work.
The only feasible way to change this is what I described below: the expansion
of the entire line has to deferred.
> 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.
> 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.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67265>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
