Thank you for the reply. I hadn't noticed it until now.

To answer the points you raised (or at least clarify my meaning):

> It seems obvious that you'd want this to print "local" not
> "global", but the evaluation of the variable happens in the
> context of the global scope.

Localizing all variables automatically would be nice, but I think that it is probably too far from the "way make works" to be imlpemented easily. And actually I was not so concerned about this as such. My main purpose was to stop trampling on the global BIZ and "peer" BIZ declarations. Given that, I think it would be acceptable for the evaluation to print "global". It would be nice to have a way to "localize" any reference of course, but I am pretty much ok with deferred evaluation remaining the way it is. So to expand your example:

BIZ = global
scope FOO {
BIZ = local
BAR = $(BIZ)
}
scope BAZ {
BIZ = local
BAR = ${localreference $(BIZ)}
}
scope BAM
{
BIZ := local
BAR := ${BIZ}
}
all: @echo foobar = ${FOO::BAR}, bazbar = ${BAZ::BAR}, bambar = ${BAM::BAR}

would echo the following
foobar = global, bazbar = local, bambar = local

Though obviously the notation for localizing a variable reference sould be nicer. Verbosity is just for illustration purposes while this feature doesn't exist :) I think the FOO::BIZ you use is not really ok, since the person then has to know the name (and probably degree of nestedness) of the current local scope.

> As far as scoping targets, that's an even MORE difficult issue.
> Variables can be scoped with some kind of naming convention, but
> targets are not like that. They represent files, typically, and
> files don't have any sort of "scope". I have a difficult time
> seeing how this could work for targets.

I must admit that mostly I was thinking of them as .PHONY targets, but I think that basically the "real target" would be the scopeless target name.

i.e.

scope FOO {
afile: echo "foo::afile" > $@
.PHONY: prepare_afile
prepare_afile: afile
}
afile: echo "afile" > $@

> make afile

echo "afile" > afile

> make FOO::afile

echo "foo::afile" > afile

> make FOO::prepare_afile

echo "foo::afile" > afile

Basically this allows someone to componentize the make more easily, as in the "a.mk, b.mk, c.mk" example in the original savannah request item. (well, more easily, ignoring the existance of recursive make)

That's not to say it would not be also  nice to have some optional way to manipulate the scoped targets to e.g. prepend a directory without rewriting every rule, but that is building a house on imaginary foundations, so I'll stop there.

Just an idea for the future:

It would be good to have the option to enable separate namespaces for included .mk files. And a way to address them of course. This would reduce the difficulty of creating compatable include files without worrying over messing up the variables of the parent. This is important when trying to do non recursive makes for large systems.

My suggestion is a  "import" keyword that is an alternative to "include", It would automatically put the imported file's variable, target, and defines (anything else?) into it's own namespace based on the imported file's pathname.

It would also use the same include search as the CPP's #include rather than make's include one.

# begin GNUMakefile
IMPORTS := a.mk b.mk c.mk
import ${IMPORTS}

default: ${patsubst %, %::default, ${IMPORTS}}
all: ${patsubst %, %::all, ${IMPORTS}}
clean: ${patsubst %, %::clean, ${IMPORTS}}
# etc...

# end GNUMakefile

and the .mk files can trash CFLAGS and any other variables or targets as much as they like, without worrying that they will break something in the "main project".

I know you probably prefer recursive invocations of make for this kind of thing though :-)