Re: undefine
Paul Smith <[email protected]>
| Newsgroups | gmane.comp.gnu.make.devel |
|---|---|
| Organization | GNU's Not Unix! |
| Message-ID | <[email protected]> |
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.