%% Boris Kolpackov <[EMAIL PROTECTED]> writes: bk> Paul D. Smith <[EMAIL PROTECTED]> writes: >> When you invoke a make with a specific value like this: >> >> make selector=abc >> >> then the variable override static string "selector=abc" will be passed >> to every submake. Whether you set your local copy of the "selector" >> variable in that version of make doesn't change the value of the command >> line string passed to sub-makes.
bk> Not that I insist it's a bug, but, IMO, this logic is bk> strange. When I say bk> override selector=cba bk> I would naturally expect the new value in every place that bk> originated from this makefile. I would expect every reference to the _variable_ $(selector) to be replaced that way, yes. But I wouldn't expect values that just happened to contain the previous value of the selector variable to be changed. I do see what you're saying that a variable assignment like this _could_ be considered a special case and not treated as a simple variable value, but instead interpreted as a set of variable assignments. But, that's not how it works. If you want to use the value of the variable you have to use a variable reference. bk> Also I can't think of any scenario where current logic might be bk> useful. Well, I can easily imagine situations where for a particular makefile you need to override a command-line setting of CFLAGS, for example (maybe this code cannot be compiled with optimization or something), but you didn't want it to be overridden for all the subsequent sub-makefiles. Of course in a situation like that you could do it a different way. But you can do this in a different way as well :-). How about: MAKEOVERRIDES := $(patsubst selector=%,selector=$(selector),$(MAKEOVERRIDES)) Of course you have to be careful about this as the := could in some situations change the behavior, which is too bad. Of course you could also do something like this: MAKEOVERRIDES += selector=$(selector) so the second setting of the "selector" variable would take precedence over the first. This doesn't evaluate MAKEOVERRIDES so it's safe. -- ------------------------------------------------------------------------------- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/help-make
