Brian Dessent wrote:
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?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 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 ``+='' operatorExplain: [EMAIL PROTECTED]'' 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. |
begin:vcard fn;quoted-printable:Chen Jun=EF=BC=88=E9=99=88=E5=86=9B=EF=BC=89 n:Chen;Jun org:Fujian Newland Auto-ID Tech. Co,.Ltd.;Technical Department adr:;;Newland Science & Technology Park, No.1 Rujiang Avenue, Mawei District, Fuzhou, China;Fuzhou;Fujian;350015;China email;internet:[EMAIL PROTECTED] title:Software Engineer x-mozilla-html:TRUE url:www.nlscan.com version:2.1 end:vcard
_______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
