[Top][All Lists]

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

Re: How to stop a variable from being exported?

From: Paul D. Smith
Subject: Re: How to stop a variable from being exported?
Date: Wed, 27 Oct 2004 17:42:56 -0400

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

  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

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:            
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist

reply via email to

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