Re: How to stop a variable from being exported?

[Paul D. Smith]

%% Boris Kolpackov <address@hidden> writes:

  bk> Paul D. Smith <address@hidden> 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 <address@hidden>          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