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
_______________________________________________
Help-make mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-make
