Re: Dilemer using target-specific or pattern-specific variables

[Chen Jun （陈军）]

Brian Dessent wrote:

Just introduce another variable.

default_cflags = -c -DNDEBUG -O2
cflags = $(default_cflags)

...

my.obj: cflags = $(LateDef) $(filter-out -DNDEBUG,$(default_cflags))

$ make
Compile my.obj: -D LATEDEF1 -D LATEDEF2 -c -O2
Compile his.obj: -c -DNDEBUG -O2
linking my.obj his.obj

Brian

  

Thank you Brian. But sigh, it is just a workaround but not a perfect solution. In your method, you refrain from using cflags until the final stage(executing a rule), and in middle stages you stick to default_cflags , but what if in some middle stage I want to to filter-out something else? Then I have to introduce yet another variable. Don't you think so?

For example, a modification:

### special >>>
LateDef += -D LATEDEF1

my.obj: cflags := $(LateDef) $(filter-out -DNDEBUG,$(cflags))

ifdef DONT_OPTIMIZE_MYOBJ
  default_cflags := $(filter-out -O2,$(default_cflags)) # Oops.
endif 

LateDef += -D LATEDEF2
### special <<<

So,  it's best to add a new operator to makefile syntax , e.g.

myvar @= $(call someprocessing,$(myvar),...)

myvar @= $(myvar) abc # the same effect as ``+='' operator

Explain: address@hidden'' is like ``='', a delayed expansion, but when a recursive situation is encountered on expansion, the recursed variable reports its current value; and, after the expansion the recursed variable is updated according to the @= _expression_. This way we can eliminate many cases drawing intermediate variables to our makefiles.

I hope make's current developers can consider this.

chenjun.vcf
Description: Vcard