Hi Paul,
A few comments, if I may:
Paul Smith <psmith@xxxxxxx> 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
|
