[Top][All Lists]

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

Re: TR: Adresses email sur les probl?mes gmake

From: Paul D. Smith
Subject: Re: TR: Adresses email sur les probl?mes gmake
Date: Fri, 9 Jan 2004 17:09:12 -0500

%% Robert Mecklenburg <address@hidden> writes:

  ML> bin/CIBLE_%.elf : SUBST=$(shell echo $* | sed "s|^CIBLE_||")

  rm> This doesn't work as you seem to expect.  Remember, make operates
  rm> in two phases: reading and evaluating the dag.  Here, the RHS is
  rm> evaluated immediately upon reading the makefile - the shell
  rm> command is run before any file is bound to the rule.

Actually, this is not really true... or rather you have the right reason
but are quoting the wrong line.  Target-specific variables are expanded
like any other variable setting; in this case since the variable is
recursive it's not expanded here.


  ML> bin/CIBLE_%.elf : DEPENDANCES=$(addprefix lib/CIBLE_, $(shell cat 
src/$(SUBST).mk | egrep "^$(SUBST).elf" | cut -d':' -f2))

Again, this is OK: it merely sets the target-specific variable
DEPENDANCES to this _unexpanded_ value.

  ML> bin/CIBLE_%.elf:$(DEPENDANCES)

_THIS_ is where the problem really occurs.

Because $(DEPENDANCES) is in the prerequisite list, as Robert points out
it is expanded when the makefile is read in.  Target-specific variables
are only valid (only have their value) when they appear inside command
scripts, they do not have their value when they appear in prerequisite

So, DEPENDANCES is expanded to whatever the global value of this
variable has, which is nothing.  Just as you've seen.

Check the GNU make manual section "How 'make' Reads a Makefile" to learn
more about when variables (and functions--they behave the same way WRT
expansion) are expanded.

 Paul D. Smith <address@hidden>          Find some GNU make tips at:            
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

reply via email to

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