Deferred expansion and computed rules and rant about make bug

[Dale King]

I have a problem trying to convert a recursive make into a non-recursive 
make and am having trouble figuring out a good workaround.

The question was actually asked a couple of years ago, but the answer 
avoided the question and offered a workaround that focussed on the 
peculiarity of the particular example (see 
http://lists.gnu.org/archive/html/help-make/2004-03/msg00077.html)

Here is a simplified hypothetical makefile that in reality would be made 
of bits included from different directories as I have indicated with 
comments.

# The main make file
targets :=

all: do-targets

# This comes from an included file for a
foo := a
target := abc
flags := 123

# This comes from a standard include file
target-$(foo) := $(target)
flags-$(foo) := $(flags)
targets += $(target-$(foo))

$(target-$(foo)):
   @echo $(flags-$(foo))

# This comes from an included file for b
foo := b
target := xyz
flags := 789

# This comes from a standard include file
target-$(foo) := xyz
flags-$(foo) := 5678
targets += $(target-$(foo))

$(target-$(foo)):
   @echo $(flags-$(foo))

# this is back to the main include file
do-targets: $(targets)

### EOF ###

This of course will print:

5678
5678

And I understand perfectly why it does it. The commands in the rules use 
deferred expansion. The issue then is how to do what I want.

The previous email on this topic offered the workaround of putting the 
rule in a define statement and using eval-call to do it. This of course 
works in a simple example like this, but is clumsy, requires lots of 
messing around with escaping $'s to force their expansion to be deferred.

But the big problem with the eval-call workaround is that MAKE IS 
BROKEN! In reality the rules are not this simple. With lots of 
prerequisites with long path names the expanded text of the rule can be 
upwards of a kilobyte for one rule. There is a bug with eval when the 
text that is being evaluated is long it crashes with the dreaded virtual 
memory exhausted error. This bug has been reported and a fix identified 
ALMOST 3 YEARS AGO! (see 
https://savannah.gnu.org/bugs/index.php?func=detailitem&item_id=1517). 
Yet in a move that just boggles the mind there has been no new release 
of make in almost 3 years!

I cannot understand how you can have such a serious bug in a tool as 
fundamental as make and NOT RELEASE A FIX! It's not as if this is an 
obscure bug. Just google for "make virtual memory exhausted" and you'll 
get quite a few hits.

Sure its fixed in CVS, but how does that solve the problem. Do you 
really expect everyone to go download the latest unreleased source, and 
rebuild it for their system?! Note in my case this is on a team of about 
20 developers and management would not look favorably on using a patched 
make tool for doing builds.

So I am looking for another workaround to the issue. I thought perhaps 
target-specific variables might do it, but haven't gotten it to work.
--
Dale  King