Re: undefine

[Boris Kolpackov]

Hi Paul,

Paul D. Smith <address@hidden> writes:

> > override undefine CFLAGS
> 
> We don't really have much precedent for combining keywords like this.

I feel like I am missing something here. What about define?

override define foo
bar
endef

The idea is to model undefine after define so that we don't have to 
invent and explain much here.


> What if someone wrote "undefine override CFLAGS" instead?  Does/should
> order matter here?

Depends on whether it matters for define ;-). I am pretty sure the answer 
is yes ('define override foo' doesn't work).


> The other thing I wonder about is using undefine in a target-specific
> variable context.  Is this allowed?

No, since it is not allowed for define. Once we support something like:

bar: define var
foo
endef

and

bar/%.o: define var
bar
endef

Then we will also support undefine in these contexts.

I actually thought about this and I don't think undefine will be very 
useful in these situations. Thought I agree, for consistency we should
support it along with define.


> In a way it's a shame we don't have some concept of scope in the
> makefile syntax.  We already have a concept of scope in variable
> definitions; we can push a new variable context quite easily in the code
> and that's done all the time.  If there were syntax brought out into the
> makefile to push the variable scope then you could create variables
> local to that scope and when it ended, they would be freed up using
> existing features of the code.

That would be fantastic. Right now I do something like this manually
(that is, iterate over all the variables and store them in special, 
weirdly-named variables; these weirdly-named variables are the ones 
that I want to undefine).


> Of course this is a big change to the syntax

We would have a pair of simple functions, like $(push-variable-scope) and
$(pop-variable-scope). No syntax changes. Though having keywords like push
and pop would be nicer.


> and requires its own set of questions to be answered, such as is 
> scope only for variables?

I think rules, and target/pattern-specific variables should be global.
What else is there?


> Today we "know" that a variable, once defined, can never disappear.  I
> think there might be a few places in the code where we try to do some
> small performance improvements based on this; for example storing
> pointers to variable structures in global variables to allow for faster
> checking.  You might take a look at where we use global "struct
> variable" variables.

Ok, I will have to check that.


> Also, variable names are currently stored in the string cache so they 
> can never be removed from memory; your change might save performance 
> but it won't help memory usage (I know that's not why you suggested it).

It does help memory usage since the struct variable instance is removed
from the hash table. It is just not as much as it could have been.

Boris