Re: Last patch reviewed.

[Boris Kolpackov]

Hi Paul,

A few comments, if I may:

Paul Smith <address@hidden> writes:

> For the former, I think we need to allow the syntax $(::var) which
> returns the global value of the variable "var", for consistency.  This
> could be useful in some situations, as well.  Also, I wonder if it would
> be useful to allow variables to be _SET_ using this syntax.  Then you
> could write something like:
>       somefile::VARIABLE = foo
> which is the same thing, syntactically, as:
>       somefile: VARIABLE = foo
> This would be tricky to add into the parser, though, and maybe it's not
> worth it.

Why not change the "get" syntax to be $(somefile: VARIABLE) instead
of $(somefile::VARIABLE)? This way:

1. The "set" syntax is already there.

2. From the backwards-compatibility standpoint, 'somefile: VARIABLE'
   is a very unlikely existing valiable name, more so than
   'somefile::VARIABLE'.

> The only thing I can think that this would allow is to use
> define/enddef with target-specific variables, which is currently not
> straightforward (you have to define a different variable globally, then
> set the target-specific variable to that value).

Yes, it would be great if this is handled properly, e.g.,

somefile: define foo
        @echo one
        @echo two
endef


>
> For the latter (inheritance inhibition), there are a few things.  First,
> I think the name of the token should be changed from "not-inherit" to
> "local".  Naming things in the negative ("I am not this" instead of "I
> am this") is something we want to avoid.

While I agree "not-inherit" is a bad keyword, "local" has a bit
different connotation, as being opposite to "global". And GNU make
already has an opposite to "global" which is "target specific".
Maybe "private"? In this case we can say that a variable is
private to a particular context (global, or target-specific) and is
not "inherited" by other contexts.

> Second, it should be valid to mark even global variables "local",
> for consistency.

Can't ask for a better illustartion of my previous point ;-).

Boris