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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.