[Top][All Lists]

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

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

From: Chen Jun (陈军)
Subject: Re: Dilemer using target-specific or pattern-specific variables
Date: Fri, 17 Oct 2008 09:21:19 +0800
User-agent: Thunderbird (Windows/20080914)

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


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

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

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.

Attachment: chenjun.vcf
Description: Vcard

reply via email to

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