On 03/14/2016 10:59 AM, Paul Smith wrote:
> On Mon, 2016-03-14 at 10:36 -0700, Zoltan wrote:
>> I don't particularly see a reason to change current behavior, but if
>> you want to, how about implementing it like a "delayed" expansion
>> except for recipe lines, so instead of $(...whatever....), it would
>> be written $$(...whatever...) in order to not not break backward
>> compatibility and still allow new uses as you describe. Sort of like
>> in .SECONDEXPANSION conceptually, and could maybe even be tied to
>> .SECONDEXPANSION if needed.
>
> Ouch! The escaping of "$" with "$$" is used EVERYWHERE in recipes, and
> this would break all instances of that by doing a double-expansion.
>
> Even if we managed to work out a way around this somehow, trying to
> explain the expansion rules would be a nightmare. It's already the
> most difficult part of make for new users to grasp.
>
> Nope. As far as I'm concerned either things stay as they are or they
> change to the new method, and that's it. If someone can provide me
> with a compelling reason for the current behavior, which would include
> an in-use configuration which relies on it, then the discussion is over
> and we'll leave things as they are.
>
> If no one can come up with a good reason for the current behavior, then
> I'll leave the possibility open :).
Not exactly escaping '$' with '$$'. From your example of $(info ...), I'm
actually suggesting to escape '$(' with '$$('. So not quite the same thing at
all. And this is already implemented, and already "explained," so no extra
work there.
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...
--
### 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
