Re: Unexpected failure in tricky use of eval

[Stefano Lattarini]

On 05/13/2012 09:45 PM, Paul Smith wrote:
> On Sat, 2012-05-12 at 19:42 +0200, Stefano Lattarini wrote:
>> BTW: to make it more easy to discover at make runtime whether the bug has
>> been fixed in the make version in use, could a proper new entry be added
>> to .FEATURES?  Maybe 'can-have-lazy-variables'?  (I know, I suck at choosing
>> names).
> 
> I'm not interested in having the features option used to describe bugs
> that have been fixed, sorry.
>
No problem, I've apparently managed to find a work-around for the issue,
so I won't need this new .FEATURES entry anyway (I had already retired the
request in my other, earlier reply).

> It should be straightforward to find some real feature added in the
> release where the bug is fixed though and you can check for that instead.
>
>> Better again: would you consider the possibility of adding a new kind
>> of variables (let's call them "lazy"), so that a definition like:
>>
>>     LAZYVAR = val
>>
>> behaves exactly as:
>>
>>     LAZYVAR = $(override LAZYVAR := val)$(LAZY)
> 
> I don't have any idea what this is supposed to do... it doesn't make any
> sense as written.
>
In fact, it should have been s/$(LAZY)/$(LAZYVAR)/.  Sorry for the confusion.

> Can you describe in words what you're looking for?
> 
Basically, a new kind of assignment that do not expand the right-hand side
at definition time, but which causes the value the variable expands to the
first time it gets dereferenced to be cached, and reused in any successive
expansion of that same variable.  A sort of "memoized variables", if you
want.

A rationale for this request is given by the commit message of this patch:

  <http://lists.gnu.org/archive/html/automake-ng/2012-05/msg00067.html>

Regards,
  Stefano