[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: undefine
From: |
Boris Kolpackov |
Subject: |
Re: undefine |
Date: |
Mon, 5 Oct 2009 18:28:12 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
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
- undefine, Boris Kolpackov, 2009/10/05
- Re: undefine, Paul Smith, 2009/10/05
- Re: undefine,
Boris Kolpackov <=