On 03/14/2016 11:10 AM, Brian Vandenberg wrote:
> For cases of recipe lines that do not have a '$(' construct, would there
> actually be any difference at all, whether or not you change the expansion
> style? I can't think of one...or maybe its just I can't think...at any
> rate,
> your proposed change primarily impacts recipe lines with '$(...)' on them.
> The rest, not so much...
>
>
> I was looking through the parsing code a week ago. As of 4.1 it treats ${ and
> $( as meaning exactly the same thing. In our build we use the convention $()
> for macro calls and ${} for variable expansions, but the opposite could be
> true (or no convention) in other builds.
Understood...but there's no behavioral "acrobatics" required here. Regardless
of whether '$$(' or '$${' references a function or a variable (aka macro), the
currently documented behavior with .SECONDEXPANSION turned on is to convert
the $$ into $ to delay the expansion until execution time. The "hole" in the
implementation apparently is that this does not apply to recipe lines, and
until this current proposal, it has never had to. Paul's point was that $$ is
in some cases a reference to a literal $ in some constructs, and I suggest to
limit my proposed change to both .SECONDEXPANSION enabled and '$$(', but we
could add '$${' as well as pointed out by you.
In that scenario, Paul could add his proposed change, and it would still
maintain backward compatibility, for to enable it, one would have to use
.SECONDEXPANSION and $$ in combination with '(' or '{'. That would seem to be
doable. The rest of the work to actually implement the runtime expansion, is
still the same, and the '$$' as a reference to a literal '$' should still be
protected.
I'm perfectly happy with current behavior, but if there's going to be a
change, I _really_ don't want it to break backward-compatibility. That's the
goal of my proposal: to isolate new behavior to some new way to enable it,
one that is already familiar to the community, but yet default to old behavior.
--
### Any similarity between my views and the truth is completely ###
### coincidental, except that they are endorsed by NO ONE ###
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
