[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: undefine
From: |
Paul Smith |
Subject: |
Re: undefine |
Date: |
Mon, 5 Oct 2009 12:50:45 -0400 |
On Mon, 2009-10-05 at 18:28 +0200, Boris Kolpackov wrote:
> > 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.
I was going to say that define is different because the stuff after the
keyword is the variable name, but I realized undefine would work the
same way. So, never mind! :-)
> > 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.
Actually I think this almost works now. I intended to get it working
but there's a subtle issue with the parser and how these interact with
ifdef/endif (IIRC) that causes some problems. But as far as the lexer
is concerned I believe this can basically work today.
> > 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).
There are other questions here of course. Do we need a new keyword to
mark a variable as local to the scope? Or choose the global reference
value? It gets complex:
FOO = foo
<new scope>
FOO = fum
BAR = baz $(FOO) boz
<end scope>
Now what's the value of $(FOO)? What's the value of $(BAR)? Etc.
Maybe we could repurpose the new "private" keyword to mean "local to
this scope".
> > 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.
Erm, not functions. This would need to be a keyword. Functions can be
used anywhere, like in recipes, etc. and what would THAT mean? The
push/pop of the scope is a syntax of the makefile parser, so it should
be new keywords (or, I guess, symbols like braces or something). IMO,
anyway.
> > 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?
True. That's what I'd think as well but we should think carefully about
whether there's ever a use for a "target scope"; if we say "no" and then
need to introduce one later, that would be a drag.