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 _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
