[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Deferred expansion and computed rules and rant about make bug

From: Dale King
Subject: Deferred expansion and computed rules and rant about make bug
Date: Thu, 04 Aug 2005 07:51:56 -0500
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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

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))

   @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))

   @echo $(flags-$(foo))

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

### EOF ###

This of course will print:


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 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]