Re: undefine

[Paul Smith]

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.